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.

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.

> 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 it's conventionally camelCase...on the other hand, I try to use it as a personal advantage...I can immediately tell in a body of code what helper functions originated from me, as I'll habitually write them in underscore (though this probably annoys the shit out of anyone who then tries to read/use my code).

Conversely, my enthusiasm for using R jumped when I read Hadley Wickham's style guide and saw that he endorsed underscores (http://r-pkgs.had.co.nz/style.html)

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"

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

Lisps, by not reserving '-', and following convention:

  (println are-the-clearest-and-easiest-for-me)

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

Observe:

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

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

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

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

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

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

I personally favour the C-style fuck-it-all naming scheme:

    else if (like) {
      likelowbar = true;
      vote(lowbarfmt);
    }

// BTW: I don't believe anyone telling me they can read camels more efficiently. Underscores add contrast, which aids your vision quite a bit.

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

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.

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.

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

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.

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

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.

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

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

//This wont look good :)

int static set_my_config(char* data);

int static getMyConfig();

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.

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 :-)

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

  err_total = err_intrinsic + err_extrinsic

    if ( thisLooksLikeJavaOrJavaScriptOr/* ... */ )
    {
        youLikeCamelCase = true;
        votePoll( camelCaseFormatting );
    }
    else if ( this_looks_like_python )
    {
        you_like_underscores = true;
        vote_poll( underscore_formatting );
    }

    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)))

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.

It's possible that with more exposure to underscore_case I would eventually start treating it as one word.

The important thing is that the variable names be chosen to facilitate human understanding of the code.

country_state_city

or

unitedStates_texas_houston

or

unitedStates_newMexico_santaFe

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

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

That, and it's easier to type (reduction of combo-pressing shift and the key for _)

1. http://en.wikipedia.org/wiki/CamelCase