3 ms·

>We write code once, but read it many times, so shorter names (incl. namespaces) seems like a poor efficiency choice. I think it's fascinating how different pe

by Kranar 2y ago

>We write code once, but read it many times, so shorter names (incl. namespaces) seems like a poor efficiency choice. I think it's fascinating how different people can interpret this so differently. I feel like it's precisely because we read code so much more than we write it that we should prefer using names that get to the point, instead of having so much noise and repetitive boilerplate. Reading a soup of std::this, std::that, std::foo, std::bar is so difficult to parse through. Especially if you're like me and you sound things out in your head, which I recently learned is not how everyone reads. The only justification for writing all those std::'s is because compilers can't disambiguate names from their context, but you're not going to find a human who comes across a use of vector<Foo>, or sort(...) and throw their hands up in confusion wondering what was meant. >We write code once, but read it many times, so shorter names (incl. namespaces) seems like a poor efficiency choice. This to me seems like a cargo cult justification, where you've heard the argument that descriptive names are helpful for readability, so we should name our variables in a way that conveys their intention as opposed to 1 letter names or obfuscated abbreviations, but instead of genuinely understanding the principle behind the rule, you think the rule is simply that it's better to have long names over short names. Descriptive names that can be used to disambiguate variables from one another on the basis of their purpose... yes, please do that. Writing long names just so that they are long, especially by giving everything a shared prefix like std::... no, that's a misunderstanding of the justification behind the rule. It's similar to that saying along the lines of when a principle becomes a metric, it ceases to be a useful principle.

HarHarVeryFunny 2y ago
> This to me seems like a cargo cult justification, where you've heard the argument ... Well, no, I've been a professional programmer since 1982, and a hobbyist one both before then and to this day. I might be wrong, but these are the lessons I've learnt over the decades working on a variety of projects of different size and durations ... Of course consise code is nice, and while you're in the heat of development it's easy to pretty much memorize an entire codebase, even a large one, but it's when you have to come back to it years later, and barely even recognize the code as your own, that you'll be happy it's self-documenting. Now, on a large team that "future self" may just be the new hire, or the guy who replaces you when you quit ...
- Kranar 2y ago
  I am not saying you are cargo cult programming, but being a cargo cult programmer has nothing to do with seniority. There are plenty of people who have been programming for decades who blindly follow rules because that's how they learned things, that's what they were taught is good practice, and they never bothered to question it, reflect on it, and they go along with it because of cultural reasons rather than because they have a genuine understanding of the principles. >I might be wrong, but these are the lessons I've learnt over the decades working on a variety of projects of different size and durations ... But what lesson did you learn? That long names are better than short names, which is what I called cargo cult programming and an instance of mixing up the metric for the principle? Or did you instead learn that descriptive names are better than non-descriptive names? If it's that long names are better than short names, then by all means continue using std:: everywhere. If instead it's that descriptive names that communicate purpose or intention or actual information are better than non-descriptive names, then having a bunch of std:: everywhere doesn't do much of anything to help readability, it just adds noise. Now people can and do justify the use of std:: but I've never heard it on the basis of making code more readable. There is nothing self documenting about a bunch of names that all share a common prefix. And this doesn't even touch on how ironic it is that std is itself non-descriptive jargon that is an abbreviation of standard, but I am almost certain that if everyone had to liter their codebase with standard:: everywhere, no one would think twice about what the right thing to do is.
  - HarHarVeryFunny 2y ago
    > But what lesson did you learn? That long names are better than short names, which is what I called cargo cult programming and an instance of mixing up the metric for the principle? Or did you instead learn that descriptive names are better than non-descriptive names? Do you always suppose that the people you are talking to are morons and cargo-cultists? Rhetorical question - have fun.
    - Kranar 2y ago
      I like to present questions to people to justify their position so that others reading the advice can better evaluate it, understand the reasons and make a more informed judgement on it. I am also principled in critiquing an argument and never critiquing a person. I said that the advice you gave is a form of cargo culting, but I also said in the very first sentence that "I am not saying you are cargo cult programming". I don't think there is anything wrong with getting into the subtleties of whether the advice is what you originally said it was, which is that longer names are better than shorter names, or whether the advice you learned was that descriptive names are better than non-descriptive names. I think the subtlety between those two statements is not being appreciated and without a clear distinction other people may read that advice and take away the wrong conclusion. Take care.
