No your line is too long.
-
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.