CamelCase vs. underscores: Scientific showdown • Hacker News Board

Re: CamelCase vs. underscores: Scientific showdown

#21

Post by libria » Tue, Mar 03, 2015, 4:54 PM UTC

I'm heavily biased in favor of the idiomatic style of the language I happen to be using. There's less context switching when interfacing with external libraries that are expected to follow the same.

There isn't a significant loss in velocity in adapting to use one or the other or even simultaneously (front_end_javascript, BackEndJava, SELECT * FROM blah). The most significant portion of my time is spent thinking/designing/debugging; I save the balls-to-wall frantic keyboard banging for NCIS cameos.

Re: CamelCase vs. underscores: Scientific showdown

#22

Post by kbd » Tue, Mar 03, 2015, 4:55 PM UTC

Someone1234 wrote: post #6

I 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…

> At least camcelCase keeps me from reaching for the _ as much...

Among the many reasons I prefer Dvorak is that dash/underscore is on the home row.

Re: CamelCase vs. underscores: Scientific showdown

#23

Post by ttmarek » Tue, Mar 03, 2015, 4:55 PM UTC

rowanseymour wrote: post #18

illcollins wrote: post #9

Earlier quoted context omitted.

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."

PEP8 also says "The naming conventions of Python's library are a bit of a mess, so we'll never get this completely consistent -- nevertheless, here are the currently recommended naming standards. New modules and packages (including third party frameworks) should be written to these standards, but where an existing library has a different style, internal consistency is preferred."

Re: CamelCase vs. underscores: Scientific showdown

#24

Post by RussianCow » Tue, Mar 03, 2015, 4:56 PM UTC

smhenderson wrote: post #7

Try choosing independently of (language) convention, habit or type of the identifiers. That's the non-starter for me right there. I use whatever convention makes sense in the context of what I'm doing. Language, library and previous code in an existing project all dictate my choice in this matter.

Agreed. Consistency with existing code and standards trumps any potential gains from using a different style.

Re: CamelCase vs. underscores: Scientific showdown

#25

Post by lutusp » Tue, Mar 03, 2015, 4:57 PM UTC

Not mentioned in the article is the fact that an underscored file can be algorithmically converted to camel case, but not the reverse (with any reliability). Therefore camel case has higher entropy, lower information content, and is less flexible.

Also, the expression "scientific showdown" about studies that rely on psychological self-reporting is a bit of a stretch.

Re: CamelCase vs. underscores: Scientific showdown

#26

Post by [deleted] » Tue, Mar 03, 2015, 4:59 PM UTC

[deleted]

Re: CamelCase vs. underscores: Scientific showdown

#27

Post by lutusp » Tue, Mar 03, 2015, 5:00 PM UTC

kbenson wrote: post #16

untog wrote: post #3

As 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. ;)

> Apparently, people who prefer underscores are more likely to follow through.

Or perhaps they're predisposed to underscore their arguments. :)

Re: CamelCase vs. underscores: Scientific showdown

#28

Post by lutusp » Tue, Mar 03, 2015, 5:01 PM UTC

sotiris-k wrote: post #5

Funnily enough if we want to be semantically correct then CamelCase is wrong and camelCase is right.

Unless it's the name of a class, not a variable.

Re: CamelCase vs. underscores: Scientific showdown

#29

Post by [deleted] » Tue, Mar 03, 2015, 5:01 PM UTC

kbd wrote: post #22

Someone1234 wrote: post #6

I 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…

> At least camcelCase keeps me from reaching for the _ as much... Among the many reasons I prefer Dvorak is that dash/underscore is on the home row.

[deleted]

Re: CamelCase vs. underscores: Scientific showdown

#30

Post by dicroce » Tue, Mar 03, 2015, 5:02 PM UTC

I use the convention of the language or large code base I'm working with...

That said, I've found that the style isn't nearly as important as consistency. Generally speaking, an inconsistently styled code base is a sign that the developers didn't really care about their work...