6 ms·

I don't want to start a flame war, but I was wondering if there is a rationale for prefering dash-case? I have a hard time not writing in camelCase by default n

by rtpg 14y ago

I don't want to start a flame war, but I was wondering if there is a rationale for prefering dash-case? I have a hard time not writing in camelCase by default now.

roel_v 14y ago
"I don't want to start a flame war, but I was wondering if there is a rationale for prefering dash-case?" No, there isn't. It's one of those typical things that novice programmers fret about. Consistency within a code base is much more important than which style is used exactly. Having the style be a compile parameter would make sense to me, not switching from one to the other.
- beagle3 14y ago
  > Consistency within a code base is much more important than which style is used exactly. I know this is a commonly held belief, and I held it too for a short while. But then, I was managing a project that ran on both Linux (lower_case_name libraries), Windows (CapitalizeEachWord), had components in Python (ClassesAreLikeThis but variables_like_this), Java (camelCaseIsAnAbomination) and even some VB6 (don't even remember the convention). Utterly inconsistent. And it didn't make any difference to readability or maintainability, once people accepted that there actually is no single standard we can use. In my opinion, it's one of these things like, e.g. significant whitespace or C brace style, that people believe make a difference because they have an example - in which the difference is often not attributable to the feature being discussed.
  - roel_v 14y ago
    Well within several modules of the same project, I guess it's inevitable, and not that problematic, especially not between several languages; but seeing (at the top of one function) int my_counter; char hostName[256]; double LIFESPAN; doesn't make for pleasant reading, I'm sure you agree.
    - beagle3 14y ago
      But in a large enough project, there are several modules that cannot escape that: Our main codebase used unix_conventional_names. Then, a GUI (FLTK, C++) was added, with classes like Fl_DoubleWindow; Every GUI part now had two conventions. Then, it turned out that the abstractions FLTK gave on Windows needed a small nudge. So we added some Windows-specific stuff; that module had calls like FLTK Fl_RadioButton, Win32's TrackMouse, our main code's "user_action_t". Then we added needed to add Python scripting (implementing a native Python module in C) - and since the most maintainable way to do that was to have the C names and Python names correspond, there's a module that also had Python convention names in it. Lather, rinse, repeat with JNI. So, I would guess ~ 70% of the files ended up being "uniform convention" (with one convention, depending on source code language), and 30% had mixed conventions of up to 4 conventions. And it didn't make anything a little bit unreadable. It's no more distracting than changing fonts in a document every paragraph (and occasionally in the middle of a paragraph) between several readable standard fonts (arial, courier, consolas, ...). It looks weird and bothering for the first few days, but is not actually distracting or hampering in any way. And if anyone is going to reply "but new people who come into the codebase will be confused" - that codebase was moving millions of dollars per day, and was nontrivial enough that I wouldn't allow anyone to commit a change on their first week, often their first month, without two other people reviewing it (experienced people got only one person to review their code). By the time anyone knew the code well enough to make a change, they weren't bothered by the multiple conventions either. > doesn't make for pleasant reading, I'm sure you agree. only lifespan, the upper case implying constantness when it isn't, bothers me. Other than that - pleasant as day.
  - mgkimsal 14y ago
    those are essentially different code bases (python/java/vb6). As the other replier wrote, having different style variables and naming conventions in the same project - really, the same file - is somewhat distracting. <?php $x = 55; $numberOfPeopleEmailed = 23; $What_The_User_Chose = $_POST['chosen']; do_something_withVarName($x); $sFirst_Name = _$_POST['name']; it gets distracting. While it's been rare for me, I've occasionally dealt with large files with different styles of var naming contributed by different people. It's far more of a mental nuisance than tabs-v-spaces (I'm a tabs guy, fwiw).
