7 ms·

CamelCase vs. underscores: Scientific showdown

56 points by ttmarek 12y ago

danso 12y ago
From 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 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 http://r-pkgs.had.co.nz/style.html)
- illcollins 12y ago
  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"
  - rowanseymour 12y ago
    PEP8 also says "Class names should normally use the CapWords convention."
    - ttmarek 12y ago
      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."
untog 12y ago
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.
- nkozyra 12y ago
  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.
  - untog 12y ago
    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.
  - lmm 12y ago
    > 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).
- kbenson 12y ago
  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. ;)
  - lutusp 12y ago
    > Apparently, people who prefer underscores are more likely to follow through. Or perhaps they're predisposed to underscore their arguments. :)
engineerdollery 12y ago
As long as you follow convention, that's all that matters.
- htor 12y ago
  As long as you are consistent, that's all that matters.
sotiris-k 12y ago
Funnily enough if we want to be semantically correct then CamelCase is wrong and camelCase is right.
- rowanseymour 12y ago
  Apparently that's a Microsoft distinction and they use "Pascal case" to describe strings starting with uppercase [1] 1. http://en.wikipedia.org/wiki/CamelCase http://en.wikipedia.org/wiki/CamelCase
- lutusp 12y ago
  Unless it's the name of a class, not a variable.
Someone1234 12y ago
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 least camcelCase keeps me from reaching for the _ as much and allows me to stay on the A-Za-z more of the time...
- kbenson 12y ago
  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.
- kbd 12y ago
  > 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 12y ago
    [deleted]
- hga 12y ago
  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.
  - amyjess 12y ago
    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.
- dubya 12y ago
smhenderson 12y ago
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.
- RussianCow 12y ago
  Agreed. Consistency with existing code and standards trumps any potential gains from using a different style.
- ll123 12y ago
  What if you're inventing a new language and need to set the convention?
insin 12y ago
Personal 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;
- hga 12y ago
  (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))) If you follow the normal Lisp pattern of mostly one case and '-' for separation, allowed because Lisps/s-expressions allow the use of the normally reserved '-', I think you get the clearest code. See Clojure for a Lisp that breaks up the sea of Lots of Irritating Sets of Parenthesis if that bothers you.
swhipple 12y ago
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.
logfromblammo 12y ago
I 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.
slm_HN 12y ago
I 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.
libria 12y ago
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.
lutusp 12y ago
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.
deleted 12y ago
[deleted]
dicroce 12y ago
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...
murbard2 12y ago
An argument pro underscore: they can be displayed with 50% transparency, making them visible, yet not interfering with the reading of the identifier as much.
fnordsensei 12y ago
I wonder how kebab-case would do. When available, I prefer it.
mturmon 12y ago
For math, underscores evoke the "_ is subscript" convention of TeX. That can be a good thing, e.g. err_total = err_intrinsic + err_extrinsic which might mirror the notation in a paper that the code implements.
Demiurge 12y ago
I don't think they are exclusive? I use CamelCase for object oriented methods, classes and under_scores for procedural code and temporary variables.
teamhappy 12y ago
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; it's fun, isn't it? // BTW: I don't believe anyone telling me they can read camels more efficiently. Underscores add contrast, which aids your vision quite a bit.
- louthy 12y ago
  > // 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.
  - teamhappy 12y ago
    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.
    - louthy 12y ago
      > 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 who have never seen either casing style? But for you to claim that those who disagree with you are drinking Kool-Aid is disingenuous.
wyager 12y ago
Let's not pretend this is anything other than an aesthetic choice. All these "scientific" arguments one way or the other are weak at best.
64bitbrain 12y ago
When I am writing C, I tend to use underscore. I think I just follow the convention, or the code that already exists. Imagine the some part of the code written in camelCase and other used underscore. //This wont look good :) int static set_my_config(char* data); int static getMyConfig();
jgrowl 12y ago
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.
jdontillman 12y ago
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.)
- Gibbon1 12y ago
  In c often I use underscores to deal with lack of name spaces and or classes. As in Module_FunctionName()
josephschmoe 12y ago
Is there some reason we can't just do away with both and consider spaces in languages?
- tzs 12y ago
  I've often wanted spaces in C. Because C makes heavy use of required punctuation, there aren't many places that a keyword can be adjacent to an identifier, or two identifiers can be adjacent, so for the most part I don't think spaces would introduce ambiguity. 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"?
exogen 12y ago
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.
G3E9 12y ago
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
ars 12y ago
I use both. I use underscore for global functions, and camel case for functions specific to the module. 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.
olav 12y ago
In my eyes, using CamelCase is a kind of cargo cult, based on the fact that the programming language Smalltalk used it. C++ adopted the style and moved away from the predominant use of underscores in C. So, people who want to be seen as modern and object-oriented, are biased to use CamelCase to stress their competence in things OO.
cordite 12y ago
Personally I prefer snake-case but most languages (including the ones I use most) do not support names with dashes in them. That, and it's easier to type (reduction of combo-pressing shift and the key for _)
Someone 12y ago
I would like to see whether mother tongue has an effect on preference. Languages with lots of compounding (http://en.m.wikipedia.org/wiki/Compound_(linguistics) http://en.m.wikipedia.org/wiki/Compound_(linguistics) such as German and Dutch or languages without many spaces such as Classical Latin and Greek, Egyptian hieroglyphics and, sort-of, Chinese and Japanese might make CamelCase look more familiar. I know of one data point: Guido van Rossum is Dutch, and underscores are fairly common in Python (but, on the other hand, https://docs.python.org/3/library/functions.html https://docs.python.org/3/library/functions.html has 'isinstance', 'setattr' and 'memoryview') 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 :-)

56 points by ttmarek 12y ago

danso 12y ago

From 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 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 http://r-pkgs.had.co.nz/style.html)

illcollins 12y ago
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"
- rowanseymour 12y ago
  PEP8 also says "Class names should normally use the CapWords convention."
  - ttmarek 12y ago
    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."

untog 12y ago

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.

nkozyra 12y ago
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.
- untog 12y ago
  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.
- lmm 12y ago
  > 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).
