AFAIK, using 'new' is not a matter of preference. Omitting the keyword leads to different results. Am I missing something?
Some people think that library consumers shouldn't have to use new. Instead they should call a factory function (which itself calls new).
Treating JavaScript like a 30 year old language
11–20 of 99 posts
Re: Treating JavaScript like a 30 year old language
#12http://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.
Re: Treating JavaScript like a 30 year old language
#13If 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).
Re: Treating JavaScript like a 30 year old language
#14Excellent attitude. I need to keep reminding myself of this when I come up with them fancy oneliners again.
Re: Treating JavaScript like a 30 year old language
#15I disagree with the point about 80 chars limit. 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 so…
"Shouldn't have to read it" !== "won't ever have to read it."
Re: Treating JavaScript like a 30 year old language
#16For 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...
Re: Treating JavaScript like a 30 year old language
#17Doesn't even mention coffescript
Re: Treating JavaScript like a 30 year old language
#18I disagree with the point about 80 chars limit. 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 so…
Why make me scroll horizontally?
Re: Treating JavaScript like a 30 year old language
#19Re: Treating JavaScript like a 30 year old language
#20I disagree with the point about 80 chars limit. 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 so…