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 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
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.
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 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.
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 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:
"At some point in computer history, somebody (arbitrarily?) created an 80 character line limit for code. ... I’ve been writing JavaScript for three-ish years"
For a couple decades, and not ending until the late 90s, most text terminals and text modes for graphics cards were 80 characters wide[1], and dot matrix printers also had an 80 character line length (plus margins) dating back to 80 characters per line punch cards from 1928[2]. If a line was longer, you had to scroll that individual line. To let your code be read easily anywhere including your own screen, you stuck to that line length.
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.
Note that typographical measures are usually even smaller, with 66 characters per line being quite common. And those don't use monospaced fonts and are thus even more narrow, and thus easier to scan. Granted, they usually don't include spurious whitespace, but if 40 characters out of your 80 are empty, you've probably got a different problem altogether.
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 javascript as if it were C++, its really no wonder he hates the language. Javascript is a wonderful little language - but its not C, and if you pretend it is, you're going to have a miserable time.
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."
I'm a huge fan of an 80-character limit. But more importantly, of having a rigorously-defined limit.
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 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 immediately see the complete set of dependencies of a line of code and extract common bits of code into helper methods with less hassle.
In general I think I prefer the "cram a bunch of nested functions into one line" approach, but then that might be language-dependent (I mostly do Objective-C these days, and Xcode has a pretty smart automatic line-wrapping feature).
Lisp would be an extreme example where that's pretty much all you do.
An advantage of using intermediate variables is that they provide for a way to add comments without adding comments, in the form of the name of the intermediate result.
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.
> I would contend that readability generally has more impact on the success of a project than micro-optimizations and stylistic experimentation. If that means writing like a C coder in the 80’s, then so be it.
Excellent attitude. I need to keep reminding myself of this when I come up with them fancy oneliners again.
I'm sorry to sound like a fanboy, but this is one of the reasons I love Go: is the most readable language I know.
It is expressive, but free of magic, code says what it does, there is no hidden magic tricks, this annoys people used to other languages with more "features", but to me it is Go's greatest feature.
If the line consists of boilerplate code, I will allow it to go over 120-160 chars most of times. The idea is to just get that code out of sight, as nobody should have to read it anyway. If it's important, I will break the line up. If not - like a long exception message that gets constructed with bunch of context information - I'll let it grow out of window. It's not something you will need to look at, read and grok every day. And I am happy to have it out of sight most of time.
I break up lines when thinking about stepping through them in debugger (though javascript debuggers seem to be able to step statement by statement, not line by line).
We're so different, you and I. "Getting code out of sight because it's ugly" is such a foreign concept. If a code block is that ugly, it either needs to be made not ugly or put directly in the line of sight with plentiful comments.
"Shouldn't have to read it" !== "won't ever have to read it."
I had a manager once who would seriously write 250-500 character lines of VB6. When I see code disappear off the right margin I get very nervous. You can hide a lot of functionality that way, especially if your language supports multiple statements on a single line.
I have worked with a strict 80 character rule, and I find that it usually causes worse looking code with excessive multi-line statements, poor variable naming and makes refactoring more labour intensive.
I have a soft limit of around 100 characters for C++, which is good for readability and still allows me to have two side by side editing windows.
Maybe I'm an exception, but I generally find code with LESS syntax to be more readable.
var makeAdder = function(x) {
return function(y) {
return x + y;
};
}
vs
makeAdder = (x) -> (y) -> x + y
Is anyone else like this? Do you think people are hard-wired to prefer one form of syntax to another, or do you think it's a "whichever you have more experience with" kind of thing?
I think I could get used to the second, but I'm not yet. At a glance, it looks like Erlang or Haskell, but that just shows you how little I know about those languages.
It's tough to strike a balance between brevity and familiarity sometimes.
Totally aside, but interesting: 80 characters was not an arbitrary limit, at least not directly. It was the size of the IBM standard punched card, and the terminals that succeeded them. Famously, versions of COBOL (FORTRAN too?) well into the 1990s would not even recognize input past column 80 even though it had long since graduated to text files.
I still like to use 80 characters even today because it means I can fit two or even three pages of code side-by-side without wrapping. Great for merging.
Especially when a tab isn't 8 spaces worth and you don't have a near useless level of indentation from the start (e.g. Java's "class" scope), I rarely found a problem with 80 (or 78) character limits. Quite the opposite, usually there's something "wrong" with code that exceeds that limit (a "code smell", as the hip kids like to say).
Granted, quite often it's a "language smell", like Java or earlier C++'s verbose initialization forms and class terminology (AbstractFactoryImpl etc.). Other than that, it's often longer formulas or string building exercises, which usually could benefit from some temporary variables or printf-style format languages. If a statemenet has more than one operator and polysyllabic variable names, I generally prefer some variation of "let x be the overlong constant/class/descriptive name", e.g. "int x = DomainBasedStaticConfigurationSingleton.MAXIMUM_FROBNICATION_VALUE", instead of just adding up those monsters themselves. And being German, I'm actually quite used to silly compound nouns.
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 person to try it.
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. :)
Semicolons: it's too bad Netscape didn't choose to use colons instead (but then it wouldn't sorta look like C, would it).
As opposed to common dogma as this is, JavaScript is essentially a line oriented language, like Ruby, Shell Script, BASIC, Groovy or dBASE. OK, so it's more like Ruby, where the line will continue if it doesn't look done.
Had they used colons instead of semicolons, it would have been obvious that "oh, I'm using this punctuation to add another statement to this line", but of course, it's usually the null statement in JavaScript.
It's a shame JavaScript (and Ruby) didn't adopt the line continuation character convention (e.g. - backslash or ampersand) for incomplete lines. As it is, one might be best served by learning what incomplete statements look like, just in case, and alternately, where the parser might think your statement is shorter than you intended.
Yes, I add the semicolons at work to avoid the <<trivial criteria>> contest.
In Ruby, once you reach the end of a line, it is unambiguous whether the line is complete. You don't need to scan the next line to figure it out.
Ruby does support a line continuation character if the line is complete, but you want to continue it anyway.
foo = Struct.new(:bar).new("HI")
puts foo \
.bar
So in Ruby, the rule is: if you get to the end of a line and the expression is complete, the expression is finished. Otherwise, continue on the next line.
This is really nice for human-readability (and as a side effect, pasting code into IRB).
It does but there are other ways to create objects (even using prototypal inheritance) in JavaScript that are pretty popular in the wild (Object.create and object literals with {} for example). The code behind this and the constructors, etc, would need to be rather different though (that is, you're right, you can't just drop new and expect it to work as-is.)
If you are writing types in Javascript, you owe it to yourself to use webstorm, as it can do code completion in javascript (it can also do reasonable inference).
The (crazy but awesome) "unicode literals" feature in Python 3 means that your example is actually a valid statement:
Python 3.2.3 (default, May 3 2012, 15:51:42)
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 放改型(势, 做改值(这._改订购, _.挑(态, 改函数名)))
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
NameError: name '放改型' is not defined
Of course I didn't actually define a function named 放改型...
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!
I'm pleased that someone else favours a sensible line limit.
I stick to 72 columns for width and 20 lines per function body. The result has been very concise code that's easy to follow. Only exceptional cases such as heavy recursion have eluded the line limit.
If popular JavaScript projects wrote code with cleanliness in mind, maybe more people would take the language seriously.
I have always felt that scripting languages should stay clear of OO syntax largely. Try to do small files which are procedural. OO is for large monolithic modules - good to collabarate and manage complexity - scripting should stay where it needs to be - simple and standalone, no threading, but asynchronous where possible. This makes life easier for everybody.
> 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.
[+] [-] greggman|13 years ago|reply
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
than or 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
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
Not allowed 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.[+] [-] wickedchicken|13 years ago|reply
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
[+] [-] mkmcdonald|13 years ago|reply
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.
[+] [-] jerbils|13 years ago|reply
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.
[+] [-] orangecat|13 years ago|reply
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.
[+] [-] cabalamat|13 years ago|reply
[+] [-] nfm|13 years ago|reply
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.
[+] [-] roguecoder|13 years ago|reply
combined = fragment + original
[+] [-] maybird|13 years ago|reply
[+] [-] unknown|13 years ago|reply
[deleted]
[+] [-] Terretta|13 years ago|reply
For a couple decades, and not ending until the late 90s, most text terminals and text modes for graphics cards were 80 characters wide[1], and dot matrix printers also had an 80 character line length (plus margins) dating back to 80 characters per line punch cards from 1928[2]. If a line was longer, you had to scroll that individual line. To let your code be read easily anywhere including your own screen, you stuck to that line length.
1. http://en.wikipedia.org/wiki/Text_mode#PC_common_text_modes
2. http://en.wikipedia.org/wiki/Punched_card#IBM_80-column_punc...
[+] [-] kibwen|13 years ago|reply
"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...
[+] [-] mhd|13 years ago|reply
[+] [-] josephg|13 years ago|reply
If the author writes his javascript as if it were C++, its really no wonder he hates the language. Javascript is a wonderful little language - but its not C, and if you pretend it is, you're going to have a miserable time.
[+] [-] jerbils|13 years ago|reply
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."
[+] [-] crazygringo|13 years ago|reply
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.
[+] [-] cabalamat|13 years ago|reply
[+] [-] frankus|13 years ago|reply
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 immediately see the complete set of dependencies of a line of code and extract common bits of code into helper methods with less hassle.
In general I think I prefer the "cram a bunch of nested functions into one line" approach, but then that might be language-dependent (I mostly do Objective-C these days, and Xcode has a pretty smart automatic line-wrapping feature).
Lisp would be an extreme example where that's pretty much all you do.
[+] [-] Someone|13 years ago|reply
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.
[+] [-] skrebbel|13 years ago|reply
Excellent attitude. I need to keep reminding myself of this when I come up with them fancy oneliners again.
[+] [-] luriel|13 years ago|reply
It is expressive, but free of magic, code says what it does, there is no hidden magic tricks, this annoys people used to other languages with more "features", but to me it is Go's greatest feature.
[+] [-] watt|13 years ago|reply
If the line consists of boilerplate code, I will allow it to go over 120-160 chars most of times. The idea is to just get that code out of sight, as nobody should have to read it anyway. If it's important, I will break the line up. If not - like a long exception message that gets constructed with bunch of context information - I'll let it grow out of window. It's not something you will need to look at, read and grok every day. And I am happy to have it out of sight most of time.
I break up lines when thinking about stepping through them in debugger (though javascript debuggers seem to be able to step statement by statement, not line by line).
[+] [-] mattdeboard|13 years ago|reply
"Shouldn't have to read it" !== "won't ever have to read it."
[+] [-] muriithi|13 years ago|reply
Why make me scroll horizontally?
[+] [-] techdmn|13 years ago|reply
[+] [-] correctifier|13 years ago|reply
I have a soft limit of around 100 characters for C++, which is good for readability and still allows me to have two side by side editing windows.
[+] [-] Xcelerate|13 years ago|reply
[+] [-] Roboprog|13 years ago|reply
It's tough to strike a balance between brevity and familiarity sometimes.
[+] [-] emef|13 years ago|reply
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.
[+] [-] kemiller|13 years ago|reply
http://en.wikipedia.org/wiki/Punched_card
I still like to use 80 characters even today because it means I can fit two or even three pages of code side-by-side without wrapping. Great for merging.
[+] [-] mhd|13 years ago|reply
Granted, quite often it's a "language smell", like Java or earlier C++'s verbose initialization forms and class terminology (AbstractFactoryImpl etc.). Other than that, it's often longer formulas or string building exercises, which usually could benefit from some temporary variables or printf-style format languages. If a statemenet has more than one operator and polysyllabic variable names, I generally prefer some variation of "let x be the overlong constant/class/descriptive name", e.g. "int x = DomainBasedStaticConfigurationSingleton.MAXIMUM_FROBNICATION_VALUE", instead of just adding up those monsters themselves. And being German, I'm actually quite used to silly compound nouns.
[+] [-] ricardobeat|13 years ago|reply
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 person to try it.
[+] [-] jerbils|13 years ago|reply
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. :)
[+] [-] samspot|13 years ago|reply
[+] [-] Roboprog|13 years ago|reply
As opposed to common dogma as this is, JavaScript is essentially a line oriented language, like Ruby, Shell Script, BASIC, Groovy or dBASE. OK, so it's more like Ruby, where the line will continue if it doesn't look done.
Had they used colons instead of semicolons, it would have been obvious that "oh, I'm using this punctuation to add another statement to this line", but of course, it's usually the null statement in JavaScript.
It's a shame JavaScript (and Ruby) didn't adopt the line continuation character convention (e.g. - backslash or ampersand) for incomplete lines. As it is, one might be best served by learning what incomplete statements look like, just in case, and alternately, where the parser might think your statement is shorter than you intended.
Yes, I add the semicolons at work to avoid the <<trivial criteria>> contest.
[+] [-] wycats|13 years ago|reply
In Ruby, once you reach the end of a line, it is unambiguous whether the line is complete. You don't need to scan the next line to figure it out.
Ruby does support a line continuation character if the line is complete, but you want to continue it anyway.
So in Ruby, the rule is: if you get to the end of a line and the expression is complete, the expression is finished. Otherwise, continue on the next line.This is really nice for human-readability (and as a side effect, pasting code into IRB).
[+] [-] AjJi|13 years ago|reply
[+] [-] MatthewPhillips|13 years ago|reply
[+] [-] petercooper|13 years ago|reply
[+] [-] shawndumas|13 years ago|reply
[+] [-] tomjen3|13 years ago|reply
[+] [-] vorg|13 years ago|reply
There's other ways fit your first example within 80 chars:
How about?...[+] [-] kiwidrew|13 years ago|reply
[+] [-] altrego99|13 years ago|reply
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!
[+] [-] mkmcdonald|13 years ago|reply
I stick to 72 columns for width and 20 lines per function body. The result has been very concise code that's easy to follow. Only exceptional cases such as heavy recursion have eluded the line limit.
If popular JavaScript projects wrote code with cleanliness in mind, maybe more people would take the language seriously.
[+] [-] rbanffy|13 years ago|reply
Isn't 72 columns a little bit restrictive?
[+] [-] anuraj|13 years ago|reply
[+] [-] azakai|13 years ago|reply
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.
[+] [-] jerbils|13 years ago|reply
I can't wait for the day that CoffeeScript has a robust debugger.