All things programming and coding related. Subcommunity of Technology.
This community's icon was made by Aaron Schneider, under the CC-BY-NC-SA 4.0 license.
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"
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.
I have issues with acronyms. For example, SMS: Is it activateSms or activateSMS? What about smsPermission vs sMSPermission?
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.
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_offset
But someone else might think it should be:
white_space_width,
strike_through_off_set
And yet a third person might do:
whitespace_width,
strike_through_offset
I 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)