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.
> 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.
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.
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.
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?
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.
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.
To this I would add a couple of classic mid century studies on perception: Arnheim's "Art and Visual Perception" (which imo should be mandatory for any UI designer), and Merleau-ponty's "Phenomenology of Perception" (this one requires some extensive background reading, but it's well worth the effort)
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 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.
Maybe you want to have the feeling to be in control ? Smaller files, each having one well defined usage, nicely ordered in structured folders, gives me the feeling I understand what's going on.
Maybe JS projects feels less solid or grounded sometimes ?
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.
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.
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.
The author doesn't claim to make a universal determination. The supposed claims are introduced with "here's how I would psychoanalyse my own preferences."
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.
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
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.
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'
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.
> 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.
Of course it's difficult to compare if they feel maybe a bit less heavy for me than for English speakers, but as a German capital letters do indeed feel heavy for me, as well.
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.
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 :)
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.
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.
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.
What I’ve started to do is put everything in c:\src\<git-repo>, which limits the overhead to 3 characters instead of the 42 or whatever for your users folder.
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.
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.