CamelCase vs. underscores: Scientific showdown • Hacker News Board

Re: CamelCase vs. underscores: Scientific showdown

#41

Post by jgrowl » Tue, Mar 03, 2015, 5:18 PM UTC

Would it be possible to just have the editor display to the user whatever style they prefer but keep the underlying representation consistent? I guess it would just add complexity and make it harder to just edit the files as plain text though. Probably not worth.

Re: CamelCase vs. underscores: Scientific showdown

#42

Post by louthy » Tue, Mar 03, 2015, 5:21 PM UTC

teamhappy wrote: post #36

Underscores win. Having said that; if your standard lib chose camels, that's probably what you should be choosing too. Consistency is the most important criteria. I personally favour the C-style fuck-it-all naming scheme: else if (like) { likelowbar = true; vote(lowbarfmt); } The narrower the columns, the easier it is for me to comprehend the algorithm. It also makes for great method names. Say "isatty" three times;…

> // BTW: I don't believe anyone telling me they can read camels more efficiently.

Maybe it's time to accept that other people have different opinions to you, and maybe, just maybe have a preference for camel-casing.

Re: CamelCase vs. underscores: Scientific showdown

#43

Post by jdontillman » Tue, Mar 03, 2015, 5:22 PM UTC

Very often a variable name needs to provide more context.

I have found it very useful to use under_scores as a form of punctuation within camelCase to visually connect related variables.

Like this:

  spectrumPlot_x
  spectrumPlot_y
  spectrumPlot_drawHarmonics
  qa_signalDone
  qa_setLoadedFlag
  requestTimeout_minValue
  requestTimeout_maxValue

... and so forth.

(Note that the opposite doesn't work: camelCase as a punctuation within under_scores.)

Re: CamelCase vs. underscores: Scientific showdown

#44

Post by lmm » Tue, Mar 03, 2015, 5:22 PM UTC

nkozyra wrote: post #13

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.

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.

> I think "use whatever style you want" is a fair ethos for personal projects but the truth is it never works for teams.

Citation needed; my experience is just the opposite (it works much better than trying to specify some kind of organization-wide standard).

Re: CamelCase vs. underscores: Scientific showdown

#45

Post by josephschmoe » Tue, Mar 03, 2015, 5:25 PM UTC

Is there some reason we can't just do away with both and consider spaces in languages?

Re: CamelCase vs. underscores: Scientific showdown

#46

Post by amyjess » Tue, Mar 03, 2015, 5:32 PM UTC

hga wrote: post #31

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…

Agreed, although I still find '_' to be a lot more clear. Lisps, by not reserving '-', and following convention: (println are-the-clearest-and-easiest-for-me) Also see my other comment.

Personally, I'm fond of Algol style, where spaces are permitted in identifiers.

Man, Algol 68 was really ahead of its time... too bad it never caught on.

Re: CamelCase vs. underscores: Scientific showdown

#47

Post by exogen » Tue, Mar 03, 2015, 5:34 PM UTC

Camel case results in several sources of frustration for me:

1. Is it userID or userId? HTTPClient or HttpClient? Leaving this additional stylistic choice up to people results in conflicting styles even within the scope of "camel case" everywhere! (JavaScript mostly leaves them uppercase, e.g. DOMException...then there's XMLHttpRequest...)

2. Code isn't the only place we need to make this choice: what about configuration files? I find that using camel case for configuration keys – even if the configuration will be the input to a camel-case-language program! – just feels incredibly wrong.

Re: CamelCase vs. underscores: Scientific showdown

#48

Post by rejected_value » Tue, Mar 03, 2015, 5:38 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…

Your first example is actually a mutant hybrid of camel-cased underscores.

Observe:

  if(accounts_orders_invoices_table.order_onvoice_number == order_invoice_number){ ...}

Versus yours:

  if(Accounts_Orders_Invoices_Table.Order_Invoice_Number == Order_Invoice_Number){ ...}

I would be, perhaps, moderately ticked off to have to have to deal with code that looked like that, and used both, in a real world scenario.

Re: CamelCase vs. underscores: Scientific showdown

#49

Post by G3E9 » Tue, Mar 03, 2015, 5:43 PM UTC

I use camel case when the subject needs two words in order to identify it. Underscores, I feel, can be used to separate and include multiple ideas within a single name, in order to explain or emphasize on a relationship.

country_state_city

or

unitedStates_texas_houston

or

unitedStates_newMexico_santaFe

edit: sorry, don't know HN's markup

Re: CamelCase vs. underscores: Scientific showdown

#50

Post by teamhappy » Tue, Mar 03, 2015, 5:43 PM UTC

louthy wrote: post #42

teamhappy wrote: post #36

Underscores win. Having said that; if your standard lib chose camels, that's probably what you should be choosing too. Consistency is the most important criteria. I personally favour the C-style fuck-it-all naming scheme: else if (like) { likelowbar = true; vote(lowbarfmt); } The narrower the columns, the easier it is for me to comprehend the algorithm. It also makes for great method names. Say "isatty" three times;…

> // BTW: I don't believe anyone telling me they can read camels more efficiently. Maybe it's time to accept that other people have different opinions to you, and maybe, just maybe have a preference for camel-casing.

There is an objective, scientific truth to which one is easier to read. It_might_be_this_one, or ItMightBeThatOne. I don't know which one it is, but I do know that facts don't require opinion.

I'm glad you used the word "preference." I wish people wouldn't feel the need to justify arbitrary choices they make in life. It's your code and I will honour the choices you made if I ever end up working on it. You can't expect me to drink the Kool-Aid though.