The measures of programming

80 rows and 25 columns were the measures of one of the most popular VGA text modes in the 1980s and 90s. Today we have far more powerful graphic cards, which render several megapixels every second, on our 24" monitors.

Yet I would argue that a typical programmer does not need more than an 80x25 fixed-width characters windows for wiewing code. My measures are for PHP code, but if you change the actual numbers, fixed dimensions may work also with your Java or Ruby code.

If you are into IDEs, the screen real estate can be used for displaying other helpful informationand avoid a context switch, like a list of available methods, a tree of folders and files, or your red/green bar. I myself keep another terminal open with my running Vim one, to issue version control commands (although I may integrate that in the Vim window in the future.)

Width

So why 80x25 terminals? These measure may seem a limitation, but in fact many programming practices are based on constraints. For example, structured programming (if, for while) limits you from jumping around in your code. Private and protected scope for your class members limit from where they can be accessed. Constraints are not really that bad if they force you to simplify your mathematical model of reality (which is to say, your codebase).

The 80 character limit detects lines which are too long to be quickly understood. Some IDEs (e.g. Netbeans) may display a red line on the 80 character limit to show you if you're exceeding it (I think this number is of course configurable). My Vim displays a red background on the lines segments after. the 81 character.

Static analysis tools, such as PHP_CodeSniffer, bundle coding standards that display a warning when a line is too long and an error when it is really too long (more than 120 characters in the Zend standard):

        if (!$this->getParam('noViewRenderer') && !Zend_Controller_Action_HelperBroker::hasHelper('viewRenderer')) {
            require_once 'Zend/Controller/Action/Helper/ViewRenderer.php';
            Zend_Controller_Action_HelperBroker::getStack()->offsetSet(-80, new Zend_Controller_Action_Helper_ViewRenderer());
        }

What's the condition? And what happens in line 3? I find it difficult to tell at a glance.

If you keep lines short, the readers of the code will be able to follow the flow by moving almost always in the vertical direction, without the need to explore the horizontal dimension and mismatch start of lines with the end of other lines. Again, IDEs may evidence you the selected line so that you don't lose your place, but I bet when reading code you don't continuously move the cursor on the line you're currently reading.

Height

The 25 measure detects too long methods: when you find yourself continuously going up and down your 25-line viewing window to understand what a method does, chances are that it is already too long.

In fact, the limit for ideal method length is probably set on an even lower measure, like 6-10 lines according to Uncle Bob. However, I don't have absolute measures as the length of methods depend on the brevity of the programming language you're using: Java and Python are really different and a method of 6 lines in Python may correspond to a larger, longer version in Java. In Matlab, the same method would probably be twice as long.

Within different programming languages, a limited viewing window discourages programmers from writing and maintaining long methods. If you can adjust the window's height up to 2000 pixel, you'll never touch the 100-line method which would force you to scroll completely 4 times in order to read it all.

Consider regions: some IDEs let you define special comments that act as navigation guidance. If you need regions to navigate into a class, that class is already too long for my taste. Folding of methods may be a good idea instead, but when you open a method it still needs to be shorter than the 25 lines limit.

Indentation

I am also a fan of another measure equivalence, which the 4 spaces for one tab (in general, for one level of indentation). I'm not entering into the tab vs. spaces religion war, but I think that levels of indentation are really readable when represented by 4 spaces, or by a tab character visualized with a width of 4 spaces. 4 spaces is also Python's standard (when not using tabs).

The alternative choices for indentation are 2 spaces per level and 8 spaces per level.

2 spaces are probably too few to easily detect the indentation, especially if you're pair programming and viewing the code from a skewed angle (if you pair with two screens, good for you).

8 spaces are in my opinion probably too much; if you work with object-oriented programming, like many of us, you already start writing most of your code with two levels of indentation (class and method). If you have to write a line in a cycle, you will end up with just 55-56 characters for your line.

Thus, 4 spaces will easily detect too many levels of indentations in the same method, a symptom of a method that merges many different levels of abstractions; at the same time, they will let you use two nested cycles like the ones for accessing a bidimensional array (an image for example).

class MyClass {
    public void doSomething(Image image) {
        for (int x=0; x < height; x++) {
            for (int y=0; y < width; y++) {
                doSomethingWithPixel(image.at(x, y)); //this line: 80 characters
                // why would you need a longer one?
            }
        }
    }
}

Conclusions

These are the reasons why I find myself comfortable with 80x25 windows and a 4-space indentation width. What do you use instead? Maximized Eclipse on a 30'' monitor? 2 spaces like in the Symfony 1 coding standard? Why do you find it helpful?