21–30 of 138 posts
I find snake case so much easier to read, breathing space between words is there for a reason.
IAgreeThatSnakeCaseIsEasierToRead,ThoughIfWeWereToUseCamelCaseMoreWeWouldBeSavingAGoodAmountOfSpace,WhichMightBeUsefulForNarrowBlocksOfText.I'mSuprisedItHasn'tCaughtOnInProse.Actually,LookingAtThis,MaybeIt'sAGoodThingItHasn'tCaughtOnForProse.
Why can't we just have spaces in our variable names? These are both work arounds.
So that the compiler or interpreter knows the extent of the variable token. Without spaces allowed you would need some other way to tell it where they start and end, like quotes or a special declaration, which would be harder for the brain to parse. If you know a better way please share it.
The first restriction might make this a problem. I am not saying it is a good idea, but it is not obvious to me.
I use both. Depends on the context. In Swift (where I spend most of my time), it's CamelCase, or, quite often, dromedaryCase.
Why can't we just have spaces in our variable names? These are both work arounds.
var initial factory = abstract configuration factory factory. configure new factory()I got the solution! Given that spaces in identifiers cannot be used because we need to please the language tokenizers (shouldn't be the other way around with humans vs machines?), let's use TAB as a word separator! Configure TAB width = 1 character, and there you go.
Underscore is a double-pinky keystroke. As someone who has battled RSI, I stopped using snake case and underscore-prefixed member variables because of the added stress all those underscores place on the weakest fingers.
Why can't we just have spaces in our variable names? These are both work arounds.
PS> ${Valid characters for an identifier? Eh, ¯\_(ツ)_/¯ whatever (`}) you want.} = $True
PS> ${Valid characters for an identifier? Eh, ¯\_(ツ)_/¯ whatever (`}) you want.}
True