CamelCase vs. underscores revisited (2013)

I&#x27;m slightly conflicted about CamelCase. On the one hand it <i>can</i> be somewhat harder to read, on the other hand it does have a number of benefits:<p>- Typing &quot;ABC&quot; Ctrl+Space gives me code completion for AsynchronousByteChannel (and the like), whereas &quot;abc&quot; Ctrl+Space gives me code completion only for what strictly starts with &quot;abc&quot;. I.e. uppercase means &quot;words starting with that letter&quot;. Of course you could have something equivalent for non-CamelCase naming conventions, but for CamelCase it is a very natural fit.<p>- It provides the two variants lowerCamelCase and UpperCamelCase (often used for variable names vs. type names), whereas lower-kebab-case &amp; Upper-Kebab-Case or lower_snake_case &amp; Upper_Snake_Case seem more awkward in comparison (more keystrokes for the &quot;upper&quot; variant).<p>- When lowerCamelCase is used for function names, the case distinction often maps nicely to verb + noun (`createFooBar()`, `validateBazQuz()`).<p>- You still have underscore available to occasionally &quot;index&quot; a name (`transmogrifyFooBar()`, `transmogrifyFooBar_unchecked()`) unambiguously.<p>- The fact that CamelCase does <i>not</i> match normal English spelling has the advantage that it can&#x27;t clash with it. CamelCase can stand both for hyphenated-compound-words as well as for open compound words (or just a phrase), whereas other naming conventions may look like the one although the words really stand for the other.<p>- Minor advantage: You can fit slightly more words into a line.<p>Apart from that, I&#x27;m pro-kebab-case.

While I find snake_case more readable when looking at the identifier alone, it has the downside that _ is mostly whitespace with the glyph at the bottom of the character cell, and so it visually groups more with punctuation like &quot;.&quot; than with letters. Which wouldn&#x27;t be so bad if &quot;.&quot; wasn&#x27;t so common in property &#x2F; method call chains, so you end up with stuff like:<p><pre><code> foo.bar_baz.blah() </code></pre> being difficult to parse when quickly skimming through code. OTOH kebab-case solves this nicely because &quot;-&quot; is not in the same place as &quot;.&quot; in the character cell, and being in the middle, groups more naturally with letters:<p><pre><code> foo.bar-baz.blah() </code></pre> Then again, maybe the established formatting conventions for member access are just suboptimal? Suppose that we put a space before every &quot;.&quot;; then:<p><pre><code> foo .bar_baz .blah()</code></pre>

Good to see some scientific studies on the easier_readability_of_snake_case, versusComparedToCamelCaseBouncingUpAndDown.<p>I tried to convince my co-workers toTransitionFromCamelCase to the world_of_easy_reading_snake_case, but alas, the codebase alreadyUsingCamelCase won.<p>Maybe it&#x27;s the idea that &quot;shorter == better&quot;, or whatever, but if I could choose, I would use snake_case_everywhere man.

An underscore is a word-separating space that selects as part of the sentence.<p>If you use spaces in your normal writing, there&#x27;s no reason you shouldn&#x27;t use spaces in programming - except that a space prevents you from easily selecting the whole phrase, a very common operation programmers face.<p>So they replaced the space with a character that is effectively identical, but works better.<p>Some people figured they could just remove it. WellTellMeThis,DoesItMakeMyTextMoreReadableToYou? If you argue that camelcase is better, then shouldn&#x27;t we adopt it into normal writing too? Why not?

I hacked my editor to make _ look like a small hyphen, and - look like an extra-large em-dash. Then I can work with snake_case underneath, with the pleasing aesthetic of kebab-case. And (for the robot control stuff I work on), negation is an extremely significant operator so I like having it stand out.<p>Screenshots at <a href="https:&#x2F;&#x2F;visibot.com&#x2F;post&#x2F;kebab-case" rel="nofollow">https:&#x2F;&#x2F;visibot.com&#x2F;post&#x2F;kebab-case</a><p>This is for a custom language &amp; IDE, but someday I&#x27;ll get around to making VSCode do the same.

