21 ms·
CamelCase vs. underscores revisited (2013)
- yakubin 4y agoDo you have a moment to talk about our lord and saviour kebab-case?
- Waterluvian 4y agoonlyifwehavetimetotalkaboutflatcase
- aloukissas 4y agoALLCAPSCASEPLSFIX
- TylerE 4y agoThErEArRWOrSeOpTiOnSCaSe
- Zamicol 4y agoWe've dubbed this "ridicule" case. Upper case is majuscule. Lower case is miniscule. Mixed case is ridicule. https://en.wikipedia.org/wiki/Letter_case#Terminology https://en.wikipedia.org/wiki/Letter_case#Terminology
- downvotetruth 4y agoWoXCvSZ: randomly only capitalizing C,O,S,V,W,X,Z
- tmtvl 4y agoThere arr worse options? Is that Pirate Case?
- deleted 4y ago[deleted]
- choult 4y agokebab-case = doner meat
- tmtvl 4y agoI'll second that, kebab-case is easy to type, has nice readability, and fits well with regular English constructions like case-sensitive, human-sized, looking-glass, and so on.
- alexisread 4y agoThe problem I've had with kebab case is cross language / devops systems. Some languages and systems don't like kebab case whereas snake case appears more compatible eg. Rpc calls to a named (kebab or snake endpoint).
- djbusby 4y agoDoesn't match \w+
- roenxi 4y agomaybe it is some sort of status thing. since people have to be able to afford a fancy keyboard with a shift key to use camel case or underscores, it shows they can afford nicer things than us kebab-cases. more seriously, it is the unfortunate fact that a lot of systems interpret named-thing and named minus thing. many people don't have the option of using kebab-case. it isn't a good style because it is often impossible to use. which is unfortunate because it is more ergonomic.
- waiting4shoe2 4y agoThe obvious solution is to make `kebab‐case` a name, `kebab−case` a subtraction, and `kebab-case` an error.
- taeric 4y agoI thought this was mainly because of infix math operators?
- txbuck 4y agoThe fact that kebab-case support is a rarity constantly boggles my mind, nevermind that it isn't the de facto default for any language created after *sh/lisp. Readability, ease-of-typing, parallel with the way it's used in (Romantic) natural language. If I were writing a new language I intended to popularize this would be one of the features I would emphasize. Spicy semi-snarky aside: if your counterpoint is that kebab-case prevents crushing your arithmetic operators together, I strongly suggest you either reconsider or never write any code you think may be read by another human being (and possibly yourself).
- Arch-TK 4y agoIt's a bit hard to parse it outside of languages like lisp because of infix.
- thaumasiotes 4y agoInfix has nothing to do with it. We can already parse expressions of the form "x - 20". The change would be to stop interpreting "x-20" as being the same set of three tokens as "x - 20".
- taeric 4y agoThat is the point, though? Is "x- 20" the same as "x - 20" the same as "x -20" In the vast majority of modern programming languages, that is a yes. If you allowed dashes in the names, not so much. Now, I grant the point that it is doable. But the point is it complicate things. Now, fair, we have some of these complications already by virtue of the fact that we allow numbers in variable names. "foo3" is already allowed in many languages, and that clearly gets altered as you add space between the characters.
- thaumasiotes 4y ago> Is "x- 20" the same as "x - 20" the same as "x -20"[?] In the vast majority of modern programming languages, that is a yes. Is that really true? I wouldn't exactly feel comfortable with "x -20", though I suspect you're right about at least a large number of languages determining the meaning of the hyphen through local syntactic context ("I just saw an identifier; that must be a non-unary hyphen"). Now I'm interested in whether the corpus of existing code shows any bias between "y = -x" (perfectly allowed, I think) and "y = -1 * x".
- inopinatus 4y agoI’ve always liked the readability, but interaction is a problem when many UIs treat the hyphen as a break character. Most (all?) browsers do, and even some (albeit not good) IDEs cannot be configured otherwise. When you’re in a hurry, it’s easy to miss a bit off the end.
- layer8 4y agoLuckily Unicode has the non‑breaking hyphen U+2011. This‑is‑a‑long‑identifier‑that‑should‑not‑break‑at‑any‑of‑the‑hyphens.
- inopinatus 4y agoAlas, that doesn't seem to be a general solution. Sure, it doesn't cause line or selection break in my IDEs, nor does it line break in browsers, but it's still a selection break in everything except IDEs (such as all the web and chat services developers use to talk about code), it's harder to type, and as a homoglyph it's super problematic to grep or index identifiers that use it. This last consideration could potentially even increase an attack surface. I'd suggest that it's feasible if we lived our entire developer lives inside a monoculture that adopted it, but that just ain't reality. This all adds up to "why I do not kebab my identifiers".
- infradig 4y agoI had never heard of kebab-case before as kebab refers to cooked chunks of meat.Soon it dawned that shish (meaning skewer) was meant, as in shish-kebab-case. Sorry to be that guy.
- bsder 4y agoThen we have to talk about the devil token which indicates variables/names. You can't have infix minus and kebab case without something to differentiate between the two. Lisp chooses to remove infix minus. Other than old-school BASIC, I don't remember anything else which uses tokens for variables.
- yakubin 4y ago> Lisp chooses to remove infix minus. Infix has nothing to do with it. - refers to the subtraction function regardless of whether it is placed in prefix or infix position. Infix will trigger a type error, not a syntactic error — it will tell you that e.g. it cannot call a fixnum. Lisp quite ordinarily requires function names to be separated from their arguments by spaces, which is just a special case of the rule that atoms need to be separated by spaces. That’s all.
- lispm 4y agoIn many Lisps (+ + +) means this: call the function named + on the two values from the variables named +. The function is then a function object and the values of + can be anything they are currently set to. Thus + serves more than one purpose: function or variable and both may be different values. Thus the position actually matters. What we have below the Lisp syntax are s-expressions: nested lists of symbols and other objects. In s-expressions, symbols need to be separated by whitespace, parentheses or possibly by some special character type (-> terminating character). Characters like +, -, /, *, _, ... are valid characters for any symbols. Thus Lisp does not require functions to be separated by characters but symbols. That's a part of the reader mechanism for reading s-expressions (-> symbolic expression).
- MetaWhirledPeas 4y agoInteresting 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).
- Waterluvian 4y agoI’m interested in what kinds of software development jobs have you churning out so much code that these things practically matter. I have found that most of the time you can just automatically switch between the two cases, too. So maybe it’s moot.
- innocentoldguy 4y agoTo overcome this issue, I switched to the Dvorak keyboard layout and use Karabiner Elements to remap some of my keys. The result is that I can type underscores on the home row and parenthesis on my shift keys (tap == parenthesis and hold == shift). This has eliminated the RSI pain I used to feel from these hard-to-reach keys.
- kbd 4y agoCame here to say this. Underscore/dash is on the home row in Dvorak, making snake_case/kebab-case way more natural to type. Cool trick about mapping shift keys with Karabiner-Elements. I do that with my caps lock to create a "hyper" key: tapping it brings up Alfred, using it in a chord is "hyper", and long pressing caps lock maintains its default behavior.
- inDigiNeous 4y agoTyping is not the slow part. Reading and understanding the code is what takes most of the time, and is something that should be optimized. But '_' might be difficult to hit on non-US keyboards though.
- TylerE 4y agoIt’s not really that great on US boards, either. Way off to in a corner, and requiring shift.
- CoolGuySteve 4y agoEverywhere I work seems to settle on CamelCase but reading/writing it is annoying because: sSkKcClIwWxXzZvVoO0 Goldman Sachs' Slang language allowed spaces in tokens which was actually much better but I guess your grammar has to support that from the ground up.
- dahfizz 4y agoUnicode has lots of space characters, maybe we could choose one to be a space that is legal in identifiers.
- innocentoldguy 4y agoI don't see as well as I used to and snake_case is much easier for me to read when scanning through code than camelCase. 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.
- inDigiNeous 4y agoGood to see some scientific studies on the easier_readability_of_snake_case, versusComparedToCamelCaseBouncingUpAndDown. I tried to convince my co-workers toTransitionFromCamelCase to the world_of_easy_reading_snake_case, but alas, the codebase alreadyUsingCamelCase won. Maybe it's the idea that "shorter == better", or whatever, but if I could choose, I would use snake_case_everywhere man.
- brookst 4y agoI am pro-snake myself, but those that use double underscores, especially in a meaningful way, are drilling holes in our boat.
- spookthesunset 4y agoWhat is a double underscore? hello__world?
- jayknight 4y agoYep, or "dunder" as it's often called in the python world.
- eddsh1994 4y ago__special_functions__ __privateish_variable Etc, in the land of Python
- goodoldneon 4y agoI wish Python enforced private attributes. I once worked in a codebase where this was roughly true: _usually_private_but_ok_to_access_if_you_are_knowledgeable __private_unless_you_need_an_escape_hatch ___absolutely_private_except_for_a_few_times
- brookst 4y agoI mean doesn’t it make you want to make ___________super_ultra_private, with an accessor that corrupts the filesystem and hangs if you so much as look at it?
- frereubu 4y agoThe title needs (2013) at the end, particularly as the results might be different now.
- 0x073 4y agoI prefer camelCase for class properties and under_score for local variables.
- jjice 4y agoWhatever the standard is for the language. Unless we'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. Snake is my preferred. The Python/Rust use of snake case and Pascal case for their respective purposes is my favorite.
- doutunlined 4y agoNo linter? Seems like a quick thing to standardize
- jjice 4y agoI actually did set up our linter but can't enforce the casing since so much of the codebase is all over the place and leadership didn't want to take any risk with an automatic conversion :shrug:.
- tredre3 4y ago> Unless we're in a language without a standard (cough cough PHP cough cough) Frameworks, IDEs, and linters all follow the PSR-2: https://www.php-fig.org/psr/psr-2/ https://www.php-fig.org/psr/psr-2/ . It is indeed common for new developers to not know or care about it, but most professional shops I've been to adhere to it unless they're working on very legacy code.
- jjice 4y agoHuh, thanks for the link. I swear that when I read that document (or a similar PSR) about a year ago, it specified that it didn't take a stance for method names (or maybe regular function names). I wonder why I thought that or if I read it someone else. Thanks for that.
- dec0dedab0de 4y agoI prefer snakecase, but I just use whatever the standard is for the language I'm using, or the project if it already exists. Staying consistent is most important for these kinds of things.
- metadat 4y agosnake_case strains my fingers way more with the excessive reaching to tap shift-underscore. Thank goodness for PyCharm auto-complete. Typing every variable name fully manually in snake_case 24/7 everyday was begging for me to develop RSI.
- inopinatus 4y agoAlways liked the Ruby convention of PascalCase for constants and under_score for lexicals.
- jacobsenscott 4y agoIn ruby anything that starts with a capital is a constant, but PascalCase is only used for ClassNames and ModuleNames, and ALL_CAPS_SNAKE_CASE = "is used for constant values". Unless you are some kind of monster anyway.
- inopinatus 4y agoQuite right, that’s the full picture. Honestly though I am that kind of monster
- jacobsenscott 4y agokebab-case is best - no awkward shift but more readable than camelcase.
- pyrolistical 4y agoI 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
- jfk13 4y agoTry Algol68.
- thaumasiotes 4y agoUnderscores are visually very similar to spaces. Their major problem is unrelated to their appearance - it's that you have to use a key combination in order to type them on a standard keyboard. The obvious solution would appear to be to use better keyboards, but I don't even see anyone suggesting that. But note that the lisp identifier style, words-separated-by-hyphens, is better than using underscores despite being less legible. It's purely a matter of how easy it is to type the separator. ("Standard" languages don't allow hyphens in identifier names because they want to allow subtraction without requiring a space between the subtraction operator - and the two operands. In Lisp, spacing around an operator, including the subtraction operator, is required. You could go a long way in a C-like language by just requiring spacing around operators and immediately being able to allow hyphens in identifiers.)
- downvotetruth 4y ago> Their major problem is unrelated to their appearance Shift key is a problem for all the shifted only chars. Their major problem is appearance: a single underscore '_' vs underscores '__' . Concatenated glyphs are hard to discern due to only distinguisher being width.
- thaumasiotes 4y agoI have no idea what you're trying to say. You just compared underscores with underscores; relative to underscores, underscores cannot even theoretically have any problems at all.
- deleted 4y ago[deleted]
- deleted 4y ago[deleted]
- teddyh 4y agoBest of both worlds: Emacs with M-x glasses-mode
- jws 4y agoThis has remained unsettled for 60 years. Perhaps we need a new choice? How about Unicode "Thin Space" 0x2009 for a legal identifier character? (HN isn't letting me put the Thin Space in there.) How about Unicode "Middle Dot" 0x00B7 for a legal identifier·character? Best if you aren't in a fixed with editor for those. I used middle dot in an experimental language which was Unicode heavy so already didn't like fixed width fonts. It parses trivially and reads well. I haven't tried the thin space in earnest, but the example code I typed up looked reasonable.
- Zigurd 4y agoThis 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's easy.
- int_19h 4y agoWhile 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 "." than with letters. Which wouldn't be so bad if "." wasn't so common in property / method call chains, so you end up with stuff like: foo.bar_baz.blah() being difficult to parse when quickly skimming through code. OTOH kebab-case solves this nicely because "-" is not in the same place as "." in the character cell, and being in the middle, groups more naturally with letters: foo.bar-baz.blah() Then again, maybe the established formatting conventions for member access are just suboptimal? Suppose that we put a space before every "."; then: foo .bar_baz .blah()
- layer8 4y agoAlso, when using a proportional font it gets worse, because underscores become wider (significantly wider than a normal space) and dots become narrower, suggesting the wrong grouping in syntax like `foo.bar_baz.blah()` (the words in "foo.bar" are closer together than in "bar_baz"), or just when having a snake_case_identifier in normal text ("a snake" is close together than "snake_case", etc.). This problem is less pronounced with kebab-case. Underscores can also clash with hyperlink underlines, depending on the font. I've seen documentation with linked identifiers where that was confusing.
- kelnos 4y agokebab-case is fine in strings, but many languages will parse that as BinaryExpression(Identifier("kebab"), Identifier("case"), Operator.MINUS) I admit there's personal preference and just quirks of vision involved, but I don't think I've ever had an issue distinguishing '_' and '.'. One thing you can do, which helps also with breaking up long chains of calls that would give you a really long line, is break it up with newlines, e.g.: foo .bar_baz .blah()
- int_19h 4y agoI believe that syntactic limitation to be a historical mistake that we keep doubling down on for no good reason. There's really no practical purpose to parse a-b as (a - b), as evidenced by popular style conventions for pretty much ever language with a binary minus operator.
- bitwize 4y ago(define kebab-case-for-the-win #t)
- userbinator 4y agoWhy 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't see much value in that. Why can't the style simply imply how much scope and importance an identifier has? I've never liked naming dogma, but this is what I find to be natural: trivialidentifier - local variables inside a function, usually < 3 words/abbrs slightly_important_identifier - function names with limited scope ImportantIdentifier - widely-used functions, class/struct names More_Important_Identifier - classes/structs that are quite important VERY_IMPORTANT_IDENTIFIER - global constants and (rarely) classes/structs
- __ryan__ 4y agoWhy can't the style simply imply how much scope and importance an identifier has? Because lack of underscores doesn’t unanimously imply lack of importance or scope.
- kelnos 4y agoThat seems less understandable to me. I think it's easier to grok if certain classes of things always use the same casing. So all functions would use snake_case, type names would use PascalCase, global constants use UPPER_CAMEL_CASE, etc. "Importance" is subjective, and regardless, IMO not really an important measure of anything.
- layer8 4y agoBecause everyone will have a different opinion about the importance of any given name.
- andreareina 4y agoHell I'll have differing opinions about the importance of the same name at different times of day.
- rootusrootus 4y agoThat's sort of what Python's PEP8 recommends. CamelCase for class names, snake_case for the rest, and SNAKE_CASE for constants.
- MichaelMoser123 4y agoi think you need to do what the built-in functions/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/standard library is very confusing.
- asiachick 4y agoI'm more of a camelCase person than a snake_case, probably because I'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. 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't mean snake_case would be all that better in those languages though. var 画面＿幅 = ...; var 窓＿縦 = ...; The point is, both camelCase and snake_case are a thing based around western languages.
- Pxtl 4y agoLet's just make a language where space isn't used to delimit between tokens and let us have spaces in our names.
- layer8 4y agoI'm slightly conflicted about CamelCase. On the one hand it can be somewhat harder to read, on the other hand it does have a number of benefits: - Typing "ABC" Ctrl+Space gives me code completion for AsynchronousByteChannel (and the like), whereas "abc" Ctrl+Space gives me code completion only for what strictly starts with "abc". I.e. uppercase means "words starting with that letter". Of course you could have something equivalent for non-CamelCase naming conventions, but for CamelCase it is a very natural fit. - It provides the two variants lowerCamelCase and UpperCamelCase (often used for variable names vs. type names), whereas lower-kebab-case & Upper-Kebab-Case or lower_snake_case & Upper_Snake_Case seem more awkward in comparison (more keystrokes for the "upper" variant). - When lowerCamelCase is used for function names, the case distinction often maps nicely to verb + noun (`createFooBar()`, `validateBazQuz()`). - You still have underscore available to occasionally "index" a name (`transmogrifyFooBar()`, `transmogrifyFooBar_unchecked()`) unambiguously. - The fact that CamelCase does not match normal English spelling has the advantage that it can'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. - Minor advantage: You can fit slightly more words into a line. Apart from that, I'm pro-kebab-case.
- m463 4y ago> typing "ABC" Ctrl+Space gives me code completion for AsynchronousByteChannel that's clever. I suspect you could add editor logic to do that with underscores too.
- pocketarc 4y agoIDEA does something similar - you just type, and as long as the characters are found in the string in the order you typed them, it doesn't matter what's separating them, it will find a match. So ABC would match AsynchronousByteChannel, and abc would match asynchronous_byte_channel. As would asyncbc or whatever else your brain comes up with. It's quite nice.
- moring 4y ago
- claytongulick 4y agoMy style comes from a weird combined history of all the languages I've worked with over the years. I do lowercase snake for_variable_names, camel case forFunctions() and title case ClassNames. 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). I like this approach because I can tell at a glance by the naming convention what kind of identifier I'm dealing with. 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's good practice to differentiate stylistically a variable from a function within the closure or prototype chain.
- wodenokoto 4y agoA 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?” Why yes. Kebab case would be so much better. Or dots, like R uses. Neither of those are compatible with most languages, but they are a better options for current keyboards.
- tzs 4y agoOffhand I can't think of a good reason why many of the popular languages couldn't allow space. Most either don't have any places where you can have a keyword adjacent to a variable, or would just have to not allow variables containing space if the first word in the name matches a keyword.
- thefaux 4y agoIt is significantly easier to write a parser if you assume names don't have spaces in them. I also tend to think that names with spaces would be confusing to read as well: you'd end up with statements like this `x = foo bar baz (buzz)`. Certainly not unparseable, but I don't think the convenience is worth giving up space as an almost universal token separator.
- collyw 4y agoI imagine it's a lot harder to read as well - as in read and parse in your head
- cpeterso 4y agoI like the symmetry and readability of “Ada case”: snake_case but with uppercase letters where appropriate, such as acronyms. So instead of XMLHttpRequest or xml_http_request, you would use XML_HTTP_Request.
- quesera 4y agoIt has always kind of bothered me that XMLHttpRequest was neither XmlHttpRequest, nor XMLHTTPRequest. There's probably some reason buried deep in the Microsoft (formerly Micro-Soft!) project docs.
- kybernetyk 4y agounder_scores look more "l33t" while CamelCase is more readable.
- every 4y agoCamelCase seems to be preferred by screen readers for the visually impaired. Just recently encountered this on Mastodon with their extensive usage of hashtags...
- robomartin 4y agoSometimes I feel these discussions can derail into the realm of being pointless. 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.
- Mikhail_Edoshin 4y agoI used to like snake case and variants, but now I like something more elaborate: camel case with semantic underscores: Lx_DoThis -- function Lx_DoThis_Gen -- generic impl. Lx_DoThis_Gcc -- GCC-specific LxMyType -- type (class) LxMyType_DoThat -- method 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. 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.
- emodendroket 4y agoLike brace style or a million other nitpicks, I don't care. I'll use whatever the linter says, so set one up. (though I will say I also hate code styles that don't adhere to the general language convention)
- r2b2 4y agoTypeName, ClassName functionName, methodName variable-name, symbol-name # if possible variable_name, symbol_name
- kovac 4y agoIsn't camelCase CamelCase and CamelCase PascalCase. On a more serious note, I feel like a reasonable middle ground is to agree to use one-word identifiers only.
- pleb_nz 4y agoA little confused. People seem to be mixing PascalCase and camelCase in the article and conversation. Assuming as they're similar they're being used interchangeably in this context?
- tmtvl 4y agoLet's just call it BactrianCase or dromedaryCase.
- danbruc 4y agoIf 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.
- transfire 4y agoOh, if only middot had been in the ASCII.
- skerit 4y agosnake_case for variables and properties, camelCase for methods and classes. That's the way I do all my projects, no matter what the "language standard" is.
- reportgunner 4y agoThis is the way
- cassepipe 4y agoI hate camelCase and Pascal Case. You want arguments? Even though they're post rationalizations of what I like best? 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's still visible. Who is going to use it if we programmers don't?
- popcorncowboy 4y agoAnd I hate snake_case. You want post rationalized arguments? Even though this is a parody to bikeshed on a polemic? OK, well first I hate to type underscores, then I hate "shift -" because it's RSI inducing and unbearable. then_i_think_this_is_ugly. Finally I hate that we use a symbol so removed from natural human writing it screams subservience to the machine. Who is going to rebel if we programmers don't?
- tlb 4y agoI 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. Screenshots at https://visibot.com/post/kebab-case https://visibot.com/post/kebab-case This is for a custom language & IDE, but someday I'll get around to making VSCode do the same.
- gpderetta 4y agoemacs has glasses-mode to switch visually between snake case and camel case. I'm sure it should be easy to hack to support kebab-case in... case it doesn't already.
- pavlov 4y agoSomehow I can't believe that it's 2023 and "word breaks within identifiers" remains such a fundamental issue in programming. Why are we stuck treating programs as structureless character sequences? We don't need to enter them on punch cards or Teletypes anymore. It'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. "That's just how computers work. Anyway, I'll share you the latest budget spreadsheet on Google Docs, it's called BDG2023A.GDC"
- iainmerrick 4y agoWhy are we stuck treating programs as structureless character sequences? The converse question is “why aren’t we all doing visual programming?” I think the answer is that plain text actually works out better for most purposes. It’s tool-agnostic, it’s reasonably easy to manage in source control, it’s reasonably easy to repair by hand when things get broken, it’s reasonably easy to maintain as tools get upgraded. Yes, it sucks in many ways. Spaces in filenames messing up shell scripts is my own pet peeve. On balance I think it’s good that you can write programs in a generic raw text editor, with things like syntax highlighting, formatting and completion being very-nice-to-have added extras. If you couldn’t so much as double-click to select an identifier without tool assistance, that would be pretty annoying when it (inevitably) sometimes goes wrong.
- pavlov 4y ago> "The converse question is 'why aren’t we all doing visual programming?'" IMO this is not the right framing because it suggests a dichotomy where we must choose between a CLI or some kind of GUI node spaghetti editor. It's perfectly possible to add structure to data and still edit it on a CLI. After all that's how file systems work. We don't address our data by raw sectors on disk; instead there are layers of data structures on top, and they're designed to be reasonably easy to use via CLI through concepts like directories and files (rather than having to poke raw inodes for example). The problem is that a tree of directories and files is clearly not a very good abstraction for structuring programs, but there hasn't been a lot of experimentation on how we could layer a more suitable data structure on top. Smalltalk had a completely different (and incompatible) approach with its image model. It kind of feels like everyone in the PC space looked at Smalltalk, said "oh that's not going to work either", and then gave up on trying to improve program structure.
- benreesman 4y agoI 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.
- moring 4y agoI'd also happily accept '-' to mean 'minus' when separated by spaces and be part of an identifier if not. You'd probably not want to space-separate a unary minus, so identifiers could not start with a hyphen, but that's ugly anyway. (BTW so is starting an identifier with an underscore, so either we'd have to finally come up with a better scheme for "private" identifiers, or just keep the underscore for that purpose.)
- teddyh 4y agoTht GNU project prescribes snake_case: https://www.gnu.org/prep/standards/html_node/Names.html https://www.gnu.org/prep/standards/html_node/Names.html
- cb321 4y agoThis relates to a hotly contended topic in style-insensitive Nim https://github.com/nim-lang/RFCs/issues/456 https://github.com/nim-lang/RFCs/issues/456
- The_Colonel 4y agoWow, I didn't know this is a thing. One of the good things about Java ecosystem is that casing and indentation are not really debated (apart from few minor corner cases) and basically everyone follows the standard. I'm kind of fine with any reasonable coding standard, but I can't stand the debates. Endless bikeshedding.
- cb321 4y agonimpretty (like gofmt & etc.) was actually mentioned (buried within that large discussion) as a way for Nim to go full sensitivity but avoid the debates. :-)
- dools 4y agoIt’s obvious that the only value in using different cases is so you can differentiate between different types of thing: 1) functionsLikeThis 2) variables_like_this 3) ClassesLikeThis
- Jaxan 4y agoWhat if a variable is also a function?
- dools 4y agoThen it’s a variable.
- flyingfences 4y agovariable_or_function CONSTANT_OR_MACRO StructOrOtherType
- hypertele-Xii 4y agoAn underscore is a word-separating space that selects as part of the sentence. If you use spaces in your normal writing, there's no reason you shouldn't use spaces in programming - except that a space prevents you from easily selecting the whole phrase, a very common operation programmers face. So they replaced the space with a character that is effectively identical, but works better. Some people figured they could just remove it. WellTellMeThis,DoesItMakeMyTextMoreReadableToYou? If you argue that camelcase is better, then shouldn't we adopt it into normal writing too? Why not?
- paulcole 4y agoCamelCase doesn’t need to be more readable, it just needs to be readable enough. And when you keep names short, it is.
- nmz 4y ago3 wordsIsTheLimit, afterThat, its_better_to_use_underscores.
- __ryan__ 4y agoThere’s plenty of things that are done in code that we don’t adopt in prose and vice versa. You could just as easily make the case for adopting underscores in place of spaces in prose to increase readability, but we haven’t done that. In code, you have to balance readability in many contexts. Snake case and kebab case look more readable in isolation, but do they look better when used as part of a larger expression, for example part of a chain of member access and method calls and argument passing? I don’t think the answer is obvious, and it probably depends on other formatting affordances (e.g. breaking the expression up on multiple lines). I’m on mobile and I don’t trust HN’s formatting to do any justice with examples, but it might be worth trying it out in your code editor.
- TomSwirly 4y agoIt'sSimplyNotVeryNaturalToReadTextWhereCapitalLettersTakeThePlaceOfSpaces,AndThereIsThe"NASAIs"ProblemToo. In_most_fonts,_the_underscore_character_is_visually_like_a_space,_and_you_can_distinguish_"NASA_is"_and_Mike_vs_mike.
- thrown1212 4y agoIf you find yourself using reallyLongKeywordChainsForIdentifiers then you're probably coding in Java and now you have two problems.
- osigurdson 4y agoI 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.
- ldh0011 4y agoI'm just mildly annoyed that most languages disallow kebab-case I assume almost entirely so '-' can be used for infix subtraction (and maybe decrement) without having to surround it with spaces... not a good tradeoff imo.
- HarHarVeryFunny 4y agoFor decades(!) I used CamelCase identifiers, with a convention of using an upper case first letter for constants/types/functions and a lower case first letter for variables. e.g. MyType myType; I'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 "_t" suffix to distinguish types. e.g. color_t color; string_list_t list; I think it's certainly easier on the eyes and more readable. At the end of the day though it's personal preference, unless you're working on an existing code base where you should adopt the naming and formatting conventions of the code base.
- psychoslave 4y agoEverybody 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. However it doesn’t in any Shell I tried (bash, fish, zsh) nor C#, Go or Java.
- rpaddock 4y ago"A well placed underscore can make the difference between a s_exchange and a sex_change." - Intel 8048 User Manual cria 1978