Right border in the source text
When we source the source text, we all use some kind of Code Convention. It is 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 to us to be standard . Although, of course, the concept of its standard is very relative. It is better to still have such a document inside the company, so that there would be no differences in the team.
One of the questions that arises when forming such a document is the right border in the source text. Previously, it was decided to use the right border of 80 (or even 76) characters. But now the monitors are wide. Maybe you can not limit? Or is it still necessary to limit? Here, for example, and quite recently, in this article this question has caused quite a big controversy. Under the cut is my vision of this question + survey.
Why did this restriction - 80 characters? A bit of history. You, of course, quickly recall that old monitors in text mode had that width. This restriction was especially important when the monitors (together with the video system) did not yet have a graphics mode. And so it was decided to try to contain the text of the program in 80, and even better in 78 or even 76 characters. Less than 80 was taken to be used because on some not very high-quality monitors the right and left side were either greatly distorted or hidden behind the casing. I came across many monitors, which lost about half the familiarity on the left and the right.
In addition to monitors, printers had this width. Of course, there were 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 punch card also contained 80 characters.
That is, 80 characters of the string width was, de facto, an industry standard that was introduced, in my assumption, by IBM.
With the story figured out.
Well, God bless them with punched cards and printers. From the beginning of zero, I personally do not often have to print the source text on paper, and the perforations are a thing of the past.
A question may arise: what is the problem with the fact that the source text goes abroad? Maybe let? The compiler is not very important what is the length of the line. And even if our screen is still 80 characters wide, and we need to see in the IDE what is beyond the right edge of the screen, 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 code 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 spend time.
But why on modern monitors do not get away from this standard? Indeed, the significance of 80 characters began to decline as the transition to graphic screens with relatively high resolution. If at a resolution of 640x480 VGA adapter it was difficult to fit on the screen more than the same 80 characters (8 pixels for each character width) (although I saw relatively well-readable fonts having 5 and 6 pixels for each character in width). That at a resolution of 1024x768 could either improve the quality of drawing characters or increase their number per line. Well, or just 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 transfer the string yourself, but leave this work on the IDE automatically when displayed. That is, this is actually one long line, but in the IDE it is displayed with a carry. Maybe this is the way out? In principle, this is less bad ... For some reason, this option turned out to be familiar to iOS developers. Probably because, in connection with the features of the Objective-C language, transfer to another line is not always obvious. That is, it is not always clear and clear what exactly and where exactly it is necessary to transfer. Well and, probably, therefore Apple by default in its IDE (which is called Xcode) made this option enabled by default.
But again. We write the source code for people. Is not it? And with this automatic transfer mode, the structure of the function may be lost, and therefore the logic will be harder to understand. Therefore, this is also a bad option.
The third option . With modern 1920 pixels and more pixels, it is not a problem to display a large number of characters in a high quality manner. Maybe we will leave the right border as such, but at the same time, we will 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, the monitors are now wide. With an aspect ratio of 9:16 or 10x16 and having resolution on the wide side, say, 1920 or 2560 pixels of text can hold a lot. Moreover, with high-quality font rendering.
And everything would be fine ... But if you have to merge (loose) several branches of the source text? For example, how will the three-point merge look?
For example, here are the screenshots of KDiff3. Especially this one:
What will three copies of your source text 120 characters wide each look like on your monitor from just 1920 pixels wide? You will have to sacrifice or render quality fonts, that is, reduce the size and strain your eyes. Or lose part of the logic that will be hidden behind the right border. The second option is generally not acceptable! Since the need for a three-point merger arose as a result of the conflict. And I (or 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. 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, okay, 3-point point doesn’t happen every day. Let the border be 100 characters. But not more :)
One of the questions that arises when forming such a document is the right border in the source text. Previously, it was decided to use the right border of 80 (or even 76) characters. But now the monitors are wide. Maybe you can not limit? Or is it still necessary to limit? Here, for example, and quite recently, in this article this question has caused quite a big controversy. Under the cut is my vision of this question + survey.
Why did this restriction - 80 characters? A bit of history. You, of course, quickly recall that old monitors in text mode had that width. This restriction was especially important when the monitors (together with the video system) did not yet have a graphics mode. And so it was decided to try to contain the text of the program in 80, and even better in 78 or even 76 characters. Less than 80 was taken to be used because on some not very high-quality monitors the right and left side were either greatly distorted or hidden behind the casing. I came across many monitors, which lost about half the familiarity on the left and the right.
In addition to monitors, printers had this width. Of course, there were 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 punch card also contained 80 characters.
That is, 80 characters of the string width was, de facto, an industry standard that was introduced, in my assumption, by IBM.
With the story figured out.
Well, God bless them with punched cards and printers. From the beginning of zero, I personally do not often have to print the source text on paper, and the perforations are a thing of the past.
A question may arise: what is the problem with the fact that the source text goes abroad? Maybe let? The compiler is not very important what is the length of the line. And even if our screen is still 80 characters wide, and we need to see in the IDE what is beyond the right edge of the screen, 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 code 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 spend time.
But why on modern monitors do not get away from this standard? Indeed, the significance of 80 characters began to decline as the transition to graphic screens with relatively high resolution. If at a resolution of 640x480 VGA adapter it was difficult to fit on the screen more than the same 80 characters (8 pixels for each character width) (although I saw relatively well-readable fonts having 5 and 6 pixels for each character in width). That at a resolution of 1024x768 could either improve the quality of drawing characters or increase their number per line. Well, or just 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 transfer the string yourself, but leave this work on the IDE automatically when displayed. That is, this is actually one long line, but in the IDE it is displayed with a carry. Maybe this is the way out? In principle, this is less bad ... For some reason, this option turned out to be familiar to iOS developers. Probably because, in connection with the features of the Objective-C language, transfer to another line is not always obvious. That is, it is not always clear and clear what exactly and where exactly it is necessary to transfer. Well and, probably, therefore Apple by default in its IDE (which is called Xcode) made this option enabled by default.
But again. We write the source code for people. Is not it? And with this automatic transfer mode, the structure of the function may be lost, and therefore the logic will be harder to understand. Therefore, this is also a bad option.
The third option . With modern 1920 pixels and more pixels, it is not a problem to display a large number of characters in a high quality manner. Maybe we will leave the right border as such, but at the same time, we will 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, the monitors are now wide. With an aspect ratio of 9:16 or 10x16 and having resolution on the wide side, say, 1920 or 2560 pixels of text can hold a lot. Moreover, with high-quality font rendering.
And everything would be fine ... But if you have to merge (loose) several branches of the source text? For example, how will the three-point merge look?
For example, here are the screenshots of KDiff3. Especially this one:
What will three copies of your source text 120 characters wide each look like on your monitor from just 1920 pixels wide? You will have to sacrifice or render quality fonts, that is, reduce the size and strain your eyes. Or lose part of the logic that will be hidden behind the right border. The second option is generally not acceptable! Since the need for a three-point merger arose as a result of the conflict. And I (or 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. 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, okay, 3-point point doesn’t happen every day. Let the border be 100 characters. But not more :)
Source: https://habr.com/ru/post/177287/
All Articles