One point not mentioned in the article is that screen readers and other assistive technologies often produce better results when parsing words separated by underscores, so the code may be more accessible if it consistently uses an underscore-based style.
CamelCase vs. underscores: Scientific showdown
11–20 of 60 posts
Re: CamelCase vs. underscores: Scientific showdown
#12Funnily enough if we want to be semantically correct then CamelCase is wrong and camelCase is right.
Apparently that's a Microsoft distinction and they use "Pascal case" to describe strings starting with uppercase [1]
Re: CamelCase vs. underscores: Scientific showdown
#13As of right now the results are as follows: - CamelCase 52.34% (4,493 votes) - underscores 47.66% (4,092 votes) Which kind of says it all. Use whatever style you want, stop worrying so much about what other people are doing. Variable names a far more important than the formatting you use with them.
I think "use whatever style you want" is a fair ethos for personal projects but the truth is it never works for teams.
If organizations allowed that you'd have no conventions and codebases would be a mess for all involved.
Years ago I moved from_underscores toCamelCase but I'm not vehemently passionate about it and there are plenty of cases where I need to go back to match_conventions.
Re: CamelCase vs. underscores: Scientific showdown
#14I can easily write a tool to automatically convert CamelCasedVariables to underscored_variables, or vice versa. The fact that I have not done so indicates that I don't care.
The important thing is that the variable names be chosen to facilitate human understanding of the code.
Re: CamelCase vs. underscores: Scientific showdown
#15As of right now the results are as follows: - CamelCase 52.34% (4,493 votes) - underscores 47.66% (4,092 votes) Which kind of says it all. Use whatever style you want, stop worrying so much about what other people are doing. Variable names a far more important than the formatting you use with them.
I think "use whatever style you want" is a fair ethos for personal projects but the truth is it never works for teams. If organizations allowed that you'd have no conventions and codebases would be a mess for all involved. Years ago I moved from_underscores toCamelCase but I'm not vehemently passionate about it and there are plenty of cases where I need to go back to match_conventions.
Well, sure, when part of a team, make a decision and go with it. But most of the time these debates on HN just disappear down a hole of people arguing past each other and caring far too much about something that doesn't matter.
Re: CamelCase vs. underscores: Scientific showdown
#16As of right now the results are as follows: - CamelCase 52.34% (4,493 votes) - underscores 47.66% (4,092 votes) Which kind of says it all. Use whatever style you want, stop worrying so much about what other people are doing. Variable names a far more important than the formatting you use with them.
Interestingly, the end of article poll has very different results,
- CamelCase 43.84% (1,117 votes)
- underscores 56.16% (1,431 votes)
The beginning poll still is still within half a percent of your numbers as of now.
Apparently, people who prefer underscores are more likely to follow through. ;)
Re: CamelCase vs. underscores: Scientific showdown
#17I find that I view camelCase as one word and camel_case as two words. The '_' works as a separator not a joiner. Since we can only keep four or five words in our working memory it's better for me to use camelCase.
It's possible that with more exposure to underscore_case I would eventually start treating it as one word.
Re: CamelCase vs. underscores: Scientific showdown
#18From the OP's list of "Pro CamelCase": > Camel case is easier to type, and underscores are hard to type. I'll grant it that, but in the context of programming, this does not seem to be a "pro". After all, don't we spend far more time reading code than we do writing code? I'm old, but I'm still surprised at how I have to fight over my reluctance to do something in another language (such as Python) when I remember that…
Agreed, although python convention is for underscores also. According to pep8 "Function names should be lowercase, with words separated by underscores as necessary to improve readability. mixedCase is allowed only in contexts where that's already the prevailing style"
PEP8 also says "Class names should normally use the CapWords convention."
Re: CamelCase vs. underscores: Scientific showdown
#19Personal logic bugfix: if ( thisLooksLikeJavaOrJavaScriptOr/* ... */ ) { youLikeCamelCase = true; votePoll( camelCaseFormatting ); } else if ( this_looks_like_python ) { you_like_underscores = true; vote_poll( underscore_formatting ); } Variable assignments for this particular piece of code: thisLooksLikeJavaOrJavaScriptOr/* ... */ = true; this_looks_like_python = false;
(define this-looks-the-best_To-Me true)
(if this-looks-the-best_To-Me
(do
(setq you-like-flexibility true)
(vote-poll :lisp-formatting)))
Re: CamelCase vs. underscores: Scientific showdown
#20I really like underscores for two word variable names. It only becomes a problem when you have variable names which are overly long, and your eyes have to move further. if(Accounts_Orders_Invoices_Table.Order_Invoice_Number == Order_Invoice_Number){ ...} if(AccountsOrdersInvoicesTable.OrderInvoiceNumber == OrderInvoiceNumber){ ... } But I don't really care that much. I'll just do whatever everyone else is doing. At l…
In my preferred language, CamelCase is often used to class names, and underscores for function/method names (as mentioned as in the article). Then again, my preferred language uses sigils so I don't need to rely on convention to differentiate things as much as some other languages.