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

Line length in programming

ck.kennt-wayne.de

Post reply on HN
Print view View original

61–70 of 74 posts

Re: Line length in programming

#61

Post by collyw »

keithgabryelski wrote: post #50

I disagree with the author that the programmer can't interpret longer than 80 lines. we don't read programs like a 6 year old sounds out words. We read more like a 10 year old (and above) by sighting tokens. Simply put: the world is different than it was in the 70s and 80s and 90s (all decades I have programmed in). 1) screen width is generally wider 2) screen widths are generally exandable 3) identifiers are general…

That's a far more sensible response than the OCD like attitudes of some commenter’s here.

Re: Line length in programming

#62

Post by collyw »

weland wrote: post #48
randallsquared wrote: post #38

Earlier quoted context omitted.

"Something is very bloody, terribly wrong in your code if you consistently find you need to write 150-character lines." Not necessarily. Most lines are below 80 characters, but there are good reasons (for readability!) to use longer lines from time to time: vertical space is more precious than horizontal on modern screens, and the more content I can fit into each vertical page, the faster I'll understand what I'm loo…

> Now, I don't actually use the code folding feature in practice, mainly because I find that the times I would want to use it are times when I nearly always want to fold the code, and in a case like that, it's nice to be able to "pre-fold" it by putting it all on one line. IMO that's just compensating for the inadequacy of tools by making code harder to follow. Usefulness of code folding (and what it says about the c…

> IMO that's just compensating for the inadequacy of tools by making code harder to follow.

Thats pretty much how I would describe the 80 character rule for old terminals. I find the occasional long lines can make things more readable. It certainly helps in locating the bit of code you are looking for when you can recognise it's shape.

Re: Line length in programming

#64

Post by collyw »

logicallee wrote: post #31

Most languages allow you to be quite concise. The best argument for 80 characters might be that it keeps you that way. A similar thing would happen if technical writing and scientific reports kept the average sentence to 12-15 word sentence averages and tried not to go over 25. Reading comprehension goes up: http://www.onlinegrammar.com.au/how-many-words-are-too-many-... It's very similar. Breaking one long sentence…

I just had a quick look at that grammar article. I imagine when people are describing something technical / scientific / difficult to comprehend, it will take more words.

Re: Line length in programming

#65

Post by yeukhon »

collyw wrote: post #57
aleem wrote: post #47

Earlier quoted context omitted.

Touche. Multiple monitors and more screen real estate has been proven to increase productivity. It's an easy win. If the lines come out too long too often, it may be a symptom of other problems. if ((browser.OS == 'win') && (browser.userAgent == 'IE')) { is often better written as: isIE = (browser.userAgent == 'IE'); isWindows = (browser.OS == 'win'); if (isIE && isWindows) { It's self-documenting and reads like natu…

Its more code, more variables. I sometimes do this with complex conditions, but for your example I find it counterproductive.

Well if this is deep deep down in a nested loop, then either you increase char or you wrap that code into multiple statements. It would be counterproductive if this is first or second level.

However, I think I missed one important point. If you are writing for Linux kernel, then 80 chars is definitely not enough since 8 spaces = 1 tab in kernel code. That is, if you have a deep branching, then after 2-3 levels 80 chars wouldn't be enough. But increasing to 100 is only going to help for an extra level.

So the important point missing is the char limit is often project coding style dependent.

Re: Line length in programming

#66

Post by sparkie »

mooism2 wrote: post #16
nkuttler wrote: post #10

I'm glad we talk about this. Once we have solved this question we can move on to really important stuff, like tabs vs spaces.

Code is read far more than it is written. Therefore code legibility is important. Line length affects code legibility. Therefore line length is important.

Code can be read in more ways than one. More often than not you aren't interested in all the minor details in a single statement, but you're interested in the larger structure of some code unit (say, a function), and having dozens of wraps in a function hinders the ability to scan through the code vertically. Therefore, line length is unimportant.

Re: Line length in programming

#67

Post by masklinn »

shadowmint wrote: post #56
masklinn wrote: post #46

Earlier quoted context omitted.

> Really? Yes, really. > Woops. 2 characters over. Do we really need a line break there? You do what you want. > I don't think 'you can just refactor that to be shorter' is really a solution in all circumstances. You don't think the solution I didn't advocate as a cure-all in the first place is a cure-all? Am I supposed to be surprised at this finding?

