Right border in source text

    When refusing source code, we all use some Code Convention. It’s good when there is a document inside the company that describes these agreements. If not, then you have to use some well-known, which seems standard to us . Although, of course, the concept of its standard is quite relative. It’s better to have such a document inside the company so that there are no differences in the team.

    One of the questions that arises in the formation of such a document is the right border in the source text. Previously, it was customary to use the right border of 80 (or even 76) characters. But now the monitors are wide. Maybe you can not limit it? Or should it be limited anyway? Here, for example, and more recently, in this articleThis issue caused quite a lot of controversy. Under the cut, my vision of this question + poll.

    Why is there such a restriction of 80 characters? A bit of history. Of course, you quickly recall that the old monitors in text mode had such a width. This limitation was especially important when monitors (together with the video system) did not yet have a graphic mode. And so it was decided to try to fit the program text in 80, and even better in 78 or even 76 characters. Less than 80 was customary to use because on some not very high-quality monitors, the right and left sides were either greatly distorted or even hidden behind the casing. I came across a lot of monitors, which lost about half of their familiarity on the left and right.

    In addition to monitors, printers had this width. Of course, there were also wide printers. But the most affordable printers designed for A4 paper or a roll of the same (210mm) width neatly printed the same 80 characters on paper.

    Moreover, the punched card also contained 80 characters.

    That is, 80 characters of line width was, de facto, the industry standard that was introduced, in my opinion, by IBM.

    We sorted out the story.

    Well, God bless them with punch cards and printers. From the beginning of the zero, to me personally, it is not so often necessary to print the source text on paper, and performance cards have completely disappeared into the past.

    The question may arise: what is the problem with the fact that the source text goes abroad? Maybe let it be? The compiler doesn’t really care what the length of the string is. And even if our screen still has a width of 80 characters, and we need to look in the IDE what is behind the right border of the screen, then we can move the cursor to this line and go to the end. Maybe this is the way out?

    Not really. This is not an option. We write the source text for people to read, not just the compiler :). If a programmer who reads the source code does not see something at once with one glance, then with a high probability he will miss something and will not understand. Or take the time.

    But why on modern monitors do not get away from this standard? Indeed, the significance of 80 characters began to decline with the transition to graphic screens with relatively high resolution. If, at a resolution of 640x480 VGA adapter, it would be difficult to fit more than the same 80 characters on the screen (8 pixels per width of each character) (although I saw relatively good readable fonts with 5 and 6 pixels for each character in width). Even at a resolution of 1024x768, it was possible to either improve the quality of rendering characters or increase their number per line. Or simply add some additional functions to the left and right of the source text - the project tree, chat with another developer, and so on.

    There is another option- Do not wrap the string yourself, but leave this work on the IDE when displayed automatically. That is, in reality this is one long line, but in the IDE it is displayed with a hyphen. Maybe this is the way out? In principle, this is already less bad ... For some reason, this option turned out to be familiar to me iOS developers. Probably because in connection with the collections of the Objective-C language, wrapping to another line is not always obvious. That is, it is not always clear what exactly and exactly where to transfer. Well, that’s probably why Apple by default in their IDE (called Xcode) made this option enabled by default.

    But then again. We are writing the source text for people. Is not it? And with such an automatic transfer mode, the structure of the function may be lost, and therefore, the logic will be more difficult to understand. Therefore, this is also a bad option.

    The third option . With modern 1920s and more pixels in width, displaying a large number of characters is not a problem. Maybe we will leave the right border as such, but at the same time, increase it from the old 80 to 160? or at least 120 characters?

    Well this option is even better than the previous one. But still. Of course, monitors are now wide. With an aspect ratio of 9:16 or 10x16 and having a resolution on the wide side, say, 1920 or 2560 pixels of text, it can accommodate a lot. Moreover, with high-quality font rendering.

    And everything would be fine ... Well, if you have to combine (freeze) several branches of the source text? For example, what would a three-point merge look like?

    For example, here are screenshots of KDiff3. Especially this one:

    image

    What will now look like three copies of your source text 120 characters wide each on your monitor with a total of 1920 pixels wide? You will either have to sacrifice the quality of the font rendering, that is, reduce the size and strain your eyes. Or lose some of the logic that will be hiding behind the right border. The second option is generally not acceptable! Since the need for a three-point merge arose as a result of the conflict. And to me (or to you), in the merge process, you need to understand exactly the logic that another developer implemented in the left version of the source text, relative to the base (center) and the right version of the source text relative to the base. You need to see all the logic!

    With a screen width of 1920 pixels, I get 80 characters of 8 pixels for each character in width for all 3 versions of the source text. And that's not counting the overhead of displaying line numbers, borders, and so on.

    Therefore, I am abroad in 76 characters!

    Well, a 3-point merzh does not happen every day. Let the border be 100 characters. But not more :)

    Only registered users can participate in the survey. Please come in.

    What do you think about the right border?

    • 22.3% Don't use the right border 244
    • 0.5% I do not write the source text 6
    • 2.1% I use the border 76 - our everything! 23
    • 30.3% I use the border of 80 - a classic for all time! 332
    • 11.6% I use the border of 100 - enough for everyone. 127
    • 22% I use the border of 120 - what is the little thing? 241
    • 10.4% There is definitely some kind of border, but more than 120. 114
    • 0.6% I will write my option in the comments 7

    Also popular now: