New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Say something useful about comma-first #32

Closed
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
4 participants
@ricardobeat

ricardobeat commented Apr 2, 2012

This change removes the reference to the mozilla.org thread and adds meaningful reading recommendations. The example in that link isn't really used or encouraged by anyone:

var middleware = [ context,
                 , csrf
                 , xsite
                 , head
                 , considtional
                 , error
                 ] // wat

I don't want to get into a discussion about the style here, but the argument is that it's hard to spot the errant comma on the first line. It's just as hard as it is to notice a missing comma in standard style:

var middleware = [
  context,
  csrf,
  xsite
  head,
  conditional,
  error
]

And this is actual comma-first style (with an error):

var middleware = [
    context
  , csrf
    xsite
  , head
  , conditional
  , error
]

It's perfectly reasonable to mix the recommendations in this document with comma-first or even no-semicolon styles (except that 4-char spacing looks better with it), and be respectful for other's choices. The links point to relevant and civilized discussions on the subject.

@rwaldron

This comment has been minimized.

Show comment
Hide comment
@rwaldron

rwaldron Apr 2, 2012

Owner

I think you misunderstood the point of that link... All I care about is the quote from Brendan that calls comma-first "horrible".

I don't appreciate your hyper-aggro approach to contribution, so how about this: instead of deleting or replacing relevant content, just add even more relevant content and I'll gladly pull in your changes. Thanks!

Owner

rwaldron commented Apr 2, 2012

I think you misunderstood the point of that link... All I care about is the quote from Brendan that calls comma-first "horrible".

I don't appreciate your hyper-aggro approach to contribution, so how about this: instead of deleting or replacing relevant content, just add even more relevant content and I'll gladly pull in your changes. Thanks!

@ricardobeat

This comment has been minimized.

Show comment
Hide comment
@ricardobeat

ricardobeat Apr 3, 2012

I think you misunderstood the point of my pull request. I have no idea what "hyper-aggro" means, I assume you found my edits aggressive? Did you read the edits? I added links with meaningful discussion on the subject, to replace the one e-mail that just stays it's terrible based on a misguided example.

Passive-aggressive is much better, ain't it? Sorry for interrupting.

ricardobeat commented Apr 3, 2012

I think you misunderstood the point of my pull request. I have no idea what "hyper-aggro" means, I assume you found my edits aggressive? Did you read the edits? I added links with meaningful discussion on the subject, to replace the one e-mail that just stays it's terrible based on a misguided example.

Passive-aggressive is much better, ain't it? Sorry for interrupting.

@ricardobeat ricardobeat closed this Apr 3, 2012

@rwaldron rwaldron reopened this Apr 3, 2012

@rwaldron

This comment has been minimized.

Show comment
Hide comment
@rwaldron

rwaldron Apr 3, 2012

Owner

The "dumb example" is irrelevant. The comment about comma-first is a general statement. Anyway, I've re-opened... What I was hoping is that you'd modify the PR to add your new content, but not remove content.

Owner

rwaldron commented Apr 3, 2012

The "dumb example" is irrelevant. The comment about comma-first is a general statement. Anyway, I've re-opened... What I was hoping is that you'd modify the PR to add your new content, but not remove content.

@rwaldron

This comment has been minimized.

Show comment
Hide comment
@rwaldron

rwaldron Apr 3, 2012

Owner

Just to clarify, this was the part that I felt was aggressive:

It's perfectly reasonable to mix the recommendations in this document with comma-first or even no-semicolon styles (except that 4-char spacing looks better with it), and be respectful for other's choices. The links point to relevant and civilized discussions on the subject.

Owner

rwaldron commented Apr 3, 2012

Just to clarify, this was the part that I felt was aggressive:

It's perfectly reasonable to mix the recommendations in this document with comma-first or even no-semicolon styles (except that 4-char spacing looks better with it), and be respectful for other's choices. The links point to relevant and civilized discussions on the subject.

@ricardobeat

This comment has been minimized.

Show comment
Hide comment
@ricardobeat

ricardobeat Apr 3, 2012

