Treating JavaScript like a 30 year old language

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.

Though some are good suggestions for writing maintainable codes, I do not see a lot of opportunities to improve javascript from this.

The pieces I would like to have are a) optional arguments and b) strict type checking. They are actually syntactic sugar in a way, because you can get the same effect using typeoff function.

But restriction to 80 characters... would be definitely recommended as coding practice, but never be forced by the language!

Me. When I bring up the Netbeans editor, there is a red line down the right margin at column 80, and I'm not inclined to change that setting, although I sometimes type a few characters past it. This is a wise tradition, handed down from the tribal elders :-) I sometimes need to see at least a little bit of something else on screen besides your hideously wide code.

If you ever have to print out code, it makes a nice line size convention as well. Printing is becoming less common, unless you publish books, but it's still worth considering that it might be easier for the reader if the lines aren't mind-numbingly long.

Why do newspapers have multiple columns of text, when clearly they have space to go 14 inches or more across?

You can go one step further and make use of automatic function currying (such as in haskell) and just write:

adder(x,y) -> x + y

If you call adder with one argument, you get the same behaviour as your makeAdder (returned closure), but if you call it with 2 args you get addition.

Which of course begs the question, why were punched cards 80 characters wide? According to a random StackExchange commenter:

"The cards are that size because in 1890, CTR wanted to reuse currency carriers (the dollar was bigger back then) to carry the census data cards. – Al Biglan"[1]

Assuming this is true, and that the size of the card was chosen to match the size of the US dollar, it can perhaps be assumed that 80 columns was chosen as a reasonable compromize between data density and structural integrity. I'm not sure that this makes sense though, since Wikipedia says that IBM's 80-column cards date from 1928. A more authoritative source would be welcome.

[1] http://programmers.stackexchange.com/questions/148677/why-is...