Whatever the standard is for the language. Unless we&#x27;re in a language without a standard (cough cough PHP cough cough). I work in a real snakecase mixed with camelcase PHP codebase at seemingly random intervals. Worst part is that this codebase started only a few years ago.<p>Snake is my preferred. The Python&#x2F;Rust use of snake case and Pascal case for their respective purposes is my favorite.

I&#x27;m more of a camelCase person than a snake_case, probably because I&#x27;ve been writing lots of JavaScript for the last 10 years. But, .... You could argue that camelCase is culturally insensitive given that plenty of languages (Japanese, Chinese, Korean, Hindi, Sanskrit, etc) have no concept of case.<p>Many modern computer languages (JavaScript, Rust, Swift, ...) allow non-ascii identifiers so if you pick camelCase, then someone writing Japanese, Chinese, Korean has no way to obey. That doesn&#x27;t mean snake_case would be all that better in those languages though.<p><pre><code> var 画面＿幅 = ...; var 窓＿縦 = ...; </code></pre> The point is, both camelCase and snake_case are a thing based around western languages.

A non-programming colleague asked me why I use so many underscores “wouldn’t it be easier to type a dash if you can’t use a space?”<p>Why yes. Kebab case would be so much better.<p>Or dots, like R uses.<p>Neither of those are compatible with most languages, but they are a better options for current keyboards.

Everywhere I work seems to settle on CamelCase but reading&#x2F;writing it is annoying because: sSkKcClIwWxXzZvVoO0<p>Goldman Sachs&#x27; Slang language allowed spaces in tokens which was actually much better but I guess your grammar has to support that from the ground up.

Somehow I can&#x27;t believe that it&#x27;s 2023 and &quot;word breaks within identifiers&quot; remains such a fundamental issue in programming. Why are we stuck treating programs as structureless character sequences? We don&#x27;t need to enter them on punch cards or Teletypes anymore.<p>It&#x27;s like if file systems were forever stuck on FAT and everybody was quietly resigned to the idea that you can simply never, ever have more than 8+3 characters in a file name. &quot;That&#x27;s just how computers work. Anyway, I&#x27;ll share you the latest budget spreadsheet on Google Docs, it&#x27;s called BDG2023A.GDC&quot;

Why not both and neither? IMHO this is one of those things where people seem to congregate and advocate for one side religiously, but I don&#x27;t see much value in that. Why can&#x27;t the style simply imply how much scope and importance an identifier has? I&#x27;ve never liked naming dogma, but this is what I find to be natural:<p><pre><code> trivialidentifier - local variables inside a function, usually &lt; 3 words&#x2F;abbrs slightly_important_identifier - function names with limited scope ImportantIdentifier - widely-used functions, class&#x2F;struct names More_Important_Identifier - classes&#x2F;structs that are quite important VERY_IMPORTANT_IDENTIFIER - global constants and (rarely) classes&#x2F;structs</code></pre>

A little confused. People seem to be mixing PascalCase and camelCase in the article and conversation.<p>Assuming as they&#x27;re similar they&#x27;re being used interchangeably in this context?

Do you have a moment to talk about our lord and saviour kebab-case?

<p><pre><code> TypeName, ClassName functionName, methodName variable-name, symbol-name # if possible variable_name, symbol_name</code></pre>

I&#x27;m just mildly annoyed that most languages disallow kebab-case I assume almost entirely so &#x27;-&#x27; can be used for infix subtraction (and maybe decrement) without having to surround it with spaces... not a good tradeoff imo.

It’s obvious that the only value in using different cases is so you can differentiate between different types of thing:<p>1) functionsLikeThis<p>2) variables_like_this<p>3) ClassesLikeThis

If found a paper years ago that was also looking into the readability of different style choices - how easy is it to miss a leading underscore in _field because it is almost a space or to confuse foo_bar and foo bar and other similar stuff mostly related to casing and spacing. I have been trying to find this paper again from time to time for years now without success, is by chance someone aware of it? One thing I remember in more detail is that it was looking at the bounding box shape and how similar they are, it had figures with different styles and bounding boxes drawn around characters and words.

The title needs (2013) at the end, particularly as the results might be different now.

This feels like an issue studied through a keyhole: You can do a study that makes underscores seem advantageous. And in a vacuum, a global with an uppercase name otherwise identical to a local with a lowercase name looks like a debacle waiting to happen. But, with a modern IDE, some combination of color, bold, and italics enables coders to easily distinguish among these seemingly inadvisable symbolic names. And if you want to find all uses of a name, that&#x27;s easy.

I wish a language was designed to allow identifier with space in them without quotes. That is the most readable. But I don’t know the consequences to the rest of the grammar

My style comes from a weird combined history of all the languages I&#x27;ve worked with over the years.<p>I do lowercase snake for_variable_names, camel case forFunctions() and title case ClassNames.<p>In markup, CSS class names are kebob-case but IDs follow snake_case rules (this is so that they can be referenced easily and are valid identifiers in js).<p>I like this approach because I can tell at a glance by the naming convention what kind of identifier I&#x27;m dealing with.<p>I dislike the common js style of everythingIsCamelCase, I find it more difficult to read - and in a language where functions are a primary type, I think it&#x27;s good practice to differentiate stylistically a variable from a function within the closure or prototype chain.

I used to like snake case and variants, but now I like something more elaborate: camel case with semantic underscores:<p><pre><code> Lx_DoThis -- function Lx_DoThis_Gen -- generic impl. Lx_DoThis_Gcc -- GCC-specific LxMyType -- type (class) LxMyType_DoThat -- method </code></pre> That is if I use underscore to separate words, I get names that appear to be composed of an arbitrary number of parts. I want that apparent composition to be meaningful.<p>In a more sophisticated language where types, methods, and variants have native support, this reduces to essentially camel case. Which still looks better to me because a single thing appears as as single word, not a random number of words.

For decades(!) I used CamelCase identifiers, with a convention of using an upper case first letter for constants&#x2F;types&#x2F;functions and a lower case first letter for variables.<p>e.g. MyType myType;<p>I&#x27;m not quite sure what made me switch, but nowadays I used lower case and underscores for all identifiers other than constants, and use a &quot;_t&quot; suffix to distinguish types.<p>e.g. color_t color; string_list_t list;<p>I think it&#x27;s certainly easier on the eyes and more readable.<p>At the end of the day though it&#x27;s personal preference, unless you&#x27;re working on an existing code base where you should adopt the naming and formatting conventions of the code base.

I like the symmetry and readability of “Ada case”: snake_case but with uppercase letters where appropriate, such as acronyms. So instead of <i>XMLHttpRequest</i> or <i>xml_http_request</i>, you would use <i>XML_HTTP_Request</i>.

Interesting results! Underscores do have two built-in caveats that offset the recognition benefit somewhat: more characters to type, and an awkward key to hit (shift + hyphen).

Sometimes I feel these discussions can derail into the realm of being pointless.<p>Computers do not care. Seriously. I don’t know about others, I have far more important and urgent things to worry about in the course of completing a project than this_case or thatCase. I prefer this_case, probably out of habit. Yet, it isn’t important. I’ll use anyCase if required. My bank account also could not care less.

I hate camelCase and Pascal Case.<p>You want arguments? Even though they&#x27;re post rationalizations of what I <i>like</i> best?<p>OK, well first I hate to type caps, then I hate CAPS, so more than one in a word is unbearable. ThenIThinkItsHardToRead. Finally I like that we have a visible symbol to mean space that&#x27;s still visible. Who is going to use it if we programmers don&#x27;t?

kebab-case is best - no awkward shift but more readable than camelcase.

Let&#x27;s just make a language where space isn&#x27;t used to delimit between tokens and let us have spaces in our names.

