Psychological effects of coding style (2016)

[avindroth]

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.

[kbutler]

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.

[userbinator]

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.

[enriquto]

> 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.

[michaelbrave]

> 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.

[GoblinSlayer]

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.

[lonelappde]

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

[jka]

One of the things I really enjoy about developing in Python is that - somehow - various code style smells seem fairly apparent when reading the source.

Over time in a well-maintained project there's a tendency for these to clean themselves up, and a feeling that the codebase is in good shape emerges.

Variables become clearly and simply-named, the code starts to read more like a hybrid between a human language and a programming language, and the formatting and syntax become - generally - more straightforward and less 'clever'.

Ideally the patterns and algorithms also gravitate towards readable and efficient patterns (using generators, dunder methods, collection types, and so on where appropriate) until the code feels pleasant to understand and modify.

What's your favourite language for intuitively assessing code quality, and what are the indicators and criteria that you think you use?

[9wzYQbTYsAIc]

There’s something about JavaScript and the length of files, grouping of related lines, and usage of functions that can make it immediately obvious that the quality is either atrocious or decent.

I suppose that that extends in part to any C-style language, but the relative looseness of JavaScript really makes it stand out to me, for some reason.

[beckingz]

SQL.

Because SeLeCt * FrOm <table> is valid.

[doubletgl]

Post title raises an expectation that is hardly met. So what are the psychological effects? Oh I don't know, here's some random thoughts about C++ code style.

[pierrebai]

Worse: its psychological claims are entirely made up and only serve to artificially support his chosen style. It's the worse kind of argument: using made up science that is thus impossible to counter.

[hellofunk]

I've come to appreciate snake case (or hyphenated words in languages like Clojure) because it adds a little extra space in the syntax, and this break is easier to read I think. Long camelCased phrases are often really dense.

[Rainymood]

Personally going to Javascript from Python I actually am starting to prefer camelCase over snake_case, compare LongFunctionVariableFactoryDesigner vs long_function_variable_factory_designer, saves 4 spaces. This is all subjective of course... maybe I've been writing too much Javascript

[jffhn]

I mix both: mainly using camelCase, but using underscores sometimes instead of conjunctions to make things more readable (as you say), especially to make some important meta information stand out (as in "doSomething_locked()" for a method, to indicate that it must be called within some contextual lock).

If using mainly underscores, I don't see what other separator I could use as a higher level separation. Maybe two underscores, but that could too easily be seen as a typo.

[lonelappde]

Unfortunately it makes it hard to see that the word is one word, since many apps draw underscores wrong and because people use (ugh) monospace and even proportional fonts make underscores wider than space.

For programming underscore should be narrower than space.

[Phrenzy]

Just one nitpick that annoyed me. thisIsCamelCase. ThisIsPascalCase.

[3pt14159]

I know it is a bit of an aside, but how on earth did we overload the term camelCase (or CamelCase) when we have PascalCase available?

[asveikau]

> This sort of information can also be conveyed by a documentation comment on the function or a pseudo-keyword:

> #define NATIVE_THREAD_ONLY

> NATIVE_THREAD_ONLY int foo();

> The Win32 API tends to like using these (IN, OUT, INOUT, etc.), but I'm not too fond of them.

The use in Windows is not purely informational or for documentation. They have static analysis tools (prefast and prefix) that actually parse them and issue warnings for incorrect usage in code.

[blarg1]

I've been using Upper Camel Case recently, been causing me problems with having to name my classes and instances differently.

eg previously I would do:

    MyClass myClass

[amelius]

Germans capitalize their nouns in normal language. I wonder what effect that has on their code.

[TsiCClawOfLight]

We code in english, but it does make UpperCamelCase more natural for us.

[zonefuenf]

We mostly use (bad) English in programming contexts.

[Traubenfuchs]

I worked on the code bases of 6 German speaking companies and they were all in English.

[Deradon]

Actually, for me it's the other way round. Sometimes I write german words like "BratwurstBratGerät" (UpperCamelCase)

[9wzYQbTYsAIc]

Also wondering what the psychological effects of IDE, programming language, and SDLC are.

[nxc18]

I work with C#, Xamarin, and Visual Studio.

80% of the time build errors are transient and go away with another F5. Sometimes a build works but is reported as a failure because of a tooling error. ‘Clean’ing the build doesn’t actually do what cleaning should do, so you also have to manually delete intermediate folders to get builds working again. Heaven forbid you name folders appropriately and put your project anywhere other than C:\, because your tools will break with mysterious errors that turn out to be MAX_PATH related. Sometimes when debugging Xamarin iOS apps, Xamarin will deploy old, cached binaries without any indication that something went wrong - really, really great for debugging and issue verification (/s). It won’t be fixed because Microsoft is “prioritizing issues with a broad customer impact”.

I can personally confirm the psychological and physiological effects of at least this particular coding environment: stress, learned helplessness (why the fuck is the answer always just, hit F5 again?), shame and embarrassment (when I tell the team a bug wasn’t fixed, only to learn that visual studio was gaslighting me and deploying cached binaries to the device after a full clean of the project), and high blood pressure from the aforementioned issues.

[trumbitta2]

Stopped reading at "CamelCase" instead of "[Title|Pascal]Case"

[hasa]

Opening curly brace must open a new line!!!!!

[nickcw]

go fmt

End of argument ;-)

[lonelappde]

Doesn't affect capitalization or underscores.