There is no real discussion in that thread, therefore I think the link and quote at the bottom aren't in good spirit. Feel free to ammend the commit.

ricardobeat commented Apr 3, 2012

There is no real discussion in that thread, therefore I think the link and quote at the bottom aren't in good spirit. Feel free to ammend the commit.

@rwaldron

This comment has been minimized.

Show comment
Hide comment
@rwaldron

rwaldron Apr 3, 2012

Owner

btw: Dean Landolt said it's horrible, not Brendan.

orly?

https://mail.mozilla.org/pipermail/es-discuss/2011-September/016802.html

Owner

rwaldron commented Apr 3, 2012

btw: Dean Landolt said it's horrible, not Brendan.

orly?

https://mail.mozilla.org/pipermail/es-discuss/2011-September/016802.html

@dvdotsenko

This comment has been minimized.

Show comment
Hide comment
@dvdotsenko

dvdotsenko Apr 4, 2012

I am a serious fan of comma-first, yet, too, just like Brendan Eich find this the code block Dean Landolt offers truly horrible.

This formatting style (dangling first arg at the end of object / list declaration is error-inducing regardless of your comma positioning style:

var middleware = [ context,
                 , csrf
                 , xsite
                 , head
                 , considtional
                 , error
                 ]

Regardless of the comma-positioning style, the first arg in a list MUST go on separate line + extra "tab"

var middleware = [ 
    context
    , csrf
    , xsite
    , head
    , considtional
    , error
]

This way, you never lose the visual track of it.

This is similar to the suggestion to avoid dangling comments at the ends of code lines.

The problem that leads to mistakes is not due to frontal or rear positioning of the comma (although, the consensus train is in: comma on front is much easier to keep track of), but the mixing of the styles. If you mix styles you are in deep dudu.

Thus, i would also suggest to remove the reference to B Eich's derogatory comment, as it does NOT seem be able to prove that comma-first is wrong, but rightfully states that the codeer who could write this:

var middleware = [ context,
                 , csrf
                 , xsite
                 , head
                 , considtional
                 , error
                 ]

is simply a dumb ass.

dvdotsenko commented Apr 4, 2012

I am a serious fan of comma-first, yet, too, just like Brendan Eich find this the code block Dean Landolt offers truly horrible.

This formatting style (dangling first arg at the end of object / list declaration is error-inducing regardless of your comma positioning style:

var middleware = [ context,
                 , csrf
                 , xsite
                 , head
                 , considtional
                 , error
                 ]

Regardless of the comma-positioning style, the first arg in a list MUST go on separate line + extra "tab"

var middleware = [ 
    context
    , csrf
    , xsite
    , head
    , considtional
    , error
]

This way, you never lose the visual track of it.

This is similar to the suggestion to avoid dangling comments at the ends of code lines.

The problem that leads to mistakes is not due to frontal or rear positioning of the comma (although, the consensus train is in: comma on front is much easier to keep track of), but the mixing of the styles. If you mix styles you are in deep dudu.

Thus, i would also suggest to remove the reference to B Eich's derogatory comment, as it does NOT seem be able to prove that comma-first is wrong, but rightfully states that the codeer who could write this:

var middleware = [ context,
                 , csrf
                 , xsite
                 , head
                 , considtional
                 , error
                 ]

is simply a dumb ass.

@rwaldron

This comment has been minimized.

Show comment
Hide comment
@rwaldron

rwaldron Apr 4, 2012

Owner

While I certainly appreciate your feedback, I'm not going to remove the link to the comment (for now anyway). Your note "consensus" is definitely questionable (that's putting it nicely, too be honest)

Owner

rwaldron commented Apr 4, 2012

While I certainly appreciate your feedback, I'm not going to remove the link to the comment (for now anyway). Your note "consensus" is definitely questionable (that's putting it nicely, too be honest)

@dvdotsenko

This comment has been minimized.

Show comment
Hide comment
@dvdotsenko

dvdotsenko Apr 4, 2012

