51–60 of 138 posts
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.
I use both but camel case assumes capitalization doesn't have meaning other than as a sort of break indicator, which isn't always the case.
Madness. The only thing worse that developers willingly tolerate is prettier's sacrilegious linebreaks [0].
0: https://prettier.io/playground/#N4Igxg9gdgLgprEAuc0DOMAEBXNc...
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?
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.
The most peeving to me is camel case conventions that preserves the capitalization of abbreviations. Convention that would require TCPIPQOSScore instead of tcpIpQosScore.
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.
Would allowing spaces in identifiers even introduce any ambiguity in most languages? I think the only languages I've seen where it would matter are functional languages. e.g. I think it'd be possible to write a Python program using spaces instead of underscores, and be able to unambiguously parse it with a slightly modified parser?
Yes, ML style function application is a problem and treating newlines as "normal" whitespace without having line separators (aka semicolons). And keywords used as infix operators, like another post reminded me of.
Earlier quoted context omitted.
I am not picturing why this is true, if you cannot use key words as parts of variables (alone separated by a space) and lines end with a newline or semicolon (some symbol) The first restriction might make this a problem. I am not saying it is a good idea, but it is not obvious to me.
Removing keywords from variables is a big sacrifice when they are often such common glue words, like `and`, `or`, `if`, etc. Say `and` is the keyword and you want a variable called foo_and_bar. To get such words back you would need to add something so that the parser knows if foo and bar == true means foo && bar == true or foo_and_bar == true ? You could fix it with ugliness like making the keyword `@and` or some suc…
Like I said, I can’t picture the requirement, but am not sure it is a good idea.
just•Give•Me•Extra•Kerning•Or•Ligatures I still don't understand how comes that in times of programming fonts with fancy ligatures there is not a single one that would attempt to make camelCase more legible by slightly separating lowerUPPER sequences (presumably by constructing a "anti-ligature" for each unique pair that would have still width of two glyphs). Or try to do anything similar to ease reading theseAnachro…
hyphen-case is worth the grammar concessions (like making whitespace between binary operators mandatory).
Yeah no thanks. Soo `a-b` and `a - b` are both potentially valid and different? Also allowing hyphens generally leads to issues when interoperating with other languages that don't support hyphens. Probably the best example of this is CSS which does allow hyphens, and Javascript which doesn't. `background-color` in CSS gets translated to `backgroundColor` in JS. It's an annoying paper cut that trips up beginners and m…
You shouldn't be able to start a name with a hyphen, so `a -b` and `a - b` can be both valid.
But I mostly just came to acknowledge your fitting username ;)
Earlier quoted context omitted.
I am not picturing why this is true, if you cannot use key words as parts of variables (alone separated by a space) and lines end with a newline or semicolon (some symbol) The first restriction might make this a problem. I am not saying it is a good idea, but it is not obvious to me.
Removing keywords from variables is a big sacrifice when they are often such common glue words, like `and`, `or`, `if`, etc. Say `and` is the keyword and you want a variable called foo_and_bar. To get such words back you would need to add something so that the parser knows if foo and bar == true means foo && bar == true or foo_and_bar == true ? You could fix it with ugliness like making the keyword `@and` or some suc…
DO 10 I = 1.100
DO10I = 1.1
DO 10 I = 1,100