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

21–30 of 74 posts

Re: Line length in programming

#21

Post by viraptor »

adamtulinius wrote: post #2

And obviously practicality can get in the way. 80 character lines will be a nightmare in a java-project with verbose naming schemes (FactoryFactoryObjectThingymybobProducer thingy = new FactoryFactoryObjectThingymybobProducer(..);).

Or python if you're already in a function in a function in a class (so 68 chars left). If you also standardised on importing modules, not classes things can get silly. My favourite counter-example to the 80 char limit was a line in openstack which was:

    return some_loaded_module.fairly_descriptive_but_necessarily_long_name(not_very_long_argument)
The way applied to fit it without forced line breaking?

    fdbnln = some_loaded_module.fairly_descriptive_but_necessarily_long_name
    return fdbnln(not_very_long_argument)
(yes, actually using first letters of words) Because yeah... that makes things simpler than just crossing the limit in that place.

Re: Line length in programming

#22

Post by RyanZAG »

chrisbridgett wrote: post #15
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.

I thought the historical reason was that punch-cards had 80 characters per line. ...just Googled it: http://programmers.stackexchange.com/questions/148677/why-is...

That's interesting. Even more so in that the 80 characters per line for punch-cards is because that's the size a dollar bill was back then, because punch cards were created for use in the 1890 census. http://www.columbia.edu/cu/computinghistory/census-tabulator...

It's like the railway gauge size being standardized by the ancient romans. The best part of all of this though is the other comments on this page - many of them seem to imply that 80 width was chosen because of how well it fits onto your computer screen and that 100 must be too wide. If the dollar bill in 1890 had been a bit wider, they'd likely be arguing now how 80 is too small!

It proves the point that it's important to actually understand why certain things are chosen and not just assume they're always the best. Going with the standard method is not always the most beneficial path.

Re: Line length in programming

#23

Post by acqq »

adamtulinius wrote: post #2

And obviously practicality can get in the way. 80 character lines will be a nightmare in a java-project with verbose naming schemes (FactoryFactoryObjectThingymybobProducer thingy = new FactoryFactoryObjectThingymybobProducer(..);).

Is Java still lacking constructs like

     var thingy = FactoryFactoryObjectThingymybobProducer
The compiler actually knows what type is on the right of the = sign. Having to write FactoryFactoryObjectThingymybobProducer is not good for anything.

Re: Line length in programming

#24

Post by mrottenkolber »

I found 72 character wide lines to be optimal (writing CL). Note that I also apply the rule of choosing long descriptive symbol names. E.g. MAKE-RESOURCE-RESPONDER etc...

When I have trouble keeping the lines short I consider: 1) Is there a better way to write this? 2) Is this function too big?

There are cases where lines have to be longer, but not in Lisp. Inability to write short lines is a symptom of bad syntax designs like e.g. C et al.

EDIT: I have been writing JS the last months and keeping lines short is especially hard in JS, because of its abomination of a syntax. UNIX style backslash escaped line breaks don't help either.

Re: Line length in programming

#25

Post by Cthulhu_ »

dbaupp wrote: post #20
yeukhon wrote: post #11

Here is what I've said about 80 char in the past. "If the argument for expanding to 100 or more is that screen is getting wider, then the benefit of wide screen is the ability to fit multiple terminals in one window. For normal workflow, I'd split my windows into two or terminals, depending on what I am doing, so I don't see any benefit in increasing the limit."

I quite like 100 chars: it's perfect for two side-by-side windows on my screen. (i.e. two adjacent emacs buffers are about 101 chars wide each.)

I have 80, but then, I like my font size a few points bigger.

Re: Line length in programming

#26

Post by masklinn »

matthewmacleod wrote: post #7

80 chars is a useful rule of thumb, so long as it's tempered by practicality. I've worked on projects where the limit was taken far too literally, which results in code that's harder to read. This is especially true if you're using something verbose (Java, Objective-C) or whitespace-sensitive (Python).

I've never had much issue keeping Python code under 80 columns. Going beyond usually means you've used way too many nested clause and should either rewrite the whole thing or extract part of its to subroutines.

Re: Line length in programming

#27

Post by dkersten »

yeukhon wrote: post #11

Here is what I've said about 80 char in the past. "If the argument for expanding to 100 or more is that screen is getting wider, then the benefit of wide screen is the ability to fit multiple terminals in one window. For normal workflow, I'd split my windows into two or terminals, depending on what I am doing, so I don't see any benefit in increasing the limit."

I used to think that 80 (or even 100) characters was too short, but I've changed my mind for two reasons:

1. Like you said, splitting windows. I now use a tiled window manager and also I use vim splits a LOT. If I can fit two windows side by side, good - if I can fit three, great!

2. I find that when my lines go over 80/100ish characters they are very hard to read anyway (too much eye travel between lines) and its usually (though admittedly not always) a sign that my code is too nested or otherwise could be simplified.

So now I happily use 80 character lines (When using Python I strictly follow the vim PEP8 checker, for example). I actually kinda prefer 80 to 100 now because I use slightly above average font sizes (I don't have the best eyesight) and this way I can still comfortably fit two editors side by side.

Re: Line length in programming

#28

Post by scrabble »

I put two guidelines in my editor. One at 80 chars and one at 100. I treat 80 like a goal and 100 as a hard limit. If I go over 100, I'll put the break around 80.

Not only do I find the code easier to look at, but I find I write better code and I'm less likely to violate the Liskov substitution principle.

Re: Line length in programming

#29

Post by dkersten »

masklinn wrote: post #26
matthewmacleod wrote: post #7

80 chars is a useful rule of thumb, so long as it's tempered by practicality. I've worked on projects where the limit was taken far too literally, which results in code that's harder to read. This is especially true if you're using something verbose (Java, Objective-C) or whitespace-sensitive (Python).

I've never had much issue keeping Python code under 80 columns. Going beyond usually means you've used way too many nested clause and should either rewrite the whole thing or extract part of its to subroutines.

I agree. I now very religiously follow PEP8. Too much nesting is rarely an issue as the PEP8 checker will complain about complexity anyway. If lines are too long, usually it means that I'm trying to do too much foo.bar(baz.quux().a().b([for a in some_var])) and I should refactor the code anyway. (The SQLAlchemy ORM queries are the most common place where I go over 80 characters - everywhere else I don't seem to do it often)

Re: Line length in programming

#30

Post by jeremyjh »

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?
Post reply on HN