krimskrams 2y ago
I'd like to bring some perspective as someone who comes from a non-programmer background (mainly academic data science with Python and R) and just starting to learn C++. Bjarne's book seemed to be a comprehensive introduction and I'm currently going through it. I found that adding "using namespace std" at the beginning of the file reduced some of C++'s syntactic overhead that a beginner such as myself has to account for. It allows me to focus on the essential by learning the programming principles, rather than getting stuck on the syntax and having to (annoyingly) repeat std:: every line. Nevertheless, I think every beginner should know the disadvantages of setting the namespace at the beginning of the file and that no one should use it in production code, but it does its job at keeping things simple if I'm just starting out with C++. There is a reason why Bjarne does this in his book, and I can see why.
- chipdart 2y ago
  > Bjarne's book seemed to be a comprehensive introduction and I'm currently going through it. I found that adding "using namespace std" at the beginning of the file reduced some of C++'s syntactic overhead that a beginner such as myself has to account for. It allows me to focus on the essential by learning the programming principles, rather than getting stuck on the syntax and having to (annoyingly) repeat std:: every line. That's a false dichotomy. You are free to add using namespace directives in scopes that aren't propagated to other components, such as private headers, source files, functions definitions, etc. including using namespace directives in interfaces is a notorious source of problems. The problem with Stroustrup's pedagogical style is that it conveys to newbies that this approach is the right way to write code although this is a known source of nontrivial problems that will leave any newbie stumped.
  - krimskrams 2y ago
    You make a good point. After more reading on this, I change my mind. The slew of problems caused by using namespace directives far outweigh the positives of avoiding the use of prefixes for convenience sake. Even if there are cases where they can be safely used as you've mentioned, its introduction in the book early on, especially in the examples, seems to be a crutch that could lead to an eventual footgun for beginners like me who are following along. I'll reconsider its use from now on.
chipdart 2y ago
> I think it's fascinating how different people can interpret this so differently. Sneaking using namespace directives in interface headers is a well known source of problems, as it inadvertently introduces names to lookup which can and often clash. I mean, think for a second: why are namespaces used? What problem do they solve? And why do people think it's a good idea to add all names to a custom namespace? Well, adding those names to interface headers negates all that. That's why some people interpret things differently: they are oblivious to this problem as their negligible experience means they never experienced any of the problems they cause.

by Kranar 2y ago

HarHarVeryFunny 2y ago

> This to me seems like a cargo cult justification, where you've heard the argument ... Well, no, I've been a professional programmer since 1982, and a hobbyist one both before then and to this day. I might be wrong, but these are the lessons I've learnt over the decades working on a variety of projects of different size and durations ... Of course consise code is nice, and while you're in the heat of development it's easy to pretty much memorize an entire codebase, even a large one, but it's when you have to come back to it years later, and barely even recognize the code as your own, that you'll be happy it's self-documenting. Now, on a large team that "future self" may just be the new hire, or the guy who replaces you when you quit ...

