I didn't think that way until very recently, and then something occured to me: limiting things to 80 characters means you can fit more vertical strips of code on your screen without line breaks. On a 1920x1080 screen with a 6x13 font[1], I can split vim into 4 vertical strips each of which are 79 characters wide. It's not perfect, but it means that my screen is filled with code instead of whitespace. Keeping code width low is like dyanmic-range compression[2] for code.

[1] -Misc-Fixed-Medium-R-SemiCondensed--13-120-75-75-C-60-ISO10646-1 (I have yet to find a more readable font with those metrics, and I've looked hard) [2] http://en.wikipedia.org/wiki/Dynamic_range_compression

I don't. I use descriptive names for functions and short, concise words for variables (sometimes clear abbreviations).

> Another nit, Google Style guides disallow formatting for readability except for comments?!?!

> Allowed

> [regularly formatted variable declarations]

> Not allowed

> ["pretty" formatted variable declarations with indentation]

Code Complete 2 explicitly discourages the latter style, and I tend to agree. It's too difficult to maintain.

That might work. Unfortunately abbreviations are forbidden by the Google Style Guide.

> As for lining up

my point still holds. Either lining up helps or it doesn't. If it doesn't help then lining up comments should not be allowed. If it does help, then it helps every where.

    var infos = [
      { name: "red",   value: [255,   0,   0, 255], },
      { name: "green", value: [  0, 255,   0, 255], },
      { name: "blue",  value: [  0,   0, 255, 255], }
    ];

    var infos = [
      { name: "red", value: [255, 0, 0, 255], },
      { name: "green", value: [ 0, 255, 0, 255], },
      { name: "blue", value: [ 0, 0, 255, 255], }
    ];

instead i do something like this. (incorrect trailing commas removed from the previous example)

  var infos = [
    {
      name: "red",
      value: [255, 0, 0, 255]
    },
    {
      name: "green",
      value: [0, 255, 0, 255]
    },
    {
      name: "blue",
      value: [0, 0, 255, 255]
    }
  ];

    M_CAT02 = new Matrix3([
         .7328,  .4296, -.1624,
        -.7036, 1.6975,  .0061,
         .0030,  .0136,  .9834])
    M_HPE = new Matrix3([
         .38971,  .68898, -.07868,
        -.22981, 1.18340,  .04641,
         .00000,  .00000, 1.00000])

To be clear, I don't follow the Google Style Guide exactly, at least not for my open source projects. It's more of a jumping-off point that I then tweak to my liking. As I said in the article, it's not worth going into every detail of my style preferences (like spacing and naming), as I find that stuff pretty trivial.

If a style guide is making code less readable, I would argue that the style guide needs to be amended.

Agreed. 80 columns made a lot more sense in the FORTRAN days where variable names couldn't be more than 6 characters. Even in this article's example code, after doing the "right" thing of creating intermediate variables (debatable, as discussed in other comments), he still has to break the function call which harms rather than helps readability.

    maxComb = maxFrag + maxUniform;

It's not a problem if you're doing something sensible like extracting nested function calls, but inserting newlines into simple statements will make tools like `git blame` a lot less useful.

combined = fragment + original