Incidentally, with comma-first, the multi-var declaration, arguably, may make more sense in comparison to comma-last. If a section on comma-first it to be improved, suggest considering this format for var block:

var a = "asdf"
, b = "qwer"
, c = "zxvc"
, d = "lkjh"

as opposed to, say, this:

var a = "asdf"
    , b = "qwer"
    , c = "zxvc"
    , d = "lkjh"

The first form feels and looks very close to:

var a = "asdf"
var b = "qwer"
var c = "zxvc"
var d = "lkjh"

and saves your day when vars are multiline nested objects. Observe, how returning to the depth of 'var' keeps you aware of how deep and inside of which object you are:

var a = function(){
    // long
    // whinding
    // function
}
, b = function(){
    // long
    // whinding
    // function
}
, c = function(){
    // long
    // whinding
    // function
}
, d = function(){
    // long
    // whinding
    // function
}

Compare to the following, where by the time your eyes get to 'd = ...' you are wondering "Where are we? Is this still part of var above, or are we changing global or some, deep in-scope 'd'?

var a = function(){
        // long
        // whinding
        // function
    },
    b = function(){
        // long
        // whinding
        // function
    }, 
    c = function(){
        // long
        // whinding
        // function
    },
    d = function(){
        // long
        // whinding
        // function
    }

dvdotsenko commented Apr 4, 2012

Incidentally, with comma-first, the multi-var declaration, arguably, may make more sense in comparison to comma-last. If a section on comma-first it to be improved, suggest considering this format for var block:

var a = "asdf"
, b = "qwer"
, c = "zxvc"
, d = "lkjh"

as opposed to, say, this:

var a = "asdf"
    , b = "qwer"
    , c = "zxvc"
    , d = "lkjh"

The first form feels and looks very close to:

var a = "asdf"
var b = "qwer"
var c = "zxvc"
var d = "lkjh"

and saves your day when vars are multiline nested objects. Observe, how returning to the depth of 'var' keeps you aware of how deep and inside of which object you are:

var a = function(){
    // long
    // whinding
    // function
}
, b = function(){
    // long
    // whinding
    // function
}
, c = function(){
    // long
    // whinding
    // function
}
, d = function(){
    // long
    // whinding
    // function
}

Compare to the following, where by the time your eyes get to 'd = ...' you are wondering "Where are we? Is this still part of var above, or are we changing global or some, deep in-scope 'd'?

var a = function(){
        // long
        // whinding
        // function
    },
    b = function(){
        // long
        // whinding
        // function
    }, 
    c = function(){
        // long
        // whinding
        // function
    },
    d = function(){
        // long
        // whinding
        // function
    }
@dvdotsenko

This comment has been minimized.

Show comment
Hide comment
@dvdotsenko

dvdotsenko Apr 4, 2012

