Hacker News Reader

Comment by matthewmacleod | Hacker News Reader

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

View on HN

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)

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.

> 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 Zope) most commonly used python orm around.

Wordy database interaction is really common point this sort of thing, and it's hard to refactor/rewrite your way out of it; that's the only real point I'm making.

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

> 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

Bingo. To quote Captain Jack Sparrow, style guides are "more what you'd call guidelines than actual rules".

They're not a substitute for common sense, and sometimes breaking the rules is for the greater good. I find the similar situations in shops that enforce strict naming conventions.

edit: The other tip is that the 80 character limit is closely aligned to the optimal line length for regular reading: http://ux.stackexchange.com/questions/3618/ideal-column-widt... A bit more than normal is allowable for programming because of indentation and the more structured nature of the text.

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.

I hate the 80 character limit. I find it counterproductive. Its usually faster to find a closing brace on the same line, than scan lines until you find it. Kind of the opposite effect of Python's whitespace. I like to leave my lines longer, as I find if gives my code shape that I can recognise.

Reply on news.ycombinator.com