Psychological effects of coding style (2016)
devever.net
devever.net
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.
(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.
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.
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.
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.
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.
oAbstractpatterndecoratorproxysingletonfactoryfactory
OAbstractpatterndecoratorproxysingletonfactoryfactory::OAbstractpatterndecoratorproxysingletonfactoryfactory(){}
(even has pdp in it, truly C)
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.
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.
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?
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.
It's a principle of pattern recognition[1] regardless of language, I suppose.
It just takes time to learn and internalize the patterns to look for -- and perhaps some languages and syntax highlighters are better than others at exposing those patterns to the reader.
[1] - https://en.wikipedia.org/wiki/Pattern_recognition_%28psychol...
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.
Maybe JS projects feels less solid or grounded sometimes ?
Because SeLeCt * FrOm <table> is valid.
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.
For programming underscore should be narrower than space.
> #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.
eg previously I would do:
MyClass myClassBtw, for kebabs you probably want a Dönnergrill :)
[1] https://en.wikipedia.org/wiki/Compound_(linguistics)#Germani...
Or are capital letters so common that they don't feel heavy?
Nouns are capitalized in German, not other random words. But yes, both proper nouns and all other nouns feel heavier than other words.
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.
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.
End of argument ;-)