51–60 of 60 posts
So an underscore function can not (easily) be modified to suit a particular function since it's used all over the place.
But a camel case function can be modified because it is only used in the same part of the program, so you can easily change all uses of it.
Earlier quoted context omitted.
> // 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 expec…
Are we discussing Pascal casing now? ;)
> There is an objective, scientific truth to which one is easier to read
I seriously doubt that. I would have thought that training over many years creates a bias one way or the other. I find It_might_be_this_one much harder to read than itMightBeThatOne. I much prefer kebab-casing-over-underscores also.
Perhaps there's a definitive answer for new programmers who have never seen either casing style? But for you to claim that those who disagree with you are drinking Kool-Aid is disingenuous.
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 like using CamelCase for most things because it gives the option of also using underscores on top of that. For example, for database and table names, I'll use CamelCase for names but underscores for primitive namespacing.
Earlier quoted context omitted.
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 expec…
> ItMightBeThatOne Are we discussing Pascal casing now? ;) > There is an objective, scientific truth to which one is easier to read I seriously doubt that. I would have thought that training over many years creates a bias one way or the other. I find It_might_be_this_one much harder to read than itMightBeThatOne. I much prefer kebab-casing-over-underscores also. Perhaps there's a definitive answer for new programmers…
That, and it's easier to type (reduction of combo-pressing shift and the key for _)
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.
And, by the way, middle-score as in lisp (and, from there, Dylan and Clojure) is the superior approach: easier to type than either, and makes you stand out from the crowd :-)
Is there some reason we can't just do away with both and consider spaces in languages?
Offhand, I can only think of a couple problem areas (but my C language lawyer days are long gone and I'm way out of practice--anyone else have some I'm missing?).
1. "goto foo;" could either be a goto keyword and the label foo, or a really stupid expression involving the variable "goto foo".
2. "int foo();" could be a forward declaration of the function foo, or an invocation of the function "int foo".
There would also be some questions about preprocessing. If I have something like "x pos = 12;", and I have a #define pos foo" in effect, does that apply to the "pos" in my "x pos"?
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 wit…