Quoting Niels Basjes (2015-05-05 11:29:03) > So the 80 chars thing was at best reconsidered 16 years ago. > > Things have changed ...
Limiting text to a particular width isn't just a byzantine coding convention. It arose in programming from much older practices, and it has persisted through the years because it improves readability (not just of code, but of any text). 80 columns was a fairly standard width for teletypes (and later of video terminals). This was mostly a cultural legacy of the IBM punch cards, which were 7.375" wide and contained 80 character columns. IBM introduced these cards in 1928, but they were not the first of their kind. Punched cards have been widely used since the early 19th century to control textile looms, mechanical church organs, and various other machines. I would posit that the choice of width for punched cards was chosen to match the width of printed text. Line length was historically tightly limited; sometimes pages would be divided into multiple narrow vertical columns. The original edition of the Gutenberg Bible is has a printed text area of about 11.7" tall by 8" wide and is divided into two vertical columns, each with about 34 characters per line. Newspapers and textbooks tend still to adhere to this practice -- they are usually printed in very narrow text columns (30 to 50 characters). Other books (particularly fiction) tend to be wider, at 60 to 70 characters per line, and some websites tend even wider than that. I don't believe that there's a particular line length that is optimal for all use cases, but I think there are two strong arguments for setting some (fairly conservative) line length limit when laying out conventions for code style. One is that people will find text most comfortable to read when it is formatted in a familiar way. Code is almost universally limited to a maximum of some number of characters per line (I've seen 80 most frequently, but also 72, 100, and 120). Another, which applies specifically to code, is that (unlike most prose) code is written in the same format in which it is archived and later read. So, unlike the debate about line length for web pages or printed books, the debate over code width applies not only to readability but also to *writability*. A professor of mine once told me that if I am writing code and reach the end of the (80-column) text area, I should pause to ask myself what has gone wrong. Perhaps my variable names are too verbose, or perhaps that line contains too much logic and should be separated into two lines. I still adhere to this, and I find that it consistently improves the quality of the code that I write. Perhaps 80 columns isn't the right number (certainly it would vary depending on the syntax of the language, conventions related to tab width, and other similar factors), but I do find that having such a limit forces me to pause and ask myself whether I can be clearer in my expression of the program's logic. I think this is a good thing. I don't wish to dismiss the option of revisiting the 80-columns convention. I only hope to have convinced you that code width is not just a legacy terminal compatibily issue -- it has important code quality and readability implications too, and those should be carefully considered when creating or updating a style guide. Best regards, -Jake
