> When you have 80 characters for line, you are wasting a lot of horizontal space on most configurations. But then you're requiring those who read through your

> When you have 80 characters for line, you are wasting a lot of horizontal space on most configurations. But then you're requiring those who read through your code to have the window displaying your code maximized in order to avoid having it wrap or having to scroll to read it. > Second, at least for me, I am focusing on 1 file most of the time. 90% of the time, I write code in 1 file, with maybe 10%, I look at 2 files. When viewing diffs, a lot of people like to view them side by side. In some cases, people use a tool like kdiff3 to handle merges and need to be able to see 3 copies of the file side by side. > Third, when you break at 80 characters, you waste more space cause you need to indent the new lines that were broken up. It really depends on whether you use a lot of long variable names and/or have to include scope identifiers when referencing them. In python, a typical module may have a very small fraction of statements that require lines greater than 80 characters. That means that it doesn't add that many more lines to the file compared to just keeping those longer statements as a single line. > Fourth, if you use languages like Python that have semantic whitespace, you need line continuation characters that just add to the noise. Not necessarily. Any opening (, [, { can effectively serve as a continuation character. So you could write a print statement like: print( 'Hello there. ' 'This will be printed on a single line.' ) > Fifth, for those cases where you are comparing code side by side, having an editor that does intelligent wrapping to make code narrower is not that big of a deal. For line based diffs, it does make the diff significantly harder to read in my experience (especially when looking at the source file in conjunction with the diff).