Live data from Hacker News

Line length in programming

ck.kennt-wayne.de

31–40 of 74 posts

Re: Line length in programming

#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 into two is the same as breaking nested if and loop statement into several lines, the first just assigning a boolean based on the test. Then the if test just tests the boolean. Reading comprehension goes WAY up.

Look at the top response on this question: https://news.ycombinator.com/item?id=7289087 (the one with several short lines.)

100% comprehension.

Re: Line length in programming

#32

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.

Wow, I do the exact same thing. Nice to see someone else doing the same.

Re: Line length in programming

#33
post #23

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.

Usually this is not what you want to separate interfaces from implementations. For example, this:

    List l = new ArrayList();
is preferred to this:

    ArrayList l = new ArrayList();
Of course, it would be nice for the compiler to assume the latter if no type is specified on the left side.

Re: Line length in programming

#34
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?

'modern display' is mentioned so I'd guess that's 1900 pixels or more. That will likely fit a couple of split screens even at 100 characters?

Re: Line length in programming

#35
The argument about no one editing in a 80 character terminal anymore is a straw man. That's not the real reason 80 characters is good. The article even says why - we're just not good at reading long lines for whatever reason.

There's two modern reasons for smaller liner lengths (80-100) besides cognitive capacity:

Viewing/editing two files side by side on the same screen.

Side by side diffs.

Now, that's not to say that you should contort the code to make lines short. If it makes the code significantly more difficult to read, don't do it... but still try to keep it reasonable. This is also a good reason to keep your variable names relatively short - so you don't hit this situation all the time.

Re: Line length in programming

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

Re: Line length in programming

#38
post #14

I'm surprised and, to some degree, annoyed at the superficiality of some of the arguments in this debate. Like this one: > Readability - You don't have to scroll over horizontally when you want to see the end of some lines. It's not having to scroll horizontally that bothers me with long lines. My monitor is wide enough that it can probably hold 250 characters with ease. It's having to read long lines . Something is…

"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 looking at.

The main reason I like the ability to occasionally have a 150 or 180 character line is akin to code folding, which some editors have as a feature. The feature allows you to hide a function or class by collapsing it into one line, because you want an overview of the code around it or calling it, and for the moment the implementation details aren't relevant. 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.

For example, if not using an ORM, I might want to use SQL to grab some results from a db (in a model, say), and I almost never want to think about my SQL and my surrounding code in the same context. Now, you might say, "Just put that SQL in its own method with a reasonably short name, and call it where you would otherwise have a long SQL string, and in the function that returns it, you can break each line at 70-80 characters," but that seems like a "solution" which improves nothing in my typical reading of the code, and requires me to jump around to find the SQL in the rare case I need to pay attention to it. It breaks up something which is naturally local and specific to this place in the code.

Another example which happens somewhat more frequently for me is when I want to use a literal object in JS. If I want to keep the definition local -- because, perhaps, nothing outside of this function ever needs it -- my choices are to put each key/value pair on its own line (easy to find a given key, but consumes lots of vertical space), to put multiple key/value pairs on each line to fit ~80 characters (both moderately difficult to find a given key, and still eats moderate amounts of vertical space), or to "fold" it all to one line (consumes the minimum vertical space, with the trade-off that it's difficult to find a given key). The most common case of this is where I have the choice between using 4-6 lines, or one line, and it's an easy choice for me to pick one line, though I've never encountered a coding standard that agreed with me.

Re: Line length in programming

#39
post #35

The argument about no one editing in a 80 character terminal anymore is a straw man. That's not the real reason 80 characters is good. The article even says why - we're just not good at reading long lines for whatever reason. There's two modern reasons for smaller liner lengths (80-100) besides cognitive capacity: Viewing/editing two files side by side on the same screen. Side by side diffs. Now, that's not to say th…

The main argument for me, additionally to what you describe, is keeping lines readable. There is a reason the books from 1000 years ago were made vertical. They could have used much more width and characters per line but they didn't. See the newspaper format as well with multiple columns. The eye struggle to follow a text that is too wide.

For me, 80 chars is an arbitrary but acceptable limit (I could even argue it should be even shorter).

Personally, I view verbose languages that needs longer line as bugs. If you look at Scheme for example, it lets you wonderfully indent and nest, so that you rarely need long lines. Everyone benefits from it. Shorter lines are better for the brain, the problem is when coding languages make line too long by design, forgetting the 1000 years of experience in typography we've accumulated.

Re: Line length in programming

#40

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.

Really?

    class Engineer(Person):
        __tablename__ = 'engineers'
        __mapper_args__ = {'polymorphic_identity': 'engineer'}
        engineer_id = Column('id', Integer, ForeignKey('people.id'), primary_key=True)
        primary_language = Column(String(50))

    12345678901234567890123456789012345678901234567890123456789012345678901234567890
    ^^ Line length marker
Woops. 2 characters over. Do we really need a line break there?

Guess perhaps I should rename my columns with more obscure names like engnr_id instead.

Seriously; you see this in python all the time; people not wanting to break the line because its only a character or two off, and then stupidly renaming a variable to some obscure abbreviation instead.

We won't go into the 2-character indents argument, or the push for the 100 character limit that the BDFL veto'd for the PEP8 revision; but... safe to say, I think a fair number of people hit this as an issue.

I don't think 'you can just refactor that to be shorter' is really a solution in all circumstances.

Post reply on HN