You should NEVER have "using namespace" (for any namespace) in a header file, since that is how you create name clashes, which is what the namespaces are there to avoid.
I don't personally like "using namespace std;" even in implementations, since I think it makes code less readable, and the contents of std:: is so large, and growing, that I'd again prefer to just avoid the possibility of name clashes.
We write code once, but read it many times, so shorter names (incl. namespaces) seems like a poor efficiency choice.
>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.
> 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 ...
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.
> 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?
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.
> 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
Are you even a developer?
In the programming world "longer names" is universally understood (except apparently by you) to mean "longer due to being more descriptive". NOBODY thinks that making identifier names longer just for the hell of it beneficial.
It's as if a chess player is describing to you the importance of controlling the center of the board, and you are wondering out load if they mean controlling it by clamping it to the table.
Perhaps you think suggestions like this make you sound smart. They don't.
Which is why that advice confuses the metric for the principle.
This is your exact quote:
"We write code once, but read it many times, so shorter names (incl. namespaces) seems like a poor efficiency choice."
And the point being made is that there are cases where shorter names are actually more readable than longer names and one of those cases is when every name shares a common prefix. By prefixing everything with something common code becomes more uniform, and names become less distinctive and consequently less readable because it's harder to identify and differentiate sections of code. Code ends up looking like a soup of std::s everywhere.
It would be like a chess player who only tries to control the center because someone told them that controlling the center is important, but then repeatedly loses to the King's Indian Defense [1] because they never took the time to fundamentally understand why the center is important and so they don't realize how the King's Indian Defense is used precisely to destabilize the center of the board with sharp angles of attack.
They just blindly apply what they hear... and let me tell you there are plenty of mediocre chess players who do just that.
In almost any field from programming to chess to sports, you can find guidelines and good rules of thumb and I do not want to discourage people from knowing those rules because having heuristics certainly improves productivity. But don't ever let those rules become dogma; at some point it's worth understanding what the principles behind those rules are, when do they apply and when don't they apply.
>Are you even a developer?
Note that you keep trying to make this discussion personal whereas I have kept this discussion about the topic and the argument.
I would respectfully ask you to do the same, let's discuss the topic and avoid making this personal. It's irrelevant how long you've been programming for or how long I've been programming for or even if I am a programmer at all.
Trying to justify arguments on the basis of who you are or who I am is a poor way to go about engineering best practices.
What matters is whether your points can be justified.
The chess analogy seemed to go over your head. It's not about the value of chess theory, but about you repeatedly wanting to assume the person you are talking to is stupid, and throwing out your own straw man theories of what they are thinking, rather than actually engaging in discussion.
If someone was explaining to you why a particular chess move was good, then it'd be reasonable to assume they have some familiarity with chess, but your approach would be to trot out your (newly learned?) "cargo cult" accusation, and wonder why they think screwing the center of the board to the table is a good thing, or as you have just done, assume that they are too dumb to have any familiarity with book openings.
You are obviously young, and as you get older you will realize that experience does matter. Future you in 10 years time will hopefully (if you pay attention to your craft, whatever that may be) be smarter and more capable than current you, and future you in 20 years a level-up from that.
You ask to not make this personal, but you made it personal right from the start of your response, throwing out straw man arguments and cargo cult accusations. It's a bit ridiculous to then come back and say "don't make it personal". So, rather than give you a technical discussion, I'm giving you the one you are really asking for.
> 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.
Frankly, this is puerile and pointless. You're doing nothing of the sort. You're just being needlessly contrarian while framing issues from a place of arrogant ignorance, and not having others bite your troll bate doesn't mean you made any point or anyone was enlightened by the engagement.
> I am not saying you are cargo cult programming, but being a cargo cult programmer has nothing to do with seniority.
One thing that is a clear tell that you are not senior is this belief that just because you are oblivious to problems it somehow means they don't exist.
Between someone who "blindly follows rules" and someone who doesn't think there's any problem in tearing down any example of a Chesterton's fence that comes across them, I'd take the cautious developer who understands tradeoffs.
In this case, mindlessly peppering include headers with using namespace directives leads to name conflicts in your code and in code that consumes your code. You need to understand what is the whole point of namespaces and what you are doing by essentially removing them. Think about it for a second.
> 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.
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.
> 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.
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.
Not only that, but you have no idea what's going to be put into the standard tomorrow.
If code I write today has a class called bubble_sorter, and then one day, the C++ standard library decides to add std::bubble_sorter, then:
1. If I had "using namespace std;" then all of my code is suddenly broken.
2. If I didn't have it, I'm fine.
Also, and this is just personal preference, but I simply like to be able to clearly distinguish when my code is calling into the standard library. Typing in that short "std::" reminds me that I am calling into someone else's code.
>If I had "using namespace std;" then all of my code is suddenly broken.
If this happened and if you included that specific header, you would get a simple compiler error due to ambiguous methods. Then you can simply add a namespace somewhere and move on. I know sometimes this can involve a lot of changes (if we're talking about other `using namespace ...` usage) but in general you're not gonna have problems.
If you're really worried about this, you can move the statement closer to where you need it. This is very helpful for dense code that you normally want to be verbose.
> If this happened and if you included that specific header, you would get a simple compiler error due to ambiguous methods. Then you can simply add a namespace somewhere and move on.
...or, hear me out, you can not make the mistake of mindlessly adding using namespace directives and therefore ensure neither you nor any consumer of your code will risk.having to handle perfectly avoidabld name clashes.
And by the way, name clashes will also happen if you include code from two or more dependencies which introduce ambiguous symbols. This is code outside of your control.
>...or, hear me out, you can not make the mistake of mindlessly adding using namespace directives and therefore ensure neither you nor any consumer of your code will risk.having to handle perfectly avoidabld name clashes.
I'm not talking about "mindlessly" adding these namespace statements. I'm saying, use good judgement. As I pointed out, if you use a little common sense you won't have name clashes and even if you did, they usually cause compile errors. Just don't put them in headers ffs... If you really just need a lot of stuff from another namespace in a function, put the using statement in that function.
>And by the way, name clashes will also happen if you include code from two or more dependencies which introduce ambiguous symbols. This is code outside of your control.
The using statements are not outside your control, unless someone put them in a header. That's the only place I broadly object to them.
What's the logic of that though? Longer more descriptive names (self-documenting code) help readability, not hinder it.
Certainly time to enter code (which is increasingly going to be automated) should be the last consideration - if we're considering full software lifecycle then coding probably takes up some small single-digit percentage of the time we're interacting with the code.
Longer names are harder to read. Think about any math formula. Does energy=mass * math::powerf(speed_of_light, 2) read more fluently?
Context matters. Make sure the context is ways clear and code is written there where it belongs. Then names can be shorter while being readable.
I'm not sure that's a great example. Of course e = mc^2 is so iconic and well known that most people know it, and will probably even perceive it as a whole. Once you recognize it then no need to explain what e, m and c are.
However, most code is not that obvious, and in the real world you're probably not looking at one mystery line of code who's function becomes obvious by context - you are more likely looking at entire functions or blocks of code, maybe without comments, trying to figure out what is going on. Try inheriting 10K of mostly undocumented code, and then you'd probably be a lot more grateful that the original author used descriptive names and comments, even though he knew what it all meant when he wrote it.
You should NEVER have "using namespace" (for any namespace) in a header file, since that is how you create name clashes, which is what the namespaces are there to avoid.
I don't personally like "using namespace std;" even in implementations, since I think it makes code less readable, and the contents of std:: is so large, and growing, that I'd again prefer to just avoid the possibility of name clashes.
We write code once, but read it many times, so shorter names (incl. namespaces) seems like a poor efficiency choice.