Hacker News Reader

Comment by robomartin | Hacker News Reader

> Renamed all of the variables to use dashes instead of camelCase.

I absolutely detest camelCase. It ranks down there with good-old Hungarian notation.

So, I am now wondering, why this change? Are people finally coming to their senses?

Preference, readability, consistency with classes, better spell checking, etc. I always felt we should have done dashes instead, but shipping camelCase meant sticking with it for backward compatibility. With v3 though, we're going with our gut and using dashes.

OK, thanks for the explanation.

I'll work with either, but kebab-case(or snake-case with dashes if you prefer) is a lot more readable in HTML source for me.

Also, all their CSS classes were kebab-case anyway, so it makes sense that they'd change their variables to match. It's a nice move towards consistency.

I really want the term "kebab-case" to catch on.

Many text editors view dashes as word separators, so double clicking on a variable name with dashes (to have the editor highlight all places it's being used) will only highlight the word you double clicked on and not the entire variable. This is also the case when moving the cursor by holding command/control and using the arrow keys, the dashes are considered separate words.

For that reason, I prefer using camel case.

What's interesting is underscores are not considered word separators in many text editors.

just-testing-this

JustTestingThis

Hmm. I think it only matters to me that the author picks one and stays with it. But that means that all libraries he uses has to use the same one. Which is why languages tend to prefer one over the other. e.g. Java using CaMeLcAsE

To have them mixed in one code base would be like a micro context switch.

Ah, see, you would have received an error when running this code!

It's "justTestingThis" not "JustTestingThis" if we are talking camel case.

So yeah, camel case and case sensitivity add unnecessary fragility to programming. Which is the reason I don't like the fad. You accidentally made my case.

camelCase vs PascalCasing is used to signal and separate public from private in C#, so that you always know what kind of data or function you are working with.

It's useful.

Having a convention is useful. It doesn't necessarily have to be that particular one.

Sorry to be pedantic but these are wrong examples:

just-testing-this ---> just_testing_this

JustTestingThis ---> justTestingThis

The second one is less dramatic but the first one would in most languages subtract testing and this from just.

isn't justTestingThis a variable name and JustTestingThis a class/struct name?

I think most people have enough processing bandwidth to cope with external libraries using a different convention to inhouse code.

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.

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

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

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

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.

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

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.

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.

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

fwiw, we generally just try to do what the language does:

border-radius <- css dashes

document.createElement <- js camel (except constants, etc.)

etc…

This is the correct rationale, and should be used to end every argument about naming conventions.

what about the programmers who made javascript and css? I'm sure they flame each other!

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.

English is not my native language but I hate code with non-English variable names.

Why is it important that your code is visually set apart from the rest of the language?

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.

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.

Surely there are better ways to deal with this problem. Different languages have different solutions for this, but completely breaking the naming conventions doesn't seem like the way to go.

That's a really bad thing in my eyes. Why teach a beginner that consistency is something that does not exist?

Also, non-english variables are an abomination! I've worked with code with some finnish variables. Not only is it harder to grok, it's actively distracting.

this

AFAIK CSS uses camelCase for variables.[1]

1: http://css-tricks.com/currentcolor/

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

[*class|="text"] will also matched textWarning, textInfo, textCenter, etc.

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

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.

I believe that, exactly as the utterly retarded "TAB vs space" debate, the "cameCase vs dash" should be a non-issue. This should be solved at the text editor / IDE level and at the tools level and should not cause any issue.

Put it this way: I can trivially write an Emacs minor mode that detects cameCase and shows them as dashes and vice-versa.

This should be something each programmer could decide on its own, as long as the commits are using the same convention.

Now, also, maybe maybe maybe that it shouldn't be language recommandations but specs defined in the language.

A bit like how the Go language close shut the big mouths of people advocating for this or that place for brackets.

For what it's worth I'd configure my text editor to show names using dashes instead of camelCase...

I think the big difference is that camel case added to the ridiculous idea of designing programming languages that are case sensitive just makes for unnecessary friction.

Tab vs. spaces will not cause code to break, mistyping camel case in a case sensitive language does. Neither camel case nor case sensitivity makes programming easier, better, faster, less error-prone, clearer, more accurate, et. In other words, it serves no useful purpose other than feeding a fad.

Tab vs. spaces? Don't really care. There are good reasons for going ether way. As long as the tab key does the indentation I, personally, couldn't care less which way it goes. My code will not break if I enter a bunch of spaces instead of tabs.

> Tab vs. spaces will not cause code to break

Well, mixing them can. Python, for example.

I literally just started going through Project Euler with Python now to get comfortable with the language.

I'll play with that and see. I can't think of any other language where this might matter.

Should I look for anything in particular or simply tabs vs space in indentation on any code?

    # Problems from ProjectEuler.net

    # http://projecteuler.net/problem=1
    def problem_1():
        return sum([n for n in range(1000) if (n%3 == 0) or (n%5 == 0)])


    def problem_1a():
        return sum(set(range(3,1000,3) +  range(5,1000,5)))


    # http://projecteuler.net/problem=2
    def problem_2():
        sequence = [1,2]
        while sequence[-1] < 4000000:
            sequence.append(sum(sequence[-2:]))
        if sequence[-1] > 4000000:
            sequence.pop()
        return sum([n for n in sequence if (n%2 == 0)])

I did say I was just getting started!

I'll try the above and other code I wrote with a mixture of tabs and spaced and see what happens. Interesting. If Python actually breaks because of that it's a shame. I really like the language. Is it a matter of IDE interpreter (type code and execute interactively) vs. command-line interpreter (same as previous) vs. module execution (i.e.: "python my_module.py" from the command prompt)?

If I recall correctly, Python's indentation counts characters, so a single tab is not the equivalent of four or eight spaces, but only one. If you accidentally mix them, therefore, lining things up visually in your editor will result in indenting or outdenting where you did not intend.

> I'll play with that and see. I can't think of any other language where this might matter.

CoffeeScript as well, if I recall the indentation rules correctly.

Reply on news.ycombinator.com