- robomartin 14y ago
  > It's one of those typical things that novice programmers fret about. I think you might be generalizing a little too far here. I've been programming for over thirty years in more languages than I care to remember. Every so often a meme of some sort raises to the surface and the sheep jump on it. Hungarian notation was probably one of the ugliest of all. Case sensitivity is another. And, case sensitivity added to camel case just makes your job that much harder for no good reason at all: autoDetectMotorPhaseAngleAndSpeed Is horribly unreadable and gives you many opportunities to make a typing mistake and cause development delays. auto-detect-motor-phase-angle-and-speed Is super-easy to read and type. Less entry errors and legible code are important. If you think that this is a newbie "mistake", well, they are right.
  - blowski 14y ago
    Any actual research to support that, or is it just an opinion? As I can't find any data, I've asked on programmers.stackexchange.com. http://programmers.stackexchange.com/questions/186407/are-there-any-studies-that-say-camelcase-is-more-or-less-readable-than-dashes http://programmers.stackexchange.com/questions/186407/are-th...
    - robomartin 14y ago
      Let's see how long that one stays open! :-) From one of the answers: "results indicate a significant improvement in time and lower visual effort with the underscore style. The interaction of Experience with Style indicates that novices benefit twice as much with respect to time, with the underscore style." Having said what I said, I'll program in any language and abide by any convention if required. That's just what you have to do as a programmer. No issues there. If a client requires camelCase, so be it, it's not like it is crippling. If I have the freedom to do so, I tend to be very pragmatic about my own projects. I don't subscribe to fads both in my personal life and in software development. Camel case and Hungarian notation are just fads that, when surfaced, may or may not survive the test of time. The second, for the most part, did not. We'll see what happens with Camel case. None of this crap is necessary to write good code, or code that is bug-free, or code that makes you money. Life goes on. Those who love to camelCase, hey, it's OK, not the end of the world.
fat 14y ago
fwiw, we generally just try to do what the language does: border-radius <- css dashes document.createElement <- js camel (except constants, etc.) etc…
- mullr 14y ago
  This is the correct rationale, and should be used to end every argument about naming conventions.
  - rschmitty 14y ago
    what about the programmers who made javascript and css? I'm sure they flame each other!
- rgo 14y ago
  I personally prefer using the exact oposite to the language. That way my code or customizations are set apart visually: obj.getSomethingById() <-- theirs obj.redraw_panel() <-- mine Non-native English speakers sometimes prefer to name variables in their native language for the same reason.
  - Sandman 14y ago
    Why is it important that your code is visually set apart from the rest of the language?
    - RobAley 14y ago
      When someone, particularly a beginner, is reading the code and come across, say, an unfamiliar function name, then they know straight away whether to look for it in the language docs or a definition somewhere else in the code. Not essential, but handy.
      - joesb 14y ago
        I guess that only works for really simple project. Once you bring in third party libraries, your own common library, your own multiple layers of abstraction, this naming convention means almost nothing. It pays the price of annoying programmers who are already familiar with the code for not-so useful short term benefit of the very early beginner.
flaie 14y ago
I believe it could be usefull for CSS selectors[1] The following rule will match for values of the "lang" attribute that begin with "en", including "en", "en-US", and "en-cockney": *[lang|="en"] { color : red } So you may now be able to select with CSS elements with that syntax, for example matching all text-warning, text-info, text-center etc with just *[class|="text"] { font-weight: bold } Correct me if I'm wrong. I don't know if it would be practical or not. Other than that it just a matter of preference, CSS classes tends to be generally separated by dashes from my point of view, whether I prefer Camel Case or not. [1]: http://www.w3.org/TR/CSS2/selector.html#attribute-selectors http://www.w3.org/TR/CSS2/selector.html#attribute-selectors
- joesb 14y ago
  [*class|="text"] will also matched textWarning, textInfo, textCenter, etc.
  - flaie 14y ago
    Seems strange to me since the spec says the following: Represents an element with the att attribute, its value either being exactly "val" or beginning with "val" immediately followed by "-" (U+002D). it should match text-foo or text but not textFoo
    - jackmoore 14y ago
      You are correct, that selector would not match textFoo. It is the same as [class^=text-]. The real problem with using these attribute selectors with classes is that they only apply to the first class in the class list. If your element was something like "<p class='content text-foo'>", then it would not be matched by that selector.

