I believe that, exactly as the utterly retarded "TAB vs space" debate, the "cameCase vs dash" should be a non-issue. This should be solved at the text editor / IDE level and at the tools level and should not cause any issue.
Put it this way: I can trivially write an Emacs minor mode that detects cameCase and shows them as dashes and vice-versa.
This should be something each programmer could decide on its own, as long as the commits are using the same convention.
Now, also, maybe maybe maybe that it shouldn't be language recommandations but specs defined in the language.
A bit like how the Go language close shut the big mouths of people advocating for this or that place for brackets.
For what it's worth I'd configure my text editor to show names using dashes instead of camelCase...
I think the big difference is that camel case added to the ridiculous idea of designing programming languages that are case sensitive just makes for unnecessary friction.
Tab vs. spaces will not cause code to break, mistyping camel case in a case sensitive language does. Neither camel case nor case sensitivity makes programming easier, better, faster, less error-prone, clearer, more accurate, et. In other words, it serves no useful purpose other than feeding a fad.
Tab vs. spaces? Don't really care. There are good reasons for going ether way. As long as the tab key does the indentation I, personally, couldn't care less which way it goes. My code will not break if I enter a bunch of spaces instead of tabs.
I literally just started going through Project Euler with Python now to get comfortable with the language.
I'll play with that and see. I can't think of any other language where this might matter.
Should I look for anything in particular or simply tabs vs space in indentation on any code?
# Problems from ProjectEuler.net
# http://projecteuler.net/problem=1
def problem_1():
return sum([n for n in range(1000) if (n%3 == 0) or (n%5 == 0)])
def problem_1a():
return sum(set(range(3,1000,3) + range(5,1000,5)))
# http://projecteuler.net/problem=2
def problem_2():
sequence = [1,2]
while sequence[-1] < 4000000:
sequence.append(sum(sequence[-2:]))
if sequence[-1] > 4000000:
sequence.pop()
return sum([n for n in sequence if (n%2 == 0)])
I did say I was just getting started!
I'll try the above and other code I wrote with a mixture of tabs and spaced and see what happens. Interesting. If Python actually breaks because of that it's a shame. I really like the language. Is it a matter of IDE interpreter (type code and execute interactively) vs. command-line interpreter (same as previous) vs. module execution (i.e.: "python my_module.py" from the command prompt)?
If I recall correctly, Python's indentation counts characters, so a single tab is not the equivalent of four or eight spaces, but only one. If you accidentally mix them, therefore, lining things up visually in your editor will result in indenting or outdenting where you did not intend.
Put it this way: I can trivially write an Emacs minor mode that detects cameCase and shows them as dashes and vice-versa.
This should be something each programmer could decide on its own, as long as the commits are using the same convention.
Now, also, maybe maybe maybe that it shouldn't be language recommandations but specs defined in the language.
A bit like how the Go language close shut the big mouths of people advocating for this or that place for brackets.
For what it's worth I'd configure my text editor to show names using dashes instead of camelCase...