Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I use the Google style guide as well since it's required by my job and while I have learned somethings from it I'm not a fan.

80 characters? I never had that limit for the 27 years of programming proceeding using the Google style guide and it never caused me any grief. I find that naming things descriptively and an 80 character limit are at odds.

I'd rather read

    maxCombinedUniformVectors = maxFragmentUniformVectors + maxVectorUniformVectors;
than

    maxCombinedUniformVectors = 
        maxFragmentUniformVectors + maxVectorUniformVectors;
or

    maxCombinedUniformVectors = maxFragmentUniformVectors + 
                                maxVectorUniformVectors;
I admit it's kind of useful for side by side diff tools but in my previous 27 years of programming I never felt like "If only this code was 80 characters I could read the diff".

More importantly though, the Google Style guide is written by Java programmers to try to make JavaScript into Java, totally ignoring all the benefits of treating JavaScript like JavaScript. That has it's benefits, especially for Java programmers. They don't have to learn some of the cooler things about JavaScript. They can go on treating it like a traditional oop language. And they get static type checking.

On the other hand, all of these FP concepts are out

http://osteele.com/sources/javascript/functional/ http://www.ibm.com/developerworks/library/wa-javascript/inde... http://osteele.com/archives/2007/07/functional-javascript http://www.cubiclemuses.com/cm/blog/archives/000307.html/

Even common JS concepts like encapsulation

    var ErrorLogger = (function(){
      var privateErrorCount = 0;

      return {
        error: function(msg) {
          console.log(msg);
          ++privateErrorCount;
        },
        getNumErrors: function() {
          return privateErrorCount;
        }
      }
    }());
Are not allowed by the Google Style guide as well as many other JSisms.

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

Allowed

    var kStateRun = 1;        // character is running
    var kStateRunToWalk = 2;  // character is transitioning from run to walk
    var kStateWalk = 3;       // character is walking
Not allowed

    var kStateRun       = 1;  // character is running
    var kStateRunToWalk = 2;  // character is transitioning from run to walk
    var kStateWalk      = 3;  // character is walking
Either lining things up makes them easier to read or it doesn't. Comments are not some exception. If lining up comments makes them easier to read then lining up anything makes it easier to read.


> 80 characters? I never had that limit for the 27 years of programming proceeding using the Google style guide and it never caused me any grief.

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


yeah, I didn't adhere to a column limit until I moved to vim, then I realized as you said that it lets me view code side-by-side


> I find that naming things descriptively and an 80 character limit are at odds.

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.


>> I find that naming things descriptively and an 80 character limit are at odds. > I don't. I use descriptive names for functions and short, concise words for variables (sometimes clear abbreviations)

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], }
    ];
Is vastly easier to read and find errors in IMO than this

    var infos = [
      { name: "red", value: [255, 0, 0, 255], },
      { name: "green", value: [ 0, 255, 0, 255], },
      { name: "blue", value: [ 0, 0, 255, 255], }
    ];
The first is not allowed by the Google Style guide. It requires the 2nd.


i generally avoid putting all properties of an object in one the same line in the name of readability and also to avoid the 80 char limit.

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]
    }
  ];


How’s this then, for another example:

    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])
Without lining those all up, it becomes a real pain in the butt to read the matrix.


Nowhere are abbreviations forbidden by the Google Style Guide.


its not difficult to maintain. Emacs in particular has M-x align-regexp = (which does the alignment for you)


I find that naming things descriptively and an 80 character limit are at odds.

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.


80 cols is to fit on a punched card and has nothing to do with the variable name length limit on old versions of FORTRAN.


Article author here:

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.


On a related note, breaking statements into multiple lines can screw with your VCS workflow immensely.

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.


I'd rather read:

    maxComb = maxFrag + maxUniform;
Or some other shortish variable names.


I find that long variable names are usually a sign of design that needs improvement. For example, those names are highly repetitive and don't actually tell me how each of those variables is different from the other, which is the information I care about right that moment. By putting them into a function or prototype who's name communicates the commonality, say "getAllMax" on UniformVectors it could be just as communicative to say something like:

combined = fragment + original


Same thing in Google's C++ style guide. No FP, C++11, or boost. I find that disappointing.




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

Search: