Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Treating JavaScript like a 30 year old language

jeremyckahn.github.com

Post reply on HN
Print view View original

41–50 of 99 posts

Re: Treating JavaScript like a 30 year old language

#41

Post by mhd »

Terretta wrote: post #16

"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 ca…

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.

Re: Treating JavaScript like a 30 year old language

#42

Post by mattdeboard »

ThePherocity wrote: post #22
mattdeboard wrote: post #15

Earlier quoted context omitted.

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 agree completely with this, all code should be visible, but I still go well over 80 personally because I'm don't, nor will anyone likely edit my code on a 80 char terminal. When I was hacking on an IBM mainframe through a 3270 terminal, the 80 character limit made a lot of sense. Why use the 80 char rule because of an edge case of some throwback editing javascript in a term that only allows for 80 characters? I mea…

I mean even reviewing code on Github... if you go over 80 (or close to it, not sure the exact column count) it forces scroll.

I dunno, it's just convention. I break at 80 cols.

Re: Treating JavaScript like a 30 year old language

#43

Post by wycats »

Roboprog wrote: post #27

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…

Ruby and JavaScript are a bit different.

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).

Re: Treating JavaScript like a 30 year old language

#44

Post by orangecat »

greggman wrote: post #31

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.

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.

Re: Treating JavaScript like a 30 year old language

#45

Post by mkmcdonald »

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.

Re: Treating JavaScript like a 30 year old language

#46

Post by ricardobeat »

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.

Re: Treating JavaScript like a 30 year old language

#47

Post by mkmcdonald »

greggman wrote: post #31

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 indentation]

Code Complete 2 explicitly discourages the latter style, and I tend to agree. It's too difficult to maintain.

Re: Treating JavaScript like a 30 year old language

#48

Post by maybird »

greggman wrote: post #31

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 +…

Same thing in Google's C++ style guide. No FP, C++11, or boost. I find that disappointing.

Re: Treating JavaScript like a 30 year old language

#49

Post by greggman »

mkmcdonald wrote: post #47
greggman wrote: post #31

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…

>> 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.

Re: Treating JavaScript like a 30 year old language

#50

Post by tikhonj »

Roboprog wrote: post #29
Xcelerate wrote: post #21

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.

In Haskell you could actually just do

    adder = (+)
because operators are just normal functions which happen to be infix by default. I think this is great--it's consistent, flexible and elegant at the same time. Not treating operators as something special makes the language simpler.
Post reply on HN