
Psychological effects of coding style (2016) - luu
https://www.devever.net/~hl/codingstylepsych
======
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.

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

~~~
GoblinSlayer
Imagine if it was abstractpatterndecoratorproxysingletonfactoryfactory.

~~~
ehnto
Now lets throw in Hungarian Notation!

oAbstractpatterndecoratorproxysingletonfactoryfactory

~~~
TheOtherHobbes
C++ constructor:

OAbstractpatterndecoratorproxysingletonfactoryfactory::OAbstractpatterndecoratorproxysingletonfactoryfactory(){}

~~~
GoblinSlayer
C style: abspdpsfacfac

(even has pdp in it, truly C)

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

~~~
searchableguy
I don't understand why js psychologically force me to write smaller files.

Whenever I write in any other language, I feel totally fine with 1000+ LOC in
single file but when it's js, the zeitgeist force me to put them into bunch of
folders exporting from an index.ts

I can't put my fingers on it.

~~~
krebs_liebhaber
I feel queasy when I see a 1000-line file in any language, but JS in
particular is just... yikes. I guess it's because the language has a
reputation for being inconsistent (whether that's deserved is another thing
entirely), so the less you have to reason about, the better.

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

~~~
Phlogistique
I find this comment and the one above way too harsh. The author of the article
does not make any strong claim at "science"; it is written as a deliberately
subjective series of musings.

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

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

~~~
stronglikedan
Underscores to separate words, and dashes to separate clauses. E.g.,
'do_something-locked()'. I personally don't use this style in code, but it's
my go-to file naming convention to avoid whitespace. E.g.,
'my_awesome_report-20200428.pdf'

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

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

~~~
elliekelly
Can you explain this phrase to a non German speaker? I think ”bratwurst brat
gerät” very roughly translates to “bratwurst roasting device” which makes me
think of kabab-case instead of UpperCamelCase. German phrases are usually
pretty intuitive but I don’t understand this one at all.

~~~
ratww
Germans write those compound words with "German casing", like this:
"Bratwurstbratgerät" [1]. It is just a roaster for bratwursts. In other
languages like english sometimes compound words are kebab cased, like yes. [2]

Btw, for kebabs you probably want a Dönnergrill :)

[1]
[https://en.wikipedia.org/wiki/Compound_(linguistics)#Germani...](https://en.wikipedia.org/wiki/Compound_\(linguistics\)#Germanic_languages)

[2]
[https://en.wikipedia.org/wiki/English_compound](https://en.wikipedia.org/wiki/English_compound)

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

~~~
GoblinSlayer
I work with C#, Visual Studio. 1 level of folder nesting was more than enough
for me so far. I see a deeply nested folder hierarchy as a code smell, I once
had to walk one such hierarchy to convert files into utf8, and it was a
massive pain.

~~~
nxc18
The issue is with forms and the like, the tooling creates a lot of
intermediate files based on the names of classes and whatnot. If you’re
following the ‘best practice’ naming patterns, and have your code in a user
folder, it’s likely you’ll run out of characters. I don’t use more than 2
folder levels ever, but I have a product with wordy names.

~~~
GoblinSlayer
src/MyProductDeluxe9999LimitedUnleashed/Branch/MyProductForms/AboutForm.Designer.cs
- 83 characters, about 1/3 of path length limit.

~~~
nxc18
C:\Users\user\Documents\Visual Studio
2019\Projects\myrepo\src\MyProductDeluxe9999LimitedUnleashed\Branch\MyProductForms\myapp.Android\obj\Debug\90\android\bin\classes\mono\android\support\design\widget\BottomNavigationView_OnNavigationItemReselectedListenerImplementor.class
- 276 characters

Only 227 if you're careful about where you put it, but that's kind of the
point - you have to be careful about where you put/build your Xamarin projects
from.

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

~~~
marcrosoft
No, but go vet and many IDEs will nag you into submission if you use all caps.
Or name your func convertJson when it should be convertJSON.

