4 ms·
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 l
by greggman 14y ago
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://osteele.com/sources/javascript/functional/
http://www.ibm.com/developerworks/library/wa-javascript/index.html http://www.ibm.com/developerworks/library/wa-javascript/inde...
http://osteele.com/archives/2007/07/functional-javascript http://osteele.com/archives/2007/07/functional-javascript
http://www.cubiclemuses.com/cm/blog/archives/000307.html/ 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.
- orangecat 14y agoI 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.
- mjwalshe 14y ago80 cols is to fit on a punched card and has nothing to do with the variable name length limit on old versions of FORTRAN.
- mkmcdonald 14y ago> 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.
- greggman 14y ago>> 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.