by rtpg 14y ago

I don't want to start a flame war, but I was wondering if there is a rationale for prefering dash-case? I have a hard time not writing in camelCase by default now.

roel_v 14y ago

"I don't want to start a flame war, but I was wondering if there is a rationale for prefering dash-case?" No, there isn't. It's one of those typical things that novice programmers fret about. Consistency within a code base is much more important than which style is used exactly. Having the style be a compile parameter would make sense to me, not switching from one to the other.

beagle3 14y ago
> Consistency within a code base is much more important than which style is used exactly. I know this is a commonly held belief, and I held it too for a short while. But then, I was managing a project that ran on both Linux (lower_case_name libraries), Windows (CapitalizeEachWord), had components in Python (ClassesAreLikeThis but variables_like_this), Java (camelCaseIsAnAbomination) and even some VB6 (don't even remember the convention). Utterly inconsistent. And it didn't make any difference to readability or maintainability, once people accepted that there actually is no single standard we can use. In my opinion, it's one of these things like, e.g. significant whitespace or C brace style, that people believe make a difference because they have an example - in which the difference is often not attributable to the feature being discussed.
- roel_v 14y ago
  Well within several modules of the same project, I guess it's inevitable, and not that problematic, especially not between several languages; but seeing (at the top of one function) int my_counter; char hostName[256]; double LIFESPAN; doesn't make for pleasant reading, I'm sure you agree.
  - beagle3 14y ago
    But in a large enough project, there are several modules that cannot escape that: Our main codebase used unix_conventional_names. Then, a GUI (FLTK, C++) was added, with classes like Fl_DoubleWindow; Every GUI part now had two conventions. Then, it turned out that the abstractions FLTK gave on Windows needed a small nudge. So we added some Windows-specific stuff; that module had calls like FLTK Fl_RadioButton, Win32's TrackMouse, our main code's "user_action_t". Then we added needed to add Python scripting (implementing a native Python module in C) - and since the most maintainable way to do that was to have the C names and Python names correspond, there's a module that also had Python convention names in it. Lather, rinse, repeat with JNI. So, I would guess ~ 70% of the files ended up being "uniform convention" (with one convention, depending on source code language), and 30% had mixed conventions of up to 4 conventions. And it didn't make anything a little bit unreadable. It's no more distracting than changing fonts in a document every paragraph (and occasionally in the middle of a paragraph) between several readable standard fonts (arial, courier, consolas, ...). It looks weird and bothering for the first few days, but is not actually distracting or hampering in any way. And if anyone is going to reply "but new people who come into the codebase will be confused" - that codebase was moving millions of dollars per day, and was nontrivial enough that I wouldn't allow anyone to commit a change on their first week, often their first month, without two other people reviewing it (experienced people got only one person to review their code). By the time anyone knew the code well enough to make a change, they weren't bothered by the multiple conventions either. > doesn't make for pleasant reading, I'm sure you agree. only lifespan, the upper case implying constantness when it isn't, bothers me. Other than that - pleasant as day.
- mgkimsal 14y ago
  those are essentially different code bases (python/java/vb6). As the other replier wrote, having different style variables and naming conventions in the same project - really, the same file - is somewhat distracting. <?php $x = 55; $numberOfPeopleEmailed = 23; $What_The_User_Chose = $_POST['chosen']; do_something_withVarName($x); $sFirst_Name = _$_POST['name']; it gets distracting. While it's been rare for me, I've occasionally dealt with large files with different styles of var naming contributed by different people. It's far more of a mental nuisance than tabs-v-spaces (I'm a tabs guy, fwiw).
