I prefer to use a language's convention, whatever that might be. The language's standard library will expose names using the language's convention, and using a different convention for my own code's names would make for strange and confusing looking code.
That is silly. I think C++ went with lowercase because they expected namespaces to disambiguate everything. The last bullet makes it seem like it's because stuff is templated.
> The language's standard library will expose names using the language's convention
In Python the logging library is written in camel case (as it was heavily based on log4j) unlike most of the rest of the standard library, but the developers have let it be because fixing it would break backwards compatibility, and in any case PEP 8 [1] says consistency within a module is more important than global consistency.
In my opinion they should have fixed it in the move from Python 2 to 3, but I guess they had enough headaches from that.
Issues arise when you're dealing with multiple languages. Say, if you're working on a Java app (which uses camelCase) backed by a Postgres database (which uses snake_case).
Postgres in particular has case-sensitivity quirks if you try to force the use of camelCase table names.
I'm firmly in the camp that doesn't care what the rule/style is, I just want an unambiguous rule. I'll just use whatever the language conventions are. Snake case in Java, for example, would be a hate crime. So would camel case in C.
My general preferences beyond that are:
- Opening braces on the same line (I see the article has examples where it's on a new line);
- Two space indent, no tabs
- No trailing white space. This should be automatically removed so it doesn't generate extraneous changes on commit;
- A reasonable line length between 80 and 120 characters, depending on the language. You need to be able to look at 3 files side by side without wrapping.
- Don't put the return type on a separate line. This is a really old school (K&R) C style
- Don't align function parameters with opening parentheses. Change the function name and you generate a bunch of changed lines for the parameters.
- No space before semi-colons eg for (i=1; i<100; i++) not for (i = i ; i < 100 ; i++ )
I would love to see a space advocate's response to this, mostly so I can disregard it because they are heathens on the wrong side of a holy war, but also because this is the only argument I've ever heard one way or another which seems to boil down to anything more than opinion.
There are two classes of rules here: naming and formatting. Formatting can be completely automated and thus changed at will, even locally with git hooks. Whitespace can be made truly insignificant with the proper tools.
While you could apply the same kind of automated logic to naming, the risk of collision is non zero and moreover would likely break runtime mechanisms like reflection, etc.
1. You're writing C++. You've really lost half the battle laready :) and
2. Writing correct templated code is difficult and should generally be reserved for when you're writing a library; and
3. For complicatred types like this, one should strive to increase readability by using type aliases, assuming your language supports it (eg C++ and Hack do). It's not always possible.
By sheer coincidence, I was talking about this only a few days ago, and it also jogged my memory so that I reviewed a 2013 rust-dev thread on Java versus .NET conventions for type names, which differ in handling of acronyms: .NET style goes Gc and HttpServer; while Java goes GC, HTTPServer. As for XMLHttpRequest… ugh, that thing’s a menace.
My suggestion:
> There seems to be a basic assumption of ASCII identifiers. Hey, this ain't the eighties!
> Let's have us an XᴍʟHᴛᴛᴘRequest. Absolutely clear with no scope for misunderstanding in either direction: Gᴄ; Rᴄ; Aʀᴄ; SimpleHᴛᴛᴘServer.
> Monospace font support is a little poor, but I'm sure they'll fix that up once the desire is demonstrated.
> Q and X don't have small-caps variants in Unicode, so acronyms will be banned from having a Q or an X in the middle.
(My email wasn’t just trolling; I also added meaningful arguments in both directions to the discussion. But small caps was just too fun a concept to not mention. I also notice that Unicode 11 in 2018 added U+A7AF "ꞯ" LATIN LETTER SMALL CAPITAL Q for some reason (subhead “Letter for Japanese phonemic transcription” and I haven’t looked any deeper), but there’s still no small caps X.)
I’m glad to say that Rust stuck with the .NET rather than Java style—it’s easier to reason about, apart from anything else, because of having fairly unambiguous rules, and supports tooling better in a similar way to snake_case, because of unambiguous word separation. I’m also glad that no one ever challenged Rust’s use of snake_case for variables and fields and such.
I agree; I have done a full 180 from preferring camelcase to using snake case everywhere. It simplifies parsing for my old eyes.
I also got unnaturally irritated by PowerShell's insistence on hewing so closely to CamelCaseOrthodoxy that common abbreviations and acronyms like ID, IP, and DB became Id, Ip, Db.
Left to my own devices, I'll use OTBS + lower_snake and it drives some of The Youths on my team insane.
Agreed. I started with Java which gave me a bias towards camel case to begin with (as well as braces over whitespace), but have changed to Perl and now Python. Snake case is definitely easier to read, but Python encourages CamelCase for class names, and I see the advantage in mixing for different things.
I got the solution! Given that spaces in identifiers cannot be used because we need to please the language tokenizers (shouldn't be the other way around with humans vs machines?), let's use TAB as a word separator!
Configure TAB width = 1 character, and there you go.
Would allowing spaces in identifiers even introduce any ambiguity in most languages? I think the only languages I've seen where it would matter are functional languages. e.g. I think it'd be possible to write a Python program using spaces instead of underscores, and be able to unambiguously parse it with a slightly modified parser?
Since the space of valid syntax becomes so much larger, typos are more likely to result in valid but incorrect programs. Especially in dynamic interpreted languages like python.
> I think the only languages I've seen where it would matter are functional languages.
Yes, ML style function application is a problem and treating newlines as "normal" whitespace without having line separators (aka semicolons). And keywords used as infix operators, like another post reminded me of.
i'm pretty sure ALGOL allowed spaces in identifiers. Probably some other old programming languages too. For the most part, it's just a tradition at this point.
Fortran up to 77 (well, technically still everything in fixed-form, a.k.a. punch-card-style source files) ignores spaces.
And AFAIK there still exist both versions of e.g. "goto": "go to" and "goto" are both valid Fortran 90 and later.
This, and the fact that variable names are allowed to be implicitly defined, lead to the famous bug:
DO 10 I = 1.100
declared the variable `DO10I` with a value of 1.1, instead of the loop from 1 to 100 and declaring the "statement label" 10:
Also older versions of FORTRAN, according to Crockford at least :)
> It is good to have names containing multiple words, but there is little agreement on how to do that since spaces are not allowed inside of names. There is wun [sic] school that insists on the use of camel case, where the first letter of words are capitalized to indicate the word boundaries. There is another school that insists that _ underbar should be used in place of space to show the word boundaries. There is a third school that just runs all the words together, losing the word boundaries. The schools are unable to agree on the best practice. This argument has been going on for years and years and does not appear to be approaching any kind of consensus. That is because all of the schools are wrong.
> The correct answer is to use spaces to separate the words. Programming languages currently do not allow this because compilers in the 1950s had to run in a very small number of kilowords, and spaces in names were considered an unaffordable luxury. FORTRAN actually pulled it off, allowing names to contain spaces, but later languages did not follow that good example ... I am hoping that the next language does the right thing and allows names to contain spaces to improve readability.
As someone who has battled RSI, I stopped using snake case and underscore-prefixed member variables because of the added stress all those underscores place on the weakest fingers.
I have a programmable keyboard which I have bound underscore to LeftAlt+N, input with my left thumb + right index fingers. The first key is functionally not a Left Alt key, it is a layer key that shares the same position as where you would find a Left Alt key on keyboards.
But you do have a point because not everybody has access to programmable keyboards almost all the time. Maybe snake_case isn't that ergonomic now that I think about it, although I find it easier to read than camelCase.
Ultimately, the winner is still kebab-case, which is both aesthetically pleasing and is not a double-pinky keystroke!
Apparently I type underscore with a chord on my right hand, pinky on right-shift and middle-finger up to underscore. I never noticed before your comment.
Readit News
Looking at you, C++ STL. Almost nobody names structs/classes all lowercase. This leads to silly style guidelines eg. in the Google c++ style guide:
- Name classes PascalCase (even if it's templated)
- Except if your class happens to be a templated container type, in which case name it all lowercase.
In Python the logging library is written in camel case (as it was heavily based on log4j) unlike most of the rest of the standard library, but the developers have let it be because fixing it would break backwards compatibility, and in any case PEP 8 [1] says consistency within a module is more important than global consistency.
In my opinion they should have fixed it in the move from Python 2 to 3, but I guess they had enough headaches from that.
[1] https://peps.python.org/pep-0008/
Case insensitive, of course
Postgres in particular has case-sensitivity quirks if you try to force the use of camelCase table names.
My general preferences beyond that are:
- Opening braces on the same line (I see the article has examples where it's on a new line);
- Two space indent, no tabs
- No trailing white space. This should be automatically removed so it doesn't generate extraneous changes on commit;
- A reasonable line length between 80 and 120 characters, depending on the language. You need to be able to look at 3 files side by side without wrapping.
- Don't put the return type on a separate line. This is a really old school (K&R) C style
- Don't align function parameters with opening parentheses. Change the function name and you generate a bunch of changed lines for the parameters.
- No space before semi-colons eg for (i=1; i<100; i++) not for (i = i ; i < 100 ; i++ )
Every developer can control how those tabs are rendered to their preference.
While you could apply the same kind of automated logic to naming, the risk of collision is non zero and moreover would likely break runtime mechanisms like reflection, etc.
Generally yes, but stuff like
can be on a line of its own.1. You're writing C++. You've really lost half the battle laready :) and
2. Writing correct templated code is difficult and should generally be reserved for when you're writing a library; and
3. For complicatred types like this, one should strive to increase readability by using type aliases, assuming your language supports it (eg C++ and Hack do). It's not always possible.
Also
(i = i ; i < 100 ; i++ )
Whoever does that do not change it, they are probably a psychopath. Dont risk your life correcting them.
French generally adds a space before punctuation.
My suggestion:
> There seems to be a basic assumption of ASCII identifiers. Hey, this ain't the eighties!
> Let's have us an XᴍʟHᴛᴛᴘRequest. Absolutely clear with no scope for misunderstanding in either direction: Gᴄ; Rᴄ; Aʀᴄ; SimpleHᴛᴛᴘServer.
> Monospace font support is a little poor, but I'm sure they'll fix that up once the desire is demonstrated.
> Q and X don't have small-caps variants in Unicode, so acronyms will be banned from having a Q or an X in the middle.
(My email wasn’t just trolling; I also added meaningful arguments in both directions to the discussion. But small caps was just too fun a concept to not mention. I also notice that Unicode 11 in 2018 added U+A7AF "ꞯ" LATIN LETTER SMALL CAPITAL Q for some reason (subhead “Letter for Japanese phonemic transcription” and I haven’t looked any deeper), but there’s still no small caps X.)
I’m glad to say that Rust stuck with the .NET rather than Java style—it’s easier to reason about, apart from anything else, because of having fairly unambiguous rules, and supports tooling better in a similar way to snake_case, because of unambiguous word separation. I’m also glad that no one ever challenged Rust’s use of snake_case for variables and fields and such.
https://en.wikipedia.org/wiki/Scriptio_continua
I also got unnaturally irritated by PowerShell's insistence on hewing so closely to CamelCaseOrthodoxy that common abbreviations and acronyms like ID, IP, and DB became Id, Ip, Db.
Left to my own devices, I'll use OTBS + lower_snake and it drives some of The Youths on my team insane.
Configure TAB width = 1 character, and there you go.
Since the space of valid syntax becomes so much larger, typos are more likely to result in valid but incorrect programs. Especially in dynamic interpreted languages like python.
Yes, ML style function application is a problem and treating newlines as "normal" whitespace without having line separators (aka semicolons). And keywords used as infix operators, like another post reminded me of.
It makes sense, you would never want your variable to be line wrapped anyway, right?
The challenge is that _some_ languages define the space to be unicode whitespace, not the space character.
This, and the fact that variable names are allowed to be implicitly defined, lead to the famous bug:
declared the variable `DO10I` with a value of 1.1, instead of the loop from 1 to 100 and declaring the "statement label" 10:> It is good to have names containing multiple words, but there is little agreement on how to do that since spaces are not allowed inside of names. There is wun [sic] school that insists on the use of camel case, where the first letter of words are capitalized to indicate the word boundaries. There is another school that insists that _ underbar should be used in place of space to show the word boundaries. There is a third school that just runs all the words together, losing the word boundaries. The schools are unable to agree on the best practice. This argument has been going on for years and years and does not appear to be approaching any kind of consensus. That is because all of the schools are wrong.
> The correct answer is to use spaces to separate the words. Programming languages currently do not allow this because compilers in the 1950s had to run in a very small number of kilowords, and spaces in names were considered an unaffordable luxury. FORTRAN actually pulled it off, allowing names to contain spaces, but later languages did not follow that good example ... I am hoping that the next language does the right thing and allows names to contain spaces to improve readability.
CamelCase vs. underscores: Scientific showdown - https://news.ycombinator.com/item?id=9138156 - March 2015 (57 comments)
CamelCase vs underscores: Scientific showdown - https://news.ycombinator.com/item?id=5224531 - Feb 2013 (6 comments)
Also:
CamelCase vs. underscores revisited (2013) - https://news.ycombinator.com/item?id=34525139 - Jan 2023 (257 comments)
As someone who has battled RSI, I stopped using snake case and underscore-prefixed member variables because of the added stress all those underscores place on the weakest fingers.
But you do have a point because not everybody has access to programmable keyboards almost all the time. Maybe snake_case isn't that ergonomic now that I think about it, although I find it easier to read than camelCase.
Ultimately, the winner is still kebab-case, which is both aesthetically pleasing and is not a double-pinky keystroke!
Deleted Comment