Comment by avindroth | Hacker News Reader

Comment by avindroth | Hacker News Reader

I occasionally write for myself and for a casual audience, and I will sometimes write with proper caps... and other times write with no caps at all. (Hackernews and this particular timing/subject makes this comment more suitable to proper caps, for instance)

I think CamelCase captures a kind of properness that underscore_style does not. If you look at just texts, older people use proper caps, but younger people don’t. Of course this is not out of laziness — but because caps and no caps leave different psychological imprints.

‘Hey!’ and ‘hey’ are totally different and convey very different meanings. (-> medium is the message)

Particularly meme-y, edgy, distant, and cool content likes no caps (e.g. Billie Eilish song titles).

As to programming, I like nocaps because it makes things less formal. It makes things more bound to change, because code should read more live than fixed. It’s more sandbox and less tablet.

This is why to me Haskell, in all its greatness, feels too rigid. Too many caps (among other things). There has to be a psychologically lighter version of ‘Maybe Int = Just Int | Nothing’. Feels too much like rules written, less exploratory.

Also caps in general are more psychologically distant (and effortful) than the underscore approach, because it uses lots of chord+keys (caps) instead of single keys. Swapping dash and underscore (and dvorak and smart hotkey handling) also achieve similar effects. Small costs add up, especially when lots of tiny decisions are involved.

Psychology of representation is a subtle art that is often overlooked. You need time to do it, and most people don’t have the time nor the leisure. Much like yak-shaving.

But it is also important to remember that different people will have different psychological responses to those different styles.

It's more than just the in-group vs get-off-my-lawn, but individual, regional, ethnic, and language backgrounds come into play.

For example, a self-service product was routinely abbreviated "SS", but a Dutch colleague would never use the abbreviation (WWII history).

What you find psychologically distant, others may find comfortingly structured. Rather than be liberating, lack of capitalization and punctuation my be chaotic and imprecise.

There's no substitute for user (audience) testing.

My style could be summarised as: Very_Very_Important, SomewhatImportant, mostly_important, notveryimportant.

I personally hate the "camelcase everywhere" style, and for that matter, verbose names. Opponents tend to claim that it makes the code easier to read, but I've found that after more than a few minutes of staring at code like that, the ThingsScreamingAtYouEverywhere just get tiresome and start to obscure the actual structure, as well as making it difficult to distinguish between two very long identifiers that differ only slightly in their tail.

This may also be because the majority of the time I've (been forced to) work with that style, it's been "enterprisey" code that's full of AbstractPatternDecoratorProxySingletonFactoryFactory noise.

Agreed. There has to be a middle ground, something fairly concise but just enough words to distinguish things.

For some reason Hungarian fell out of favor (pedants etc making noise) but something similarly concise would be helpful. Folks say "Look at that alphabet soup! Completely unreadable!" but it takes just a minute or two to learn whatever lettered convention is in use.

Truth is, pedants and complainers will 'ruin anything'. I advise, choose something fairly concise, write a comment somewhere (README?) and get on with it.

Imagine if it was abstractpatterndecoratorproxysingletonfactoryfactory.

Now lets throw in Hungarian Notation!

oAbstractpatterndecoratorproxysingletonfactoryfactory

C++ constructor:

OAbstractpatterndecoratorproxysingletonfactoryfactory::OAbstractpatterndecoratorproxysingletonfactoryfactory(){}

C style: abspdpsfacfac

(even has pdp in it, truly C)

$VERY_IMPORTANT_VARIABLE_DO_NO_OVERRIDE

> caps and no caps leave different psychological imprints.

I agree with this sentence, but in my case it applies in the opposite sense as yours. For me, the paragon of seriousness and professional writing is K&R, where no caps are ever used on function nor variable names. Any mixed case identifier, or worse, camel case, is a deviation from that utmost formal elegance, thus I subconsciously interpret it as amateurish or ugly.

> because it makes things less formal. It makes things more bound to change, because code should read more live than fixed. It’s more sandbox and less tablet.

Reminded me of something I read once about someone using comic sans to program with because it made it feel more approachable and less permanent.

Yeah I wrote for a while in Courier New and it had a more 'work-in-progress' feeling as opposed to Times New Roman or even Avenir.

Symbols with broad scope like functions, fields and types are psychologically heavy because of their broad scope, caps thus reflect their higher weight. Function parameters and local variables have narrow scope, so they are psychologically light and are thus lower case.

Underscore is a chord key. That's it's main flaw, along with taking up an extra character of our precious 80-char budget.

Uppercase letters are chord keys as well.

And so are every upper-case letter. And if you want, you can modify your keyboard layout to swap the - and _ and no longer have to reach for the shift key at all.

(I'll just laugh at the argument that underscores causes problem with line width limitations.)

I prefer the underscore style as I find the names more legible, it's easier to see where each particle starts and ends. It's particularly evident when using acronyms: read_JPEG_image is much more legible than ReadJPEGImage. Many style guide resort to lower-casing acronym due to that: ReadJpegImage.

On a tangent: Emacs has a venerable minor mode called "glasses-mode" that inserts visual underscores whenever the case changes in the middle of a word. So "readJPEGFile" is displayed on screen as "read_JPEG_File". (This is just a display trick, the file itself is not modified.) It can be handy for reading denseCamelCaseCode, esp. when your eyes are tired.

For what it's worth, I think this is why kebab-case originally became popular in lisp-land. We used it significantly in our JS style guide at $PREVIOUS_FIRM.

I suspect the real reason is the same reason why you wrote "kebab-case" and "lisp-land" and not "kebab_case" and "lisp_land".

The main flaw is that the underscore is not actually a character in the English typographical language; it's a typewriter feature for going back and underlining text.

When used for joining words, it looks terrible, like a hyphen that has lost its suspenders and fallen to the floor.

I would write kebab case even if hyphen required the shift, and underscore didn't.

`kebab-case` isn't perfect. It works just fine in a prefix notated language such as LISP, but less so in an infix language. I suppose you could require significant whitespace to differentiate `a-b` from `a - b`, but even that is a little counterintuitive to read. `snake_case` is popular in both Python and Ruby, and canonical in the former. Moreover, it's canonical in SQL. Frankly, even though I like the idea of kebab casing, without the ecosystem around it changing, I have historically just apathetically accepted camelCase and snake_case, and despite being a Python lover at my core, I've gravitated more and more to camelCase as time has gone on because I definitely do find capitalization easier to parse than hyphens or underscores. I like it for the same reason I like significant whitespace. Yes, it's more painful to parse and design a language around, but it's that much closer to pseudocode.

a - b certainly isn't counterintuitive to read, and neither is max-pos - cur-pos.

But is max-pos - cur-pos better to read than maxPos - minPos or max_pos - cur_pos? I would say no to both cases.

Reply on news.ycombinator.com