Hacker News new | past | comments | ask | show | jobs | submit login

The idea of an auto-formatter has come up many times on the Chrome team. It is always shot down because formatting often imparts meaning. Meaning that is unclear to an auto-formatter. Of course you're free to run an auto-formatter over your own code.

Often I want to format things that are more readable for me. Example (yea, not Google style guide example. Too lazy to dig one up)

    uint32_t rgba8888 = ((red   & 0xFF) << 24) | 
                        ((green & 0xFF) << 16) |
                        ((blue  & 0xFF) <<  8) |
                        ((alpha & 0xFF) <<  0);
vs

    uint32_t rgba8888 = ((red & 0xFF) << 24) | 
                        ((green & 0xFF) << 16) |
                        ((blue & 0xFF) << 8) |
                        (alpha & 0xFF);
I think the first is objectively more readable than the second. An auto-formatter is unlikely to ever format that in a "readable" way.

Another simple example. If I have a many argument function

    ctx.arc(xPosition, yPosition, radius, startAngle, endAngle, clockwise);
If I break that line I'm not going to break it between xPositon and yPosition, nor and I'm going to break it between startAngle and endAngle. An auto-formatter will never know that semantically those things are more readable when they are on the same line.

Similarly you claim the short length encourages shorting names but you still run into plenty of situations where the code is far far less readable because of the line limit.

Example, assume 40 char limit

    int w = desired_width *
        scale_factor + padding;
    int h = desired_height *
        scale_factor + padding;

    glBindTexture(
        GL_TEXTURE_2D, someTexture);
    glTexImage2D(
        GL_TEXTURE_2D, level, format, 
        w, h, border, format, type, data);
    glTexParameter(
        GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, 
        GL_REPEAT);
vs

    int w = desired_width  * scale_factor + padding;
    int h = desired_height * scale_factor + padding;

    glBindTexture(GL_TEXTURE_2D, someTexture);
    glTexImage2D(GL_TEXTURE_2D, level, format, w, h, border, format, type, data);
    glTexParameter(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_REPEAT);
Chrome in particular is full of code line wrapped into what is effectively obfuscated code. So no, I don't agree what a line limit has any point.

You claim human eyes have a line limit. I don't disagree per say, but in my years before Google I never found anyone seriously abusing line length. Then again I never had to use Java but that's a separate issue. I hope Dart is not targeting Java's verboseness. I could make the same claim that unbroken lines, up to a point, are more readable, understandable and I will go on to claim that the 80 char limit at Google breaks that rule and ends up cause 20% of Google's code or more to effectively be obfusticated.




My eyes (much) prefer the 40-char version to that last code at the end, though I might do it like so:

    int w, h;
    
    w = desired_width;
    w *= scale_factor;
    w += padding;
    
    h = desired_height;
    h *= scale_factor;
    h += padding;

    glBindTexture(
        GL_TEXTURE_2D, someTexture
    );
    glTexImage2D(
        GL_TEXTURE_2D, level, format, 
        w, h, border, format, type, data
    );
    glTexParameter(
        GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, 
        GL_REPEAT
    );
That's assuming C, for C++ I might start it off like so:

    int w = desired_width;
    w *= scale_factor;
    w += padding;
    
    int h = desired_height;
    h *= scale_factor;
    h += padding;
I might be tempted to use a macro but likely pass and just use shorter names all around.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: