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.
From the article:
"paleographers today identify the extinction of scriptio continua as a critical factor in augmenting the widespread absorption of knowledge in the pre-Modern Era. By saving the reader the taxing process of interpreting pauses and breaks, the inclusion of spaces enables the brain to comprehend written text more rapidly."
I kind of love this! I feel like if I got used to reading letters backwards, this would actually be easier to parse, because I don't have to move my eyes back to the start of the next line.
Japanese also doesn't have casing or spaces, which can make text written solely in hiragana (like some Famicom games) hard to read. I don't know enough about Chinese and Korean to opine on how difficult they are to read and comprehend, but by using the four writing systems (hiragana, katakana, kanji, and western script), Japanese is easy enough to read.
I've read that it such text usually was read out loud. Not sure if doing so actually make it easier to parse, but maybe latin was more phonetically regular than english?
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.
I still don't understand how comes that in times of programming fonts with fancy ligatures there is not a single one that would attempt to make camelCase more legible by slightly separating lowerUPPER sequences (presumably by constructing a "anti-ligature" for each unique pair that would have still width of two glyphs).
Or try to do anything similar to ease reading theseAnachronisticCharacterSequences.
The most peeving to me is camel case conventions that preserves the capitalization of abbreviations. Convention that would require TCPIPQOSScore instead of tcpIpQosScore.
Yeah no thanks. Soo `a-b` and `a - b` are both potentially valid and different?
Also allowing hyphens generally leads to issues when interoperating with other languages that don't support hyphens. Probably the best example of this is CSS which does allow hyphens, and Javascript which doesn't. `background-color` in CSS gets translated to `backgroundColor` in JS.
It's an annoying paper cut that trips up beginners and makes code less greppable. I generally avoid hyphens wherever possible for that reason.
> Yeah no thanks. Soo `a-b` and `a - b` are both potentially valid and different?
Like what the sibling comment said: `-b` should be illegal. And I don’t think this would be a big deal in practice for experienced users (used to these rules).
For beginners you could build in an error check: give a dedicated error message if you write `a-b` but you happen to have both variables `a` and `b`. Then the compiler can tell that you probably meant `a - b`.
> Also allowing hyphens generally leads to issues when interoperating with other languages that don't support hyphens.
Make underscore illegal in the language. It’s not like you need them anymore. In turn you have a bidirectional translator.
Sure... but I didn't use `-b`. Maybe I've misunderstood.
> give a dedicated error message if you write `a-b` but you happen to have both variables `a` and `b`
I guess, though the idea of having mutually exclusive sets of identifiers sounds like a nightmare. You can have `a` and `a-b`, or `a` and `b`, but not `a`, `b` and `a-b`... Maybe it wouldn't come up much in practice but it's still a pretty big WTF.
> In turn you have a bidirectional translator.
But the problem is that you have this translation in the first place. It makes the identifier ungreppable. Ideally any place you have an identifier it looks exactly the same through your whole codebase and if you have to translate it then that is no longer true. For example if you want to update all background colours in your project you might search for `background-color`... but miss `backgroundColor`.
Kebab-case is the clear superior case due to requiring fewer keystrokes overall. I think languages should go for kebab case and do something else with infix formulas, as programmers write/read identifiers more than they write/read subtraction in formulas.
What about other identifiers? For example class names.
ThisClass thisVariable = null
The above is "obvious", as is the below:
this_class this_variable = null
However what is
this class this variable = null
Is it a variable named "variable" of type "this class this"?
Is it a variable named "this variable" of type "this class"?
Is it a variable named "class this variable" of type "this"?
Even in languages where you can have spaces, only jerks do that. Do you really want to type [Some stupid variable name].[some Stupid function]?
These are false time savers. We’re writing code, just recognize that and do what’s natural, snake_case. Any conventions to make code “more readable” to make it like written language seem like fool’s errands to me.
I still think the space adds more readability than the dot dectracts. If you don't like the dot though, I would use a comma. We have been writing for a couple centuries now, and the comma is well known and used.
search result := users, find all by name (name)
if search result, is present() {
return ok(search result, get())
} else {
return not found()
}
// comma is optional, used for disambiguation
search result := users, find all by name. // omitted parameters match words
if search result is present, // empty brackets can be omitted
return ok(search result value); // API change for better readability
else
return: not found. // colon is another optional delimiter
I actually like it so much, I would try to write a transpiler to Java…
PowerShell yet again proves itself to be an enlightened language:
PS> ${Valid characters for an identifier? Eh, ¯\_(ツ)_/¯ whatever (`}) you want.} = $True
PS> ${Valid characters for an identifier? Eh, ¯\_(ツ)_/¯ whatever (`}) you want.}
True
Jesting aside, I have actually used that syntax before to prefix variable names with '&' and '@' to differentiate between virtual and physical addresses in some code for patching a binary.
So that the compiler or interpreter knows the extent of the variable token. Without spaces allowed you would need some other way to tell it where they start and end, like quotes or a special declaration, which would be harder for the brain to parse. If you know a better way please share it.
I am not picturing why this is true, if you cannot use key words as parts of variables (alone separated by a space) and lines end with a newline or semicolon (some symbol)
The first restriction might make this a problem.
I am not saying it is a good idea, but it is not obvious to me.
Removing keywords from variables is a big sacrifice when they are often such common glue words, like `and`, `or`, `if`, etc. Say `and` is the keyword and you want a variable called foo_and_bar. To get such words back you would need to add something so that the parser knows if
foo and bar == true
means
foo && bar == true
or
foo_and_bar == true
?
You could fix it with ugliness like making the keyword `@and` or some such, or the variable `foo @and bar` but that's not an improvement.
Yes, it is, but it would also change the language, it is funny I forget c++ has “and” because && is so ubiquitous.
Likely you will get changes so “if” is ? Or something.
(Like we wee with ternary operator)
Like I said, I can’t picture the requirement, but am not sure it is a good idea.
> Without spaces allowed you would need some other way to tell it where they start and end
That's not a problem at all, as long a a newline isn't treated as space and you don't use ML style function application, where a space is used to separate the argument(s) from the function name - `f x` instead of `f(x)`.
With an azerty keyboard, underscores are a single stroke of the "8" key. This nullifies the "underscores are hard to type" argument. I'd even wager that the performance results are inverted in my country since snake_case does not require any press of the shift key, unlike camelCase. Also, I'm pretty sure I read a study one time that showed snake_case identifiers to be easier to read than camelCase ones.
Anyways, I think you should follow the specific guidelines of the language you are currently using.
This does make me wonder how much language preferences are really shaped by lofty philosophical arguments about different paradigms, and how much is in fact unconscious physical resistance: The awkwardness of typing the language on a given country's standard keyboard layout, individual hand physiology, individual visual perception, language verbosity (looking at you, Java)...
If I read figure 2 correctly (in the follow up study), the difference in find time only appears in 3-word names, while for 2-word names the time is the same
I wonder if we could move from sharing original (plaintext) source code to some sort of intermediate representation (mostly like AST). So if you publish the AST anyone can “render” and modify it with his own preferences
I like the latter much more. I can come up with rationalizations, like my eyes having to travel to the beginning of the long identifiers if I want to tell instance and class apart in the first example but not in the second.
But honestly it’s most likely because I was socialized on Python. Feeling lucky personally that Rust follows the same convention.
I didn't care about tabs vs spaces until I was handed a project to work on accessibility for a particular webapp, and that included firing up a screen reader.
That got me to learning about all the ways that markup can (and should) be used to convey _both_ the content _and_ the structure of the information on the screen, for the benefit of vision-impaired readers.
That in turn led to the epiphany that the tab character _is_ markup for indentation, and in the world of programming, where indentation is so significant for understanding (especially in whitespace-sensitive languages like Python), I wondered why we were making things harder for vision-impaired users by focusing so much on _visual_ consistency (which can still be achieved by syncing editor "how do I render tabs" settings)