kbenson 12y ago
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. ;)
- lutusp 12y ago
  > Apparently, people who prefer underscores are more likely to follow through. Or perhaps they're predisposed to underscore their arguments. :)

engineerdollery 12y ago

As long as you follow convention, that's all that matters.

htor 12y ago
As long as you are consistent, that's all that matters.

sotiris-k 12y ago

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

rowanseymour 12y ago
Apparently that's a Microsoft distinction and they use "Pascal case" to describe strings starting with uppercase [1] 1. http://en.wikipedia.org/wiki/CamelCase http://en.wikipedia.org/wiki/CamelCase
lutusp 12y ago
Unless it's the name of a class, not a variable.

Someone1234 12y ago

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 least camcelCase keeps me from reaching for the _ as much and allows me to stay on the A-Za-z more of the time...

kbenson 12y ago
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.
kbd 12y ago
> 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 12y ago
  [deleted]
hga 12y ago
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.
- amyjess 12y ago
  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.
dubya 12y ago

smhenderson 12y ago

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.

RussianCow 12y ago
Agreed. Consistency with existing code and standards trumps any potential gains from using a different style.
ll123 12y ago
What if you're inventing a new language and need to set the convention?

insin 12y ago

Personal 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;

hga 12y ago
(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))) If you follow the normal Lisp pattern of mostly one case and '-' for separation, allowed because Lisps/s-expressions allow the use of the normally reserved '-', I think you get the clearest code. See Clojure for a Lisp that breaks up the sea of Lots of Irritating Sets of Parenthesis if that bothers you.

swhipple 12y ago

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.

logfromblammo 12y ago

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

slm_HN 12y ago

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

libria 12y ago

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.

lutusp 12y ago

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.

deleted 12y ago

[deleted]

dicroce 12y ago

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

murbard2 12y ago

An argument pro underscore: they can be displayed with 50% transparency, making them visible, yet not interfering with the reading of the identifier as much.

fnordsensei 12y ago

I wonder how kebab-case would do. When available, I prefer it.

mturmon 12y ago

For math, underscores evoke the "_ is subscript" convention of TeX. That can be a good thing, e.g. err_total = err_intrinsic + err_extrinsic which might mirror the notation in a paper that the code implements.

Demiurge 12y ago

I don't think they are exclusive? I use CamelCase for object oriented methods, classes and under_scores for procedural code and temporary variables.

teamhappy 12y ago

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; it's fun, isn't it? // BTW: I don't believe anyone telling me they can read camels more efficiently. Underscores add contrast, which aids your vision quite a bit.

louthy 12y ago
> // 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.
- teamhappy 12y ago
  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.
  - louthy 12y ago
    > 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 who have never seen either casing style? But for you to claim that those who disagree with you are drinking Kool-Aid is disingenuous.

wyager 12y ago

Let's not pretend this is anything other than an aesthetic choice. All these "scientific" arguments one way or the other are weak at best.

64bitbrain 12y ago

When I am writing C, I tend to use underscore. I think I just follow the convention, or the code that already exists. Imagine the some part of the code written in camelCase and other used underscore. //This wont look good :) int static set_my_config(char* data); int static getMyConfig();

jgrowl 12y ago

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.

jdontillman 12y ago

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

Gibbon1 12y ago
In c often I use underscores to deal with lack of name spaces and or classes. As in Module_FunctionName()

josephschmoe 12y ago

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

tzs 12y ago
I've often wanted spaces in C. Because C makes heavy use of required punctuation, there aren't many places that a keyword can be adjacent to an identifier, or two identifiers can be adjacent, so for the most part I don't think spaces would introduce ambiguity. 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"?

exogen 12y ago

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.

G3E9 12y ago

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

ars 12y ago

I use both. I use underscore for global functions, and camel case for functions specific to the module. 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.

olav 12y ago

In my eyes, using CamelCase is a kind of cargo cult, based on the fact that the programming language Smalltalk used it. C++ adopted the style and moved away from the predominant use of underscores in C. So, people who want to be seen as modern and object-oriented, are biased to use CamelCase to stress their competence in things OO.

cordite 12y ago

Personally I prefer snake-case but most languages (including the ones I use most) do not support names with dashes in them. That, and it's easier to type (reduction of combo-pressing shift and the key for _)

Someone 12y ago

I would like to see whether mother tongue has an effect on preference. Languages with lots of compounding (http://en.m.wikipedia.org/wiki/Compound_(linguistics) http://en.m.wikipedia.org/wiki/Compound_(linguistics) such as German and Dutch or languages without many spaces such as Classical Latin and Greek, Egyptian hieroglyphics and, sort-of, Chinese and Japanese might make CamelCase look more familiar. I know of one data point: Guido van Rossum is Dutch, and underscores are fairly common in Python (but, on the other hand, https://docs.python.org/3/library/functions.html https://docs.python.org/3/library/functions.html has 'isinstance', 'setattr' and 'memoryview') 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 :-)