51–60 of 99 posts
Why would you work "almost exclusively" in a language you don't like? There are plenty of opportunities on software with all sorts of languages.
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 +…
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.
> I don’t like JavaScript. I write an enormous amount of JavaScript — in fact I write it almost exclusively — but I don’t really like it as a language. Why would you work "almost exclusively" in a language you don't like? There are plenty of opportunities on software with all sorts of languages.
I can't wait for the day that CoffeeScript has a robust debugger.
It has nothing to do with history. Horizontal scrolling is a usability nightmare, and in programming, word-wrapping introduces ambiguities.
Code should be designed to be read. You should be able to set your editor to the width defined by your project standards, and know that the code will always look the same to everyone. Clear coding is an art, and makes use of well-chosen indentation and linebreaks. Having different people use different widths in a single project destroys that art and legibility.
Now, why 80 characters? Here's my personal reason. According to "The Elements of Typographic Style", by Robert Bringhurst:
> "The 66-character line is widely considered ideal."
Assume that you'll often have 8 spaces of indent on the left side, and the a ragged right edge of perhaps 6 characters, and you get 66 + 8 + 6 = 80. There's nothing perfect about it, but an 80-character width is basically what's generally comfortable for comprehension by the human eye.
The google javascript style is overly verbose and really awkward. Javascript isn't a typed object-oriented language. If you fight javascript until it looks like C++, you make an awful mess. Most of the javascript I've read from google is overly verbose, takes ages to compile(!!) and it avoids javascript's best features - anonymous functions (closures), object literals and dynamic typing. If the author writes his java…
It's a matter of practicality. JavaScript can do some really cool things, but if it makes the code harder to read/follow/maintain, it's not very useful. From what I've seen, a lot of the JavaScript techniques that have gained popularity over that last couple years make code less grokkable for a project newcomer.
My goal is to write code that anyone can understand. I get much more enjoyment out of that than writing JavaScript "the JavaScript way."
Those are all fairly standard practices (except for the compile step which brings portability issues). I got the impression that the author has some underlying reason for this post that went unexplained. If the lack of default parameters and style consistency are your main peeves with Javascript, it's faring quite well :) Ironically, those are problems that CoffeeScript solves, yet it seems this guy would be the last…
I'll get into CoffeeScript when I feel that it solves more problems than it creates (it's very important for me to be able to debug raw source code in a language). My goal as a programmer is to reduce complexity, and I think it will take about 10 years for CoffeeScript to let me do that.
EDIT: Forget to mention, there's nothing in particular that caused me to write this. I just realized that, more and more, my style goes against what a lot of people do. I figured I'd document it for anyone interested in it. :)
> I don’t like JavaScript. I write an enormous amount of JavaScript — in fact I write it almost exclusively — but I don’t really like it as a language. Why would you work "almost exclusively" in a language you don't like? There are plenty of opportunities on software with all sorts of languages.
Because I want make UIs and apps with open web standards, and JavaScript is the only practical language. CoffeeScript and other macro languages are cool, but currently there is no way to debug and step through the source. I can't wait for the day that CoffeeScript has a robust debugger.
Earlier quoted context omitted.
> 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 indent…
>> 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…
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]
}
];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 +…
> 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 indent…
The use of intermediate variables is something I'm conflicted about. On the one hand, they can make code easier to reason about. Also, when using a crappy debugger that doesn't display return values you can more easily see what's going on. In some cases they make code that at least looks like it ought to run faster. On the other hand, ditching intermediate variables makes refactoring more straightforward. You can imm…
That helps in particular when you are calling several generic functions in a row. Names of local variables can contain a bit more of the terminology of the problem at hand.