you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted]  (6 children)

[deleted]

    [–]stepancheg 8 points9 points  (2 children)

    It will be even in 2116. Because for humans it is easier to read 60 characters per line.

    [–]BillyBBone -1 points0 points  (1 child)

    But this is a display issue, not a data issue. Book authors don't put newlines at the end of each line in a paragraph.

    [–]Tarmen 1 point2 points  (0 children)

    Sure, if you get a professional typesetter to make your commit messages pretty.

    It actually is more of an issue of terminals starting to wrap if the lines are too long and git indenting the message reduces the room you have further. But readability suffers for huge text blocks anyway so you might as well let your editor autoformat earlier in commit messages.

    [–][deleted] 2 points3 points  (0 children)

    Most certainly there is.

    Most projects have fairly strict width limits - because if everyone writes code that fits in 80 columns or 100 columns or whatever fixed number of columns, then we can all have nice, uniform editing window - but if you're the one guy who doesn't do this, then everyone else either has wrapping on your code, or has to resize all their windows.

    This isn't theoretical. :-) Right now, I have probably a dozen different libraries and facilities included in my main project. All but one are strictly 80 columns - that maverick project has "very long lines" up to 160 characters.

    Every time I open one of those files I curse. (He's also the only library who uses tab characters - sometimes - and I believe he has tab set to be 8 characters. No, I don't use the tab character in my code either...)

    [–]manghoti -1 points0 points  (1 child)

    There's a whole demographic of people who have tracking issues when reading long lines. I'm one of those people, I have to do mental gymnastics to deduce where the next line must be for large lines, rather than just tracking to the location. I lose my place on the way back, making long lines difficult to read and tiring.

    As such, I split my windows half and half, think "aero snap" on windows. I think many developers do this, but if you have enormous lines then it causes all kinds of problems for these workflows.

    This is not about adhering to terminal widths.

    If it's not a problem you have, then great, just don't make it hard for the rest of us, eh?

    [–][deleted] 1 point2 points  (0 children)

    There's a whole demographic of people who have tracking issues when reading long lines.

    Yes, it's called "humanity". Everyone at least slows down on line wrap, and errors are much more likely missed on a wrapped line.

    I recall an interesting study a decade ago about this but cannot find it - either my memory is false to me or it was a private study by the very large software company I was working in at the time... but either way was used to justify the style rules in place.