Was looking through some code today, and found something that highlights my biggest struggles in programming, it’s compound words and casing. Had identifiers such as…
strikeThroughOffset
whitespaceWidth
lineSpacing
underlineOffset
outlineThickness
I can keep in mind “strike through off set”, but then I struggle to remember, is it strikethrough or strikeThrough? What about Offset or OffSet? Why are offset, underline, and outline, all one word, but strikeThrough isn’t? I think of it as one compound word, many people apparently do, but I guess someone who wrote this code doesn’t.
Or… is this just a me problem? Does anyone else struggle with this sort of thing? Am I missing something or should I “just get good”? My best solution so far is just keep everything always lowercase, personally I find that more readable and memorable, but that’s a lot to ask of literally every other programmer in the world…
You must log in or register to comment.
I’d take the approach of “flattening” compound words and joining them with the preferred style for the given language. Take your first one, for example:
strike-through off-set -> strikethrough offset
Python (snake_case): strikethrough_offset
Go (camelCase): strikethroughOffset
Rust type (UpperCamelCase): StrikethroughOffset … etc
I totally agree with what you’re saying. Also, I think UpperCamelCase is called Pascal case.
It is, the one that starts with lower case is called camel case. As in camelCase has a “hump”
I have issues with acronyms. For example, SMS: Is it
activateSmsoractivateSMS? What aboutsmsPermissionvssMSPermission?My rule of thumbs is if its more than three characters capitalize only the first letter. So, given your example I would write activateSms and smsPermission.
The key is consistency.
It doesn’t really matter all that much. camelCase is to break up the long variable names and help people find the word breaks. Like imagine linespacing. That could be line spacing or lines pacing, and a little context would help you understand which (yeah this is a bit of a stretch)
As long as it helps clarify, it doesn’t matter. That doesn’t mean it won’t bug me if I think someone has done it wrong, but it doesn’t really matter.
Yeah, this is one of those constant annoyances that you kinda just live with. It doesn’t matter that much, because compound words were at some point not one word, and there may be separate words that you use today that will join together during your career. Electronic mail became e-mail became email. As long as the casing doesn’t hide the meaning, you’re doing it right. Also be consistent. Don’t recreate such monstrosities as XMLHttpRequest.
I see this a lot with a significant portion of my colleagues, maybe around 30%.
Personally I don’t feel like it’s a big issue for me, but on the other hand I’ve been working mostly in Python (snake_casing) for the last six years.
That said I do see people having issues with it even in Python, so it’s not like snake casing cures the issue.
Always lowercase gets a downvote from me though.
What an interesting problem!
Are you able to use other styles of casing? Like underscore casing might help because you can see the spaces so it’s strike_through_offset Whitespace_width Etc Or maybe, if you have to stick with camel, it’s every syllable (if you work on a team, I would not recommend this, but for personal stuff it should be fine)
I don’t think it’s a case of get good so much as it is a case of you parsing things differently depending on brain state, and you not having a tool to help you over come it/return to the previous brain state that could tell you which letter to capitalize.
I think your best bet might be to come up with hard arbitrary rules and practice those until it sticks. It’s all vibes until experience hardens it into an opinion, basically
My initial kneejerk reaction though was “you’re thinking too hard about it, just let it flow” but idk if that’s helpful in the slightest lol certainly wouldn’t help if there’s a mental bump at play, so I think simplifying the rules into something regular is probably the best place to start
Hmm per-syllable camel case, is that a thing? Sounds interesting! I might like that one lol
But yeah, am I able to use another casing style… the thing is, kinda yes? But kinda no. I think I basically can manage any style (Though not a fan of the underscore_style but hey, can do), it’s really just compound words that trip me up. Like, consider white space width and strike through off set. I can keep every word in mind, but apparently whitespace is one word, and strike through might be two words, depending on who you ask. So to me, I think this is correct:
whitespace_width,strikethrough_offsetBut someone else might think it should be:
white_space_width,strike_through_off_setAnd yet a third person might do:
whitespace_width,strike_through_offsetI just can’t memorize which words are compound words, and which ones aren’t, and I don’t know how to tell without just knowing. I know what words go into identifier names, but when some of those words might be compound words, I get all messed up, which is a bit of an issue when working with other people’s code.
Maybe in a way, my problem is that I memorize the names of things in a sort of “spoken” state; I “say” strike through off set in my mind, but capitalization doesn’t affect speech, so if its ‘strikethroughoffset’ or 'StrikeThroughOffSet", my brain is gonna memorize it as just the 4 words, “strike through off set”.
So in the end, the easiest thing I’ve found when working on my own projects is just keep everything lowercase, no underscores. The tiniest exception I might make is a singleton, but generally I think “If I have a collection of data and functions, and there will only be 1 instance of it, there’s a name for that: A namespace” so I don’t often employ those. (Maybe you can tell I have C/C++ in mind especially lol)
Now I kind of want an linter that checks that compound words in a given dictionary are joined, and those that are not are separate…
Whitespace width? You mean kerning?
You could make those styles into objects. So you have something like:
TextFormat.strikethrough.withWidth(1.dp)
ParagraphFormat.lineheight.double()
Or
TextDecoration.underline.solid.withWidth(1.dp).and.padding(top: 0.5dp)
Each language has their own conventions in the style guides for how they prefer variables and functions to be named.
For example,
- Python uses
snake_case - C and C++ also generally use snake case, but have specific conventions for particular types of variables
- Java, JavaScript, and C# use
camelCase(like your examples) - Pascal, Dart, and a few others use
UpperCamelCasethat’s like camel case, but the first letter is also capitalized
And then some organizations like to override those and institute their own conventions. I generally think the latter is a bad idea, since it breaks with accepted industry standards for a given language. Even for a personal project you know that no one else will touch, I think it’s good to follow the langues guides.
I generally wouldn’t make a compound word all lowercase.
strikethroughoffsetis much more difficult to read, IMO. If you’re going that route, then you should at least snake case it:strike_through_offset. But again, a lot of this is going to depend on your situation.It’s not really a “get good” issue so much as it’s just an annoying part of the industry one has to navigate.
- Python uses
