121–130 of 138 posts
Earlier quoted context omitted.
Classical Latin used all caps no spaces, so rather than caught on we moved away from it. https://en.wikipedia.org/wiki/Scriptio_continua
My favorite deprecated writing convention is boustrophedon: https://en.m.wikipedia.org/wiki/Boustrophedon
now a study on tabs vs spaces, please
That got me to learning about all the ways that markup can (and should) be used to convey _both_ the content _and_ the structure of the information on the screen, for the benefit of vision-impaired readers.
That in turn led to the epiphany that the tab character _is_ markup for indentation, and in the world of programming, where indentation is so significant for understanding (especially in whitespace-sensitive languages like Python), I wondered why we were making things harder for vision-impaired users by focusing so much on _visual_ consistency (which can still be achieved by syncing editor "how do I render tabs" settings)
C, Odin :- my_function("hi")
D, Java :- myFunction("hi")
C#, Pascal :- MyFunction("hi")
Lisp, Scheme := (my-function "hi")
Even these are not 100% accurate. For Odin, I would create a struct like MyStruct. In C, it would likely be my_struct_t.
etc.
In future, I might start following Anti Pascal Case for all languages
mYnEWfUNCTION("hi")
Earlier quoted context omitted.
> Don't put the return type on a separate line. Generally yes, but stuff like ReturnType , T>>, U, HmmLetsAdd > can be on a line of its own.
I generally agree but there are two problems: 1. You're writing C++. You've really lost half the battle laready :) and 2. Writing correct templated code is difficult and should generally be reserved for when you're writing a library; and 3. For complicatred types like this, one should strive to increase readability by using type aliases, assuming your language supports it (eg C++ and Hack do). It's not always possibl…
Earlier quoted context omitted.
> Whoever does that do not change it, they are probably a psychopath French generally adds a space before punctuation.
So I was right!
And here I was agreeing... But that was because of the "i = i".
Earlier quoted context omitted.
From the article: "paleographers today identify the extinction of scriptio continua as a critical factor in augmenting the widespread absorption of knowledge in the pre-Modern Era. By saving the reader the taxing process of interpreting pauses and breaks, the inclusion of spaces enables the brain to comprehend written text more rapidly."
I_suppose_causality_would_be_difficult_to_establish_here_but_it_is_intriguing_nonetheless._A_little_space_between_words_helps_the_eye_quickly_see_word_boundaries_which_is_helpful_because_in_the_English_language_words_roughly_correspond_to_units_of_meaning.
Earlier quoted context omitted.
IAgreeThatSnakeCaseIsEasierToRead,ThoughIfWeWereToUseCamelCaseMoreWeWouldBeSavingAGoodAmountOfSpace,WhichMightBeUsefulForNarrowBlocksOfText.I'mSuprisedItHasn'tCaughtOnInProse.Actually,LookingAtThis,MaybeIt'sAGoodThingItHasn'tCaughtOnForProse.
On_the_other_hand,_is_snake_case_really_that_much_better_for_reading_prose?_I_find_this_difficult_to_read_as_well._Also,_at_least_part_of_the_reason_camel_case_prose_is_more_difficult_to_read_is_because_the_beginnings_of_sentences_are_no_longer_uniquely_capitalized,_which_isn't_an_issue_in_code.
I prefer to use a language's convention, whatever that might be. The language's standard library will expose names using the language's convention, and using a different convention for my own code's names would make for strange and confusing looking code.
What if you are creating a new language? Which one would you use?
Case insensitive, of course
Earlier quoted context omitted.
It's a joke. I made it up. Probably not a good idea to propagate it. ;) I think that there is an official name for lowercase-prefixed CamelCase, but I don't remember it.
That's camelCase. Uppercase would be PascalCase.
But then again, camels have heads at about the same height as the hump, so...
I prefer to use a language's convention, whatever that might be. The language's standard library will expose names using the language's convention, and using a different convention for my own code's names would make for strange and confusing looking code.
> The language's standard library will expose names using the language's convention Looking at you, C++ STL. Almost nobody names structs/classes all lowercase. This leads to silly style guidelines eg. in the Google c++ style guide: - Name classes PascalCase (even if it's templated) - Except if your class happens to be a templated container type, in which case name it all lowercase.