Live data from Hacker News

Line length in programming

ck.kennt-wayne.de

41–50 of 74 posts

Re: Line length in programming

#41
post #19
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."

Please take the time to review and correct this sentence next time you copy-paste. This is a painful read.

Missing the occasional definite article out is something that seems to be fairly common with second language english speakers.

I decided some time ago that it was worthwhile forcing myself to adjust until it wasn't noticeably painful; there are too many people out there I want to communicate with who do it.

Re: Line length in programming

#42

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

In perl I'd just write -

    return $some_loaded_thing->fairly_descriptive_but_necessarily_long_name(
      $not_very_long_argument
    );
Surely python has something approximating an equivalent?

Re: Line length in programming

#43
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…

What doesn't help is silly idioms in some environments where most of the lines written START at 2 or 3 indents deep because they're inside a method inside a class inside a namespace that are all indented.

===

If anyone's interested, I wrote a simple command to scan files for configurable line length violations and the presence of a file-terminating line ending.

https://github.com/frou/pagecop

(yes, I'm aware it could probably be duplicated with some sed/awk wrangling!)

Re: Line length in programming

#44

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

For what it's worth, in my opinion, if you need more than an 80 character line in Python, you're doing it wrong.

I currently maintain a large Python codebase where the original authors /needed/ big long lines. Anytime I see one of these big wads of bubble gum, I know I can rewrite it to be simpler, clearer and shorter (I've done it enough now). Fortunately, there are increasingly fewer of them...

It's important to remember that you're not just writing for the computer -- while it can take almost anything syntactically correct that you throw at it -- some human, somewhere will still have to read and understand that code.

It may be you, six months later.

Re: Line length in programming

#45
post #41
post #19

Earlier quoted context omitted.

Please take the time to review and correct this sentence next time you copy-paste. This is a painful read.

Missing the occasional definite article out is something that seems to be fairly common with second language english speakers. I decided some time ago that it was worthwhile forcing myself to adjust until it wasn't noticeably painful; there are too many people out there I want to communicate with who do it.

Spot on. ESL. Grew up in the U.S as a kid. Took grammar as elective. But I can't perfect my writing (and am too tired to correct it now). Shoot an email to yeukhon@acm.org for a correction, if needed. Just fixed a bit, not sure if the revision is better or worse. Probably missing some "the". Can't edit it now :3

Re: Line length in programming

#46

Earlier quoted context omitted.

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

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

Re: Line length in programming

#47
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."

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 natural english. It also has the good side-effect of making lines shorter, more terse.

Re: Line length in programming

#48
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 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 code it's folding) aside, this is a really poor solution. If you just need that done temporarily, why not temporarily replace all the returns in the region you select, and then add them back when you're done? Any editor with search-and-replace can do that.

> 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,"

No, what I might say is "just stop thinking about the SQL query and the surrounding code in the same context".

Alternatively, put the SQL query in a separate function that conveys some meaning related to its purpose, so that people who read your code later don't have to decipher a 300-character query line in order to understand what that code is doing. They may not even be debugging that part of it, maybe something several layers of abstraction above borks and they end up in that part of the code debugging it.

> (easy to find a given key, but consumes lots of vertical space)

which can be easily averted with code folding? Or by simply scrolling down to the body of your code. Skipping entire lines is very easy, it's following a hundred-character snake that sucks.

Re: Line length in programming

#49
post #34

Earlier quoted context omitted.

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?

A 1920pixel-wide monitor is 274 characters wide (if your characters are 7 pixels wide, like mine). That's two files side-by-side with 100 character lines, or three files side-by-side with 80 character lines.

Re: Line length in programming

#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 generally longer

In today's world I see little reason to hold to the 80 character limit causing line breaks in what would other-wise be odd places.

That all being said, we still have yet to realize an editor that displays source code in a programmers preferred spacing while saving the program in the repository's preferred spacing. THAT is the real issue, here -- that editors are not helping with this issue, wrapping and indenting code as the screen width allows.

Your primary concern, with line-length, should be readability -- if your group decides 72 characters is the limit, well, so be-it, but I would press anyone who believes that is acceptable for JAVA.

And I no longer see a reason why one line length limit should hold for all source files. Why not let the source code decide the best line length -- we no longer have fixed sized screens, these are windows that expand with click and drag.

Post reply on HN