robomartin 14y ago
> It's one of those typical things that novice programmers fret about. I think you might be generalizing a little too far here. I've been programming for over thirty years in more languages than I care to remember. Every so often a meme of some sort raises to the surface and the sheep jump on it. Hungarian notation was probably one of the ugliest of all. Case sensitivity is another. And, case sensitivity added to camel case just makes your job that much harder for no good reason at all: autoDetectMotorPhaseAngleAndSpeed Is horribly unreadable and gives you many opportunities to make a typing mistake and cause development delays. auto-detect-motor-phase-angle-and-speed Is super-easy to read and type. Less entry errors and legible code are important. If you think that this is a newbie "mistake", well, they are right.
- blowski 14y ago
  Any actual research to support that, or is it just an opinion? As I can't find any data, I've asked on programmers.stackexchange.com. http://programmers.stackexchange.com/questions/186407/are-there-any-studies-that-say-camelcase-is-more-or-less-readable-than-dashes http://programmers.stackexchange.com/questions/186407/are-th...
  - robomartin 14y ago
    Let's see how long that one stays open! :-) From one of the answers: "results indicate a significant improvement in time and lower visual effort with the underscore style. The interaction of Experience with Style indicates that novices benefit twice as much with respect to time, with the underscore style." Having said what I said, I'll program in any language and abide by any convention if required. That's just what you have to do as a programmer. No issues there. If a client requires camelCase, so be it, it's not like it is crippling. If I have the freedom to do so, I tend to be very pragmatic about my own projects. I don't subscribe to fads both in my personal life and in software development. Camel case and Hungarian notation are just fads that, when surfaced, may or may not survive the test of time. The second, for the most part, did not. We'll see what happens with Camel case. None of this crap is necessary to write good code, or code that is bug-free, or code that makes you money. Life goes on. Those who love to camelCase, hey, it's OK, not the end of the world.

fat 14y ago

fwiw, we generally just try to do what the language does: border-radius <- css dashes document.createElement <- js camel (except constants, etc.) etc…

mullr 14y ago
This is the correct rationale, and should be used to end every argument about naming conventions.
- rschmitty 14y ago
  what about the programmers who made javascript and css? I'm sure they flame each other!
rgo 14y ago
I personally prefer using the exact oposite to the language. That way my code or customizations are set apart visually: obj.getSomethingById() <-- theirs obj.redraw_panel() <-- mine Non-native English speakers sometimes prefer to name variables in their native language for the same reason.
- Sandman 14y ago
  Why is it important that your code is visually set apart from the rest of the language?
  - RobAley 14y ago
    When someone, particularly a beginner, is reading the code and come across, say, an unfamiliar function name, then they know straight away whether to look for it in the language docs or a definition somewhere else in the code. Not essential, but handy.
    - joesb 14y ago
      I guess that only works for really simple project. Once you bring in third party libraries, your own common library, your own multiple layers of abstraction, this naming convention means almost nothing. It pays the price of annoying programmers who are already familiar with the code for not-so useful short term benefit of the very early beginner.

flaie 14y ago

I believe it could be usefull for CSS selectors[1] The following rule will match for values of the "lang" attribute that begin with "en", including "en", "en-US", and "en-cockney": *[lang|="en"] { color : red } So you may now be able to select with CSS elements with that syntax, for example matching all text-warning, text-info, text-center etc with just *[class|="text"] { font-weight: bold } Correct me if I'm wrong. I don't know if it would be practical or not. Other than that it just a matter of preference, CSS classes tends to be generally separated by dashes from my point of view, whether I prefer Camel Case or not. [1]: http://www.w3.org/TR/CSS2/selector.html#attribute-selectors http://www.w3.org/TR/CSS2/selector.html#attribute-selectors

joesb 14y ago
[*class|="text"] will also matched textWarning, textInfo, textCenter, etc.
- flaie 14y ago
  Seems strange to me since the spec says the following: Represents an element with the att attribute, its value either being exactly "val" or beginning with "val" immediately followed by "-" (U+002D). it should match text-foo or text but not textFoo
  - jackmoore 14y ago
    You are correct, that selector would not match textFoo. It is the same as [class^=text-]. The real problem with using these attribute selectors with classes is that they only apply to the first class in the class list. If your element was something like "<p class='content text-foo'>", then it would not be matched by that selector.