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.
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.
[1] https://en.wikipedia.org/wiki/King%27s_Indian_Defence