Well, you specifically said that if someone had gone beyond the 80 character limit, its probably because they needed to rewrite / reword / subfunctionize something. If you've never had a problem with it, dare I ask, how are you qualified to make that call, given you've never had to face that challenge? Anyway, that example is straight from the sqlalchemy examples, which is arguably (other than the extremely wordy Zop…

> Well, you specifically said that if someone had gone beyond the 80 character limit, its probably because

Yes. The operative word here is "probably". Meaning not always.

> If you've never had a problem with it, dare I ask, how are you qualified to make that call, given you've never had to face that challenge?

And here we can see an other important word of the original comment: "much" as in "much of an issue". As in, I've faced it, I've never found it very difficult a challenge to go against. Now of course if you pile on additional constraints for personal reasons…

> I personally think strict adherence to line length limits reduces code quality; you've got to use common sense for it.

I have no issue with that, but common sense being a super-power[0][1] and thus generally uncommon. Thus in my experience erring on the side of respecting line length limits and having to defend an exception to the rule produces significantly better results, and avoids 200+ characters lines because "well it fits in my widescreen 24" display so I don't see what the problem is"

[0] http://walls4joy.com/walls/people/deadpool-wade-wilson-commo...

[1] and was likely named by people who had none

Re: Line length in programming

#68

Post by Nursie »

jeremyjh wrote: post #30
Nursie wrote: post #5

80 is too few. The old reason for it (what if you get stuck doing an emergency bugfix using vi on an 80 char display?!?) no longer holds. It's not massively too few, and most lines never get close to the limit anyway, but the odd line of 100-120 thrown in really isn't a problem on a modern display.

You don't use a split screen in your editor?

Split how?

I usually work with a file list/project navigator/something to the left and a build window at the bottom of the screen. I usually have two screens so that docs/browsers/whatever can live on the second screen. Seems to work for me.

In my current project I'm using eclipse which has a right-hand panel for build targets. Even with both left and right hand panels there's still enough space in the source window for 130 character lines.

Don't get me wrong, I think most lines should be short and that you should endeavour to keep them a reasonable, readable length. I just disagree with 80 as a hard limit.

Re: Line length in programming

#69

Post by Nursie »

NateDad wrote: post #37
Nursie wrote: post #5

80 is too few. The old reason for it (what if you get stuck doing an emergency bugfix using vi on an 80 char display?!?) no longer holds. It's not massively too few, and most lines never get close to the limit anyway, but the odd line of 100-120 thrown in really isn't a problem on a modern display.

That is a straw man. No one actually thinks 80 character displays are the reason to use 80 characters. I think 80-100 is fine. More than 100 and you probably need to refactor the line some, because you probably have too much logic on a single line (or you need to choose names that aren't hugely long).

>> No one actually thinks 80 character displays are the reason to use 80 characters.

Err, yeah they do, I have been given exactly that reason on a few occasions, generally by older engineers who had experience with old-school machines that had precisely those screen dimensions. I don't disagree with your main point, but it's really not a straw man.

Re: Line length in programming

#70

Post by logicallee »

collyw wrote: post #64
logicallee wrote: post #31

Most languages allow you to be quite concise. The best argument for 80 characters might be that it keeps you that way. A similar thing would happen if technical writing and scientific reports kept the average sentence to 12-15 word sentence averages and tried not to go over 25. Reading comprehension goes up: http://www.onlinegrammar.com.au/how-many-words-are-too-many-... It's very similar. Breaking one long sentence…

I just had a quick look at that grammar article. I imagine when people are describing something technical / scientific / difficult to comprehend, it will take more words.

And what is more technical than code?

It's literally logic that will be followed extremely, anally literally. No scientific language gets close to being that literal - normally, you are always going to keep the author's view/point in mind as you read. If you were to accidentally remove a random "not" from scientific writing (as happens), we can usually realize what the author meant. (With rare exceptions, if we are particularly unfamiliar with the topic.)

With code, on the other hand, code doesn't have a "point of view". It will just do whatever you wrote, completely literally. The shorter the expressions, lines, etc, the better.

Post reply on HN