Re: Your note "consensus" is definitely questionable (that's putting it nicely, too be honest).

I admit, it's hard to be objective on this issue once you settle into a particular habit. With time your habit become "convention" and, then, "the right thing to do"

The consensus on "Where is it easier to see the comma" IS IN - in front. It's kinda hard to argue with that. It does not, by itself, mean that it's the right thing to do, in light of "convention" and established "the right thing to do", but when you take this question alone, and answer it honestly = "in front"

The example described as "horrible" by Brendan is actually an example of a flawed perspective. The comma that people miss in that example is the comma at the end. I could use this same exact example for arguing "never put commas at the end. they are bad, you will miss them. m'kay"

The removal of the example was suggested not because i disagree with Brendan's sentiment, but because it's actually a bad example to argue any side, and "comma-at-the-end" specifically as that ending comma is actually the problem. Same issue of 'undefined' inclusion can occur when you have double comma-at-the-end (for example after clumsy removal of elements from the list).

You have a good collection of "the right thing to do" going. If you choose to be more egalitarian about it, you can have an "Comma-at-front is 'bad,' but if you really choose to do it, here is suggested convention" section. Your present approach to this issue smells "immature" and allows me to question your authority re the rest of the document.

dvdotsenko commented Apr 4, 2012

Re: Your note "consensus" is definitely questionable (that's putting it nicely, too be honest).

I admit, it's hard to be objective on this issue once you settle into a particular habit. With time your habit become "convention" and, then, "the right thing to do"

The consensus on "Where is it easier to see the comma" IS IN - in front. It's kinda hard to argue with that. It does not, by itself, mean that it's the right thing to do, in light of "convention" and established "the right thing to do", but when you take this question alone, and answer it honestly = "in front"

The example described as "horrible" by Brendan is actually an example of a flawed perspective. The comma that people miss in that example is the comma at the end. I could use this same exact example for arguing "never put commas at the end. they are bad, you will miss them. m'kay"

The removal of the example was suggested not because i disagree with Brendan's sentiment, but because it's actually a bad example to argue any side, and "comma-at-the-end" specifically as that ending comma is actually the problem. Same issue of 'undefined' inclusion can occur when you have double comma-at-the-end (for example after clumsy removal of elements from the list).

You have a good collection of "the right thing to do" going. If you choose to be more egalitarian about it, you can have an "Comma-at-front is 'bad,' but if you really choose to do it, here is suggested convention" section. Your present approach to this issue smells "immature" and allows me to question your authority re the rest of the document.

@rwaldron

This comment has been minimized.

Show comment
Hide comment
@rwaldron

rwaldron Apr 5, 2012

Owner

Thanks for the book, but none of your arguments will ever convince me that comma first is somehow better or easier to read.

...But you've succeeded in sufficiently annoying the piss out of me enough to move me to remove mention of it. The practice is insane, noisy and out right atrocious to look at, but I really don't want to read through another essay expounding the merits of comma-first practice. Really, I don't.

For what it's worth, I just asked my girlfriend, who is not a programmer, to look at your examples above (that compare the two styles one after the other) and tell me what she thought (with no bias input from me) . In her opinion, your way is "weird and hard to follow from one line to the next".

Owner

rwaldron commented Apr 5, 2012

Thanks for the book, but none of your arguments will ever convince me that comma first is somehow better or easier to read.

...But you've succeeded in sufficiently annoying the piss out of me enough to move me to remove mention of it. The practice is insane, noisy and out right atrocious to look at, but I really don't want to read through another essay expounding the merits of comma-first practice. Really, I don't.

For what it's worth, I just asked my girlfriend, who is not a programmer, to look at your examples above (that compare the two styles one after the other) and tell me what she thought (with no bias input from me) . In her opinion, your way is "weird and hard to follow from one line to the next".

@rwaldron rwaldron closed this Apr 5, 2012

@ricardobeat

This comment has been minimized.

Show comment
Hide comment
@ricardobeat

ricardobeat Apr 7, 2012

My grandmother disagrees.

ricardobeat commented Apr 7, 2012

My grandmother disagrees.

@michaelficarra

This comment has been minimized.

Show comment
Hide comment
@michaelficarra

michaelficarra Apr 7, 2012

I just asked my girlfriend, who is not a programmer, to look at your examples above

Seriously? I don't think your girlfriend is going to be able to base her decision on the important aspects of a syntax/style like the likelihood (and severity of consequence) of accidental typos/omissions. For what it's worth, my girlfriend says your girlfriend is "weird" and "hard to follow from one line to the next". Not like she knows what criteria to base her opinion on, though...

michaelficarra commented Apr 7, 2012

I just asked my girlfriend, who is not a programmer, to look at your examples above

Seriously? I don't think your girlfriend is going to be able to base her decision on the important aspects of a syntax/style like the likelihood (and severity of consequence) of accidental typos/omissions. For what it's worth, my girlfriend says your girlfriend is "weird" and "hard to follow from one line to the next". Not like she knows what criteria to base her opinion on, though...

@rwaldron

This comment has been minimized.

Show comment
Hide comment
@rwaldron

rwaldron Apr 7, 2012

Owner

Feel free to fork and tailor to your needs - this has always been a "per project" document. kthx

Owner

rwaldron commented Apr 7, 2012

Feel free to fork and tailor to your needs - this has always been a "per project" document. kthx

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment