To be pedantic, note that is not the "C++ version" of max(). This is a particular STL's implementation of max(). Different STL implementations may approach it somewhat differently.
In practice, the style for writing STL code is often quite ugly (sometimes deliberately ugly), for reasons which aren't really interesting to most people.
It is interesting, it is related to this downside of C++ that templates have to be defined in header files, instead of say being compiled in some kind of module.
Yes it is easily fixed but this is a lack of attention to detail in a fundamental area. I would imagine that many, many people have seen that code at some point and yet have not bothered to fix up a glaringly obvious formatting error. That may say more about people than the quality of the code but it looks awful to an outsider (like me).
That chunk of code is one of the fundamental building blocks of C++. When presented as exhibit A it should look good. To an outsider that sort of thing looks bad, even if the presented thing is correct the silly error will be obsessed over - as here.
If something is important enough, and I think that C++ is one of those, then for $DEITYS sake fix the obvious stuff before having to be an apologist for it. A simple sed script run decades ago would have done that.
The reason I am labouring this point is that one day it wont be a discussion on HN debating this sort of bollocks but something involving lots of dosh. If S&M ever realised what source code really looked like - they'd have a fit. The world turns ...
Argh, I deserve my portion of lashes, but it is so clearly standing in my experience: most coders who don’t care of syntactical purity like formatting, indenting, consistency, meaningfulness etc. — they have less awareness and make more errors than those who do. It is not a strict rule, but a sign of weakness in that regard.
}
int foo(){
for(x=1; x<len*2;x++){//over 2 array len
...(no empty lines for next hour)
I know I’m clinical perfectionist, but try to see it behind my complaint. Our brain can process only few things in parallel. If you overload it with parsing and do not provide hints like grouping and/or formatting, you occupy a couple of threads for a complete bs. As if programming was not one of the hardest things already.
I agree. This looks to me like a commented out source line, not a comment that describes what comes next using a similar code expression.
It makes sense to drop the space before the start of the commented code because that way you can just delete the // and obtain the original source line.
This seems like the kind of thing which is easily corrected and probably not relevant for determining which is the better approach.