Kranar 2y ago
I am not saying you are cargo cult programming, but being a cargo cult programmer has nothing to do with seniority. There are plenty of people who have been programming for decades who blindly follow rules because that's how they learned things, that's what they were taught is good practice, and they never bothered to question it, reflect on it, and they go along with it because of cultural reasons rather than because they have a genuine understanding of the principles. >I might be wrong, but these are the lessons I've learnt over the decades working on a variety of projects of different size and durations ... But what lesson did you learn? That long names are better than short names, which is what I called cargo cult programming and an instance of mixing up the metric for the principle? Or did you instead learn that descriptive names are better than non-descriptive names? If it's that long names are better than short names, then by all means continue using std:: everywhere. If instead it's that descriptive names that communicate purpose or intention or actual information are better than non-descriptive names, then having a bunch of std:: everywhere doesn't do much of anything to help readability, it just adds noise. Now people can and do justify the use of std:: but I've never heard it on the basis of making code more readable. There is nothing self documenting about a bunch of names that all share a common prefix. And this doesn't even touch on how ironic it is that std is itself non-descriptive jargon that is an abbreviation of standard, but I am almost certain that if everyone had to liter their codebase with standard:: everywhere, no one would think twice about what the right thing to do is.
- HarHarVeryFunny 2y ago
  > But what lesson did you learn? That long names are better than short names, which is what I called cargo cult programming and an instance of mixing up the metric for the principle? Or did you instead learn that descriptive names are better than non-descriptive names? Do you always suppose that the people you are talking to are morons and cargo-cultists? Rhetorical question - have fun.
  - Kranar 2y ago
    I like to present questions to people to justify their position so that others reading the advice can better evaluate it, understand the reasons and make a more informed judgement on it. I am also principled in critiquing an argument and never critiquing a person. I said that the advice you gave is a form of cargo culting, but I also said in the very first sentence that "I am not saying you are cargo cult programming". I don't think there is anything wrong with getting into the subtleties of whether the advice is what you originally said it was, which is that longer names are better than shorter names, or whether the advice you learned was that descriptive names are better than non-descriptive names. I think the subtlety between those two statements is not being appreciated and without a clear distinction other people may read that advice and take away the wrong conclusion. Take care.

krimskrams 2y ago

I'd like to bring some perspective as someone who comes from a non-programmer background (mainly academic data science with Python and R) and just starting to learn C++. Bjarne's book seemed to be a comprehensive introduction and I'm currently going through it. I found that adding "using namespace std" at the beginning of the file reduced some of C++'s syntactic overhead that a beginner such as myself has to account for. It allows me to focus on the essential by learning the programming principles, rather than getting stuck on the syntax and having to (annoyingly) repeat std:: every line. Nevertheless, I think every beginner should know the disadvantages of setting the namespace at the beginning of the file and that no one should use it in production code, but it does its job at keeping things simple if I'm just starting out with C++. There is a reason why Bjarne does this in his book, and I can see why.

chipdart 2y ago
> Bjarne's book seemed to be a comprehensive introduction and I'm currently going through it. I found that adding "using namespace std" at the beginning of the file reduced some of C++'s syntactic overhead that a beginner such as myself has to account for. It allows me to focus on the essential by learning the programming principles, rather than getting stuck on the syntax and having to (annoyingly) repeat std:: every line. That's a false dichotomy. You are free to add using namespace directives in scopes that aren't propagated to other components, such as private headers, source files, functions definitions, etc. including using namespace directives in interfaces is a notorious source of problems. The problem with Stroustrup's pedagogical style is that it conveys to newbies that this approach is the right way to write code although this is a known source of nontrivial problems that will leave any newbie stumped.
- krimskrams 2y ago
  You make a good point. After more reading on this, I change my mind. The slew of problems caused by using namespace directives far outweigh the positives of avoiding the use of prefixes for convenience sake. Even if there are cases where they can be safely used as you've mentioned, its introduction in the book early on, especially in the examples, seems to be a crutch that could lead to an eventual footgun for beginners like me who are following along. I'll reconsider its use from now on.

chipdart 2y ago

> I think it's fascinating how different people can interpret this so differently. Sneaking using namespace directives in interface headers is a well known source of problems, as it inadvertently introduces names to lookup which can and often clash. I mean, think for a second: why are namespaces used? What problem do they solve? And why do people think it's a good idea to add all names to a custom namespace? Well, adding those names to interface headers negates all that. That's why some people interpret things differently: they are oblivious to this problem as their negligible experience means they never experienced any of the problems they cause.