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&#x27;re free to run an auto-formatter over your own code.<p>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)<p><pre><code>    uint32_t rgba8888 = ((red   &amp; 0xFF) &lt;&lt; 24) | 
                        ((green &amp; 0xFF) &lt;&lt; 16) |
                        ((blue  &amp; 0xFF) &lt;&lt;  8) |
                        ((alpha &amp; 0xFF) &lt;&lt;  0);
</code></pre>
vs<p><pre><code>    uint32_t rgba8888 = ((red &amp; 0xFF) &lt;&lt; 24) | 
                        ((green &amp; 0xFF) &lt;&lt; 16) |
                        ((blue &amp; 0xFF) &lt;&lt; 8) |
                        (alpha &amp; 0xFF);
</code></pre>
I think the first is objectively more readable than the second. An auto-formatter is unlikely to ever format that in a &quot;readable&quot; way.<p>Another simple example. If I have a many argument function<p><pre><code>    ctx.arc(xPosition, yPosition, radius, startAngle, endAngle, clockwise);
</code></pre>
If I break that line I&#x27;m not going to break it between xPositon and yPosition, nor and I&#x27;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.<p>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.<p>Example, assume 40 char limit<p><pre><code>    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);
</code></pre>
vs<p><pre><code>    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);
</code></pre>
Chrome in particular is full of code line wrapped into what is effectively obfuscated code. So no, I don&#x27;t agree what a line limit has any point.<p>You claim human eyes have a line limit. I don&#x27;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&#x27;s a separate issue. I hope Dart is not targeting Java&#x27;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&#x27;s code or more to effectively be obfusticated.