I actually spent an inordinate amount of time calculating the ideal a while back. As a sometime designer, I’m quite intimately familiar with the limits of comfortable reading for the human eye. After a silly quantity of math, I arrived at exactly 115 columns in fixed-width text as the ideally comfortable balance between readability and compactness.

Subtracting two for `diff` output, I hard-wrap all of my source-code and documentation files at column 113 exactly, and have for quite a while. It results in some quite sane output, in my opinion: https://github.com/elliottcable/Paws.c/blob/d2a5f3f/Source/P...

There are, of course, arguments to be made about source code itself; arguments you didn’t generally need to worry about at 78 characters, but that start to come into play when given that extra 35 columns; you need to start worrying about whether a given line of code is sane or readable once it starts to stretch towards 113 characters. There’s some situations where that’s perfectly normal and looks fine; but there’s also several where that indicates a serious problem in your code’s style. It’s just one more thing to think about while you design your source code.

What "silly quantity of math" did you do to reach your conclusion?

I would have assumed that this sort of thing was simply an unquantifiable aesthetic preference (as long as you're below the char width of the screen, of course). I'm very interested in learning more about how you can come up with a 'right' answer to this sort of question, since I struggle with similar problems all the time (website layouts, etc).

I definitely agree. It matters more that there is a sane limit than what that limit actually is. Your 113 column files look good to me.

I was kidding, a little. I think 80 characters wide feels a bit cramped (and an artifact from a time before the visual user interface and high resolution displays), but 200 character lines is clearly way too much.