101–110 of 138 posts
IMO, with underscores it is not immediate recognizing the elements of an expression like some_var.some_fun(some_param, another_param) Instead with CamelCase, they are immediately visible: someVar.someFun(someParam, anotherParam) But my preferred syntax is Lisp: (some-fun some-var some-param another-param) (when this-looks-appealing (setf you-like-lisp-syntax true) (vote-poll 'camel-case-formatting)) IMO, "this-looks-…
Earlier quoted context omitted.
IAgreeThatSnakeCaseIsEasierToRead,ThoughIfWeWereToUseCamelCaseMoreWeWouldBeSavingAGoodAmountOfSpace,WhichMightBeUsefulForNarrowBlocksOfText.I'mSuprisedItHasn'tCaughtOnInProse.Actually,LookingAtThis,MaybeIt'sAGoodThingItHasn'tCaughtOnForProse.
Classical Latin used all caps no spaces, so rather than caught on we moved away from it. https://en.wikipedia.org/wiki/Scriptio_continua
Earlier quoted context omitted.
IAgreeThatSnakeCaseIsEasierToRead,ThoughIfWeWereToUseCamelCaseMoreWeWouldBeSavingAGoodAmountOfSpace,WhichMightBeUsefulForNarrowBlocksOfText.I'mSuprisedItHasn'tCaughtOnInProse.Actually,LookingAtThis,MaybeIt'sAGoodThingItHasn'tCaughtOnForProse.
Classical Latin used all caps no spaces, so rather than caught on we moved away from it. https://en.wikipedia.org/wiki/Scriptio_continua
This misses one advantage of underscores, which is consistency: foo modified_foo foo modifiedFoo With underscores, "foo" looks the same whether it stands alone or not.
foo
fooModifiedIMO, with underscores it is not immediate recognizing the elements of an expression like some_var.some_fun(some_param, another_param) Instead with CamelCase, they are immediately visible: someVar.someFun(someParam, anotherParam) But my preferred syntax is Lisp: (some-fun some-var some-param another-param) (when this-looks-appealing (setf you-like-lisp-syntax true) (vote-poll 'camel-case-formatting)) IMO, "this-looks-…
That works for lisp but it's awkward for languages with infix subtraction.
some-var.some-fun(some-param, another-param)
Why can't we just have spaces in our variable names? These are both work arounds.
These are false time savers. We’re writing code, just recognize that and do what’s natural, snake_case. Any conventions to make code “more readable” to make it like written language seem like fool’s errands to me.
Earlier quoted context omitted.
Behold this monstrosity: devDbUrl Madness. The only thing worse that developers willingly tolerate is prettier's sacrilegious linebreaks [0]. 0: https://prettier.io/playground/#N4Igxg9gdgLgprEAuc0DOMAEBXNc...
JFC preach! This shits me to tears, I need to figure out a way to turn those line breaks off.
I find snake case so much easier to read, breathing space between words is there for a reason.
I also got unnaturally irritated by PowerShell's insistence on hewing so closely to CamelCaseOrthodoxy that common abbreviations and acronyms like ID, IP, and DB became Id, Ip, Db.
Left to my own devices, I'll use OTBS + lower_snake and it drives some of The Youths on my team insane.
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.