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

91–99 of 99 posts

Re: Treating JavaScript like a 30 year old language

#91

Post by mhd »

icebraining wrote: post #84
mhd wrote: post #40

Earlier quoted context omitted.

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

I don't know; I think it's fairly easy to hit that limit with some constructs like list comprehensions, particularly if they're inside a method (which cuts 12 characters with indention), yet remain readable. Something like: [person.name for person in people if person.country_of_origin == 'Netherlands' and person.age > 30] That's well above the limit, yet I still find it more readable than either a for loop that appen…

A longer/complicated list comprehension looks pretty similar to a (simple) SQL statement. And in both cases, there's really no reason why you couldn't put it on multiple lines, and they usually offer pretty good places to insert line breaks (e.g. "if" and "and" in your example).

Re: Treating JavaScript like a 30 year old language

#92

Post by icebraining »

mhd wrote: post #91
icebraining wrote: post #84

Earlier quoted context omitted.

I don't know; I think it's fairly easy to hit that limit with some constructs like list comprehensions, particularly if they're inside a method (which cuts 12 characters with indention), yet remain readable. Something like: [person.name for person in people if person.country_of_origin == 'Netherlands' and person.age > 30] That's well above the limit, yet I still find it more readable than either a for loop that appen…

A longer/complicated list comprehension looks pretty similar to a (simple) SQL statement. And in both cases, there's really no reason why you couldn't put it on multiple lines, and they usually offer pretty good places to insert line breaks (e.g. "if" and "and" in your example).

But does it really improve readability? Personally, I don't think it does - in neither case; unless it's really pathological, but then it shouldn't all be forced into a single list comprehension.

Re: Treating JavaScript like a 30 year old language

#93

Post by mhd »

icebraining wrote: post #92
mhd wrote: post #91

Earlier quoted context omitted.

A longer/complicated list comprehension looks pretty similar to a (simple) SQL statement. And in both cases, there's really no reason why you couldn't put it on multiple lines, and they usually offer pretty good places to insert line breaks (e.g. "if" and "and" in your example).

But does it really improve readability? Personally, I don't think it does - in neither case; unless it's really pathological, but then it shouldn't all be forced into a single list comprehension.

Well, it certainly doesn't help readability if parts of a line are cut off or the editor has to do an ugly linewrap, spoiling indentation. So as long as it doesn't significantly decrease readability for those corner cases and the benefits outweigh the drawbacks, I'm all for certain code conventions.

Re: Treating JavaScript like a 30 year old language

#94

Post by Roboprog »

Roboprog wrote: post #35
ThePherocity wrote: post #22

Earlier quoted context omitted.

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…

Me. When I bring up the Netbeans editor, there is a red line down the right margin at column 80, and I'm not inclined to change that setting, although I sometimes type a few characters past it. This is a wise tradition, handed down from the tribal elders :-) I sometimes need to see at least a little bit of something else on screen besides your hideously wide code. If you ever have to print out code, it makes a nice l…

Almost forgot: if you need more than 80 columns, your routine is probably too long. Indicated by deep nesting, and/or variable names that need to be more than one or two English words because the scope and intent of the variables is not obvious.

Re: Treating JavaScript like a 30 year old language

#95

Post by petercooper »

AjJi wrote: post #8

AFAIK, using 'new' is not a matter of preference. Omitting the keyword leads to different results. Am I missing something?

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

Re: Treating JavaScript like a 30 year old language

#96

Post by ThePherocity »

Roboprog wrote: post #94
Roboprog wrote: post #35

Earlier quoted context omitted.

Me. When I bring up the Netbeans editor, there is a red line down the right margin at column 80, and I'm not inclined to change that setting, although I sometimes type a few characters past it. This is a wise tradition, handed down from the tribal elders :-) I sometimes need to see at least a little bit of something else on screen besides your hideously wide code. If you ever have to print out code, it makes a nice l…

Almost forgot: if you need more than 80 columns, your routine is probably too long. Indicated by deep nesting, and/or variable names that need to be more than one or two English words because the scope and intent of the variables is not obvious.

You don't write in Objective-C for an Apple then, eh?

Re: Treating JavaScript like a 30 year old language

#97

Post by Roboprog »

ThePherocity wrote: post #96
Roboprog wrote: post #94

Earlier quoted context omitted.

Almost forgot: if you need more than 80 columns, your routine is probably too long. Indicated by deep nesting, and/or variable names that need to be more than one or two English words because the scope and intent of the variables is not obvious.

You don't write in Objective-C for an Apple then, eh?

Not much, no. (for a few weeks, 2 years ago, so literally, some, but not bloody much)

Can the args to messages not be put on a continuation line?

Re: Treating JavaScript like a 30 year old language

#98

Post by ThePherocity »

Roboprog wrote: post #97
ThePherocity wrote: post #96

Earlier quoted context omitted.

You don't write in Objective-C for an Apple then, eh?

Not much, no. (for a few weeks, 2 years ago, so literally, some, but not bloody much) Can the args to messages not be put on a continuation line?

Yea, they can, but some of the names are overly verbose.
Post reply on HN