I would happily trade using some other lexeme for subtraction and negation if it bought me hyphenated identifiers. Code has a fair amount of subtraction but it’s like 2-3 orders of magnitude off from identifier word breaks I’d wager: I take that deal, camel and snake case are both godawful.

Everybody seems to ignore the median case: `some·name` is a valid identifier in surprisingly large set of mainstream languages actually. At least it works just fine with C, C++, Javascript, PHP, Python and Ruby.<p>However it doesn’t in any Shell I tried (bash, fish, zsh) nor C#, Go or Java.

I don&#x27;t see as well as I used to and snake_case is much easier for me to read when scanning through code than camelCase.<p>This may be why I tend to gravitate towards languages like Elixir and Ruby, who prefer snake_case, and away from languages like Go, which use camelCase.

(define kebab-case-for-the-win #t)

Always liked the Ruby convention of PascalCase for constants and under_score for lexicals.

This relates to a hotly contended topic in style-insensitive Nim <a href="https:&#x2F;&#x2F;github.com&#x2F;nim-lang&#x2F;RFCs&#x2F;issues&#x2F;456">https:&#x2F;&#x2F;github.com&#x2F;nim-lang&#x2F;RFCs&#x2F;issues&#x2F;456</a>

Tht GNU project prescribes snake_case:<p><a href="https:&#x2F;&#x2F;www.gnu.org&#x2F;prep&#x2F;standards&#x2F;html_node&#x2F;Names.html" rel="nofollow">https:&#x2F;&#x2F;www.gnu.org&#x2F;prep&#x2F;standards&#x2F;html_node&#x2F;Names.html</a>

Like brace style or a million other nitpicks, I don&#x27;t care. I&#x27;ll use whatever the linter says, so set one up. (though I will say I also hate code styles that don&#x27;t adhere to the general language convention)

I prefer snakecase, but I just use whatever the standard is for the language I&#x27;m using, or the project if it already exists. Staying consistent is most important for these kinds of things.

I just do what is common in the language. Python is interesting as snake case is supposed to be used for the most part but a lot of code seems to use camel case.

CamelCase seems to be preferred by screen readers for the visually impaired. Just recently encountered this on Mastodon with their extensive usage of hashtags...

Isn&#x27;t camelCase CamelCase and CamelCase PascalCase.<p>On a more serious note, I feel like a reasonable middle ground is to agree to use one-word identifiers only.

&quot;A well placed underscore can make the difference between a s_exchange and a sex_change.&quot; - Intel 8048 User Manual cria 1978

This has remained unsettled for 60 years. Perhaps we need a new choice?<p>How about Unicode &quot;Thin Space&quot; 0x2009 for a legal identifier character? (HN isn&#x27;t letting me put the Thin Space in there.)<p>How about Unicode &quot;Middle Dot&quot; 0x00B7 for a legal identifier·character?<p>Best if you aren&#x27;t in a fixed with editor for those.<p>I used middle dot in an experimental language which was Unicode heavy so already didn&#x27;t like fixed width fonts. It parses trivially and reads well.<p>I haven&#x27;t tried the thin space in earnest, but the example code I typed up looked reasonable.

i think you need to do what the built-in functions&#x2F;standard library of language X is doing; if it is camel case then do camel case in your own code - having your own code differ from the convention of the built-in functions&#x2F;standard library is very confusing.

snake_case strains my fingers way more with the excessive reaching to tap shift-underscore.<p>Thank goodness for PyCharm auto-complete. Typing every variable name fully manually in snake_case 24&#x2F;7 everyday was begging for me to develop RSI.

I prefer camelCase for class properties and under_score for local variables.

snake_case for variables and properties, camelCase for methods and classes. That&#x27;s the way I do all my projects, no matter what the &quot;language standard&quot; is.

Best of both worlds: Emacs with M-x glasses-mode

Oh, if only middot had been in the ASCII.

If you find yourself using reallyLongKeywordChainsForIdentifiers then you&#x27;re probably coding in Java and now you have two problems.

under_scores look more &quot;l33t&quot; while CamelCase is more readable.