No your line is too long.
-
At most one line that length. Try a smaller font -- I use 8pt. I also try to limit my line lengths to 112 characters. I used to use VT screens set to 132 characters per line. 132 characters per line ought to be enough for anybody.
With a readable size font, my maximum line length is 544 characters with 135 lines on the screen. I could do more with a slightly smaller font or perhaps a different font. That is not to say that I have written lines that long, I don't actually know how long that would be. We are not using punched cards anymore, we are not restricted to fan-fold paper -- who actually uses paper anymore? There is no unacceptable maximum for either the number of lines in a method / function or the length of a line. In both cases, I would expect the set of lengths to be a power distribution. Where the vast majority of function / line lengths are very short, and very long lengths would be extremely rare -- but no upper limit. The length of either a function or a line should be considered on a case by case basis. There are many times that the most important information in a line of code occurs in the first 20 or 30 characters. The best readability may be a very, very long line because the majority of the time the remainder of the line is not of interest when reading code. If there is a problem with lines that are too long, get a better monitor. My primary monitor is a 50" 4k monitor (actually TV, but that replaced a failed 48" 4k monitor because it was something like $200 instead of $2000). When available, and when I can afford it, my next monitor will be 55-65" and 8k. Even without a better monitor, just scroll left / right or up / down.
-
From CP newsletter https://www.codeproject.com/News.aspx?ntag=19837497829658814&_z=2928472[^] They want to run their monitors in a diagonal mode because? "Why 22 degrees? At that angle, you get the longest line length (stretching between opposite corners)" My answer to that - your line is too long. Make it shorter. You are not writing code for you but are writing it for the people in the future that must maintain it.
I do actually find myself trying to stick to 80 lines, but some expressions just end up longer than that, with LINQ and so on - and in some cases, splitting the line makes it less readable. It's like this guy in a bar - the bartender bet him he couldn't drink the contents of the spittoon, so off he went, gagging and choking and turning blue, and kept going long after the bartender told him he could stop - and finally made it - and the bartender said, "Why didn't you stop?" and he replied, "I couldn't: it was all in one solid lump!"
-
So you are saying that they get maybe three really long lines and then they have to make do with 20 or 30 lines that are maybe 10 characters or less. Sounds like a fitting punishment.
If it gets too long vertically then we can combine multiple approaches. In my code I don't get to 20 or 30 lines that are part of a single statement.. but if it happened to me, I'd probably split it up into multiple statements. It would probably also make it easier to debug/troubleshoot.
-
obeobe wrote:
the conclusion that 22 degrees is the optimal angle is also not backed by any proof
Must depend on the aspect ratio of the particular monitor. When that is known it should be really simple to calculate what angle to tilt the monitor in order to have the diagonal become horizontal. Other than that, I find the concept of diagonal mode hilarious :laugh: . And yes, a complete waste of space on the other parts of the screen.
Quote:
it should be really simple to calculate what angle to tilt the monitor in order to have the diagonal become horizontal.
Yes, but where's the proof that making the diagonal horizontal is optimal for developers? (or for any other use case, for that matter).
-
A long time ago, I read about a study - in a printed periodical, so no URL - where a number of test persons were split into two groups and given the same source code to study. One group got it laid out like ordinary prose, the way you would write a plain text? ("If the rain stops, let's go to the beach. Otherwise, let's break a bottle of wine!" in a single line). The other group got the same program laid out "the programming way", with conditions, if- and else-clauses on separate lines, with proper indentations etc. Similar for loops and other constructs. After the test persons had been given a controlled amount of time to study the code, they were to fill in a questionnaire to reveal how well they had understood the program logic. It turned out that those who had read the "prose formatted" program code scored significantly higher than those who had been reading the "program structured" layout. This is so many years ago that the average person still could be expected to read both fiction and non-fiction books. Today, lots of young people never read a novel after the Harry Potter books (which they chose when school required them to pick one novel to read). So maybe the results would be different today, with lots of people inexperienced with extracting meaning unless it is conveyed both in text, semantics highlighted with punctuation and structure mediated through blocks and indentation.
Religious freedom is the freedom to say that two plus two make five.
A citation would be helpful.
Gus Gustafson
-
Quote:
it should be really simple to calculate what angle to tilt the monitor in order to have the diagonal become horizontal.
Yes, but where's the proof that making the diagonal horizontal is optimal for developers? (or for any other use case, for that matter).
Ah yes - *that* proof. Totally agree. That assertion *must* have been written tounge-in-cheek :) . At least, I very much hope so :laugh:
-
With a readable size font, my maximum line length is 544 characters with 135 lines on the screen. I could do more with a slightly smaller font or perhaps a different font. That is not to say that I have written lines that long, I don't actually know how long that would be. We are not using punched cards anymore, we are not restricted to fan-fold paper -- who actually uses paper anymore? There is no unacceptable maximum for either the number of lines in a method / function or the length of a line. In both cases, I would expect the set of lengths to be a power distribution. Where the vast majority of function / line lengths are very short, and very long lengths would be extremely rare -- but no upper limit. The length of either a function or a line should be considered on a case by case basis. There are many times that the most important information in a line of code occurs in the first 20 or 30 characters. The best readability may be a very, very long line because the majority of the time the remainder of the line is not of interest when reading code. If there is a problem with lines that are too long, get a better monitor. My primary monitor is a 50" 4k monitor (actually TV, but that replaced a failed 48" 4k monitor because it was something like $200 instead of $2000). When available, and when I can afford it, my next monitor will be 55-65" and 8k. Even without a better monitor, just scroll left / right or up / down.
Member 11816776 wrote:
There is no unacceptable maximum for either the number of lines in a method / function or the length of a line.
By that argument then every code file you write should be one line. But the real argument in a business environment is that you are not writing code for yourself. You are writing it for the company. Which is why they pay you. And unless you are a deity someday someone else will need to modify that code. Matter of fact studies have shown that the cost of maintaining code is between 2 and 100 times as much as creating it in the first place. And the company must pay that. So a responsible professional developer should create code that one can reasonably be maintained by a future programmer and not the original author.
Member 11816776 wrote:
There are many times that the most important information in a line of code occurs in the first 20 or 30 characters. The best readability may be a very, very long line because the majority of the time the remainder of the line is not of interest when reading code.
And yet your very statement points out that the rest of the line can be important.
Member 11816776 wrote:
If there is a problem with lines that are too long, get a better monitor
No the solution then is during the code review to tell the author to reformat the line so it is shorter. I have even seen one review process where long lines could not even be viewed so one had to pop to view the file then find the line.
-
obeobe wrote:
the conclusion that 22 degrees is the optimal angle is also not backed by any proof
Must depend on the aspect ratio of the particular monitor. When that is known it should be really simple to calculate what angle to tilt the monitor in order to have the diagonal become horizontal. Other than that, I find the concept of diagonal mode hilarious :laugh: . And yes, a complete waste of space on the other parts of the screen.
Makes one wonder... If you use multiple monitors how does one arrange that? Side by side - so two diamonds with the points touching? Or one on top of the first so it is flat to first one? And what happens when you get a person that thinks 5 monitors is a good idea?
-
I do actually find myself trying to stick to 80 lines, but some expressions just end up longer than that, with LINQ and so on - and in some cases, splitting the line makes it less readable. It's like this guy in a bar - the bartender bet him he couldn't drink the contents of the spittoon, so off he went, gagging and choking and turning blue, and kept going long after the bartender told him he could stop - and finally made it - and the bartender said, "Why didn't you stop?" and he replied, "I couldn't: it was all in one solid lump!"
Dan Sutton wrote:
end up longer than that, with LINQ and so on
LINQ itself lends (pretty much requires) longer lines but they can certainly be formatted. This is similar to formatting SQL in C#, Java, C++, etc when it is a string. The first try always starts out as one long string until one understands that it can be formatted in a way that makes it readable.
Dan Sutton wrote:
and in some cases, splitting the line makes it less readable.
Not sure I believe that. But one can certainly reformat a long line in a way that makes it confusing. But that is a formatting problem rather than that the technique itself is flawed. A long line pretty much starts out being difficult to read/understand regardless of how it is formatted. Long lines will have 'parts'. So for example LINQ for a db has a data object, clauses, etc. SQL as a string has the same thing. If you write SQL in a stored proc it can be formatted in the same way. Keep in mind of course that for C#/Java/C++ line breaks are not required. So one can write a method (and even a class) on few or even one line. But very few would claim that is a good idea.
-
Dan Sutton wrote:
end up longer than that, with LINQ and so on
LINQ itself lends (pretty much requires) longer lines but they can certainly be formatted. This is similar to formatting SQL in C#, Java, C++, etc when it is a string. The first try always starts out as one long string until one understands that it can be formatted in a way that makes it readable.
Dan Sutton wrote:
and in some cases, splitting the line makes it less readable.
Not sure I believe that. But one can certainly reformat a long line in a way that makes it confusing. But that is a formatting problem rather than that the technique itself is flawed. A long line pretty much starts out being difficult to read/understand regardless of how it is formatted. Long lines will have 'parts'. So for example LINQ for a db has a data object, clauses, etc. SQL as a string has the same thing. If you write SQL in a stored proc it can be formatted in the same way. Keep in mind of course that for C#/Java/C++ line breaks are not required. So one can write a method (and even a class) on few or even one line. But very few would claim that is a good idea.
Yes - I understand how to program. But sometimes, it just doesn't make sense to split the line. Often, it does. But not always.