|
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.
|
|
|
|
|
Not just no but hell no!
As the aircraft designer said, "Simplicate and add lightness".
PartsBin an Electronics Part Organizer - Release Version 1.3.0 JaxCoder.com
Latest Article: SimpleWizardUpdate
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
Obviously, this person has never seen how Microsoft writes long lines. For example,
HRESULT Scene::CreateDeviceDependentResources()
{
HRESULT hr = m_pRenderTarget->CreateSolidColorBrush(
D2D1::ColorF(1.0f, 1.0f, 0),
D2D1::BrushProperties(),
&m_pFill
);
if (SUCCEEDED(hr))
{
hr = m_pRenderTarget->CreateSolidColorBrush(
D2D1::ColorF(0, 0, 0),
D2D1::BrushProperties(),
&m_pStroke
);
}
return hr;
}
|
|
|
|
|
I have zero problem with that.
In fact, I'd much rather see a function's parameters being broken by parameter (one per line) rather than 3 on the first line, 2 on the second line, then 4 on the third line, etc. If it has to be broken down, go all the way.
Then if a parameter consists of a function call, and that function needs so many parameters of its own that that line becomes long, then break it into multiple lines too, with an extra indentation level.
Seems so logical to me.
|
|
|
|
|
dandy72 wrote: rather than 3 on the first line, 2 on the second line ...
Same for me.
|
|
|
|
|
I can understand the motivation. I've seen, and perhaps perpetrated, something like:
string someString = mything.something().somethingElse().foo().bar().bang().whiz().toString() Which can sometimes lead to very long lines. But any decent optimizer should be able to elide otherwise unused intermediate object so maybe
auto something = mything.something();
auto foobar = something().foo().bar();
auto whiz = foobar().bang().whiz();
string someString = whiz.toString(); is preferable?
But if you're going to keep the long version as a single statement, but write it over separate lines do you prefer putting the . at the end or the start of the line? e.g
mything.something().
foo().bar().whiz().
bang().toString()
vs
mything.something()
.foo().bar().whiz()
.bang().toString()
"A little song, a little dance, a little seltzer down your pants"
Chuckles the clown
|
|
|
|
|
I find that dots and commas and such are easier to see at the start of a line.
I put commas and binary operators (not dots) on their own lines in many cases so they really stand out.
|
|
|
|
|
string someString = mything
.something()
.somethingElse()
.foo()
.bar()
.bang()
.whiz()
.toString()
;
|
|
|
|
|
I like that look.
I try to write my SQL like that but have been leaving the dot-separators on the previous line in code. My thinking was to indicate that the line (command) was not yet finished.
With this style, keeping each line short it is clear that each line is a continuation.
With SQL, I have been cheating on that style to keep like fields on a single line:
...
, fKey
, LastName, FirstName, MidName
, AddrLine1, AddrLine2, City, State, Country, Zip
--, foo
, bar
...
|
|
|
|
|
bryanren wrote: SQL like that but have been leaving the dot-separators on the previous line in code.
lol ...
Really not obvious to me what you meant until I got to your example. I was crunching my brain trying to find when one would have multiple periods.
Yes I use exactly that form for SQL also.
Unlike with other expressions and even with parameters in C#/Java I still tend (always?) to put the comma at the end of the line rather than the beginning.
No real reason although I could state that a comma is not part of an expression.
But then I do it that way for SQL. So no way I can justify it.
|
|
|
|
|
k5054 wrote: do you prefer putting the . at the end or the start of the line?
Beginning.
Makes it visually obvious when skimming that it is part of a preceding expression.
|
|
|
|
|
My first job was in an age where graphic terminals were just starting to appear. My employer were designing a screen management library, primarily oriented towards screens with a resolution of 80 by 25 characters. Yet, we wanted the library to be prepared for the graphics of the future.
We had a brainstorming to provide input to the requirements spec, coming up with a proposal where the screen could be filled by a sphere. On this globe, you could allocate several virtual screens, as a sector of a given number of degrees from pole to pole. Each virtual screen (i.e. sector) could scroll independently of the others, and you could spin the globe to bring a specific screen towards you. We never agreed which would be the better default: Either, to clip the contents to the 'longitude' edges of the virtual screen (so that you would have to scroll a line to the middle to see its full length), or to scale down towards the poles (so that you would have to scroll to see a line in maximum size).
For some reason, this solution has never been realized (to my knowledge). I am quite sure that it would be possible with Linux and this screen driver. There must be someone who thinks that this is a great idea.
(In case you wonder: We were not dead serious about it - it was in the same class as 'esoteric' programming languages such as brainfuck or whitespace.)
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
Get a bigger monitor? Learn how to use a line continuation character maybe? (depending on language options)
The only really long lines I ever have are sql queries. In the past, I used to insist on keeping the Select From Group By, and Order By on individual lines and concatenate. Nowadays, I either use line continuations or a string builder to keep everything visible. (horizontally)
"Go forth into the source" - Neal Morse
"Hope is contagious"
|
|
|
|
|
When our coding standards were revised, the working group proposed to limit line lengths 72 characters of code.
Our project manager immediately granted an exemption to this rule: We also had rules for how to make up names for #define constants (identifying module, submodule, function etc. etc.) that resulted in constant names exceeding 80 chars.
(Personally, I think that rules that can lead to such results are completely crazy. There are also rules for how to name directories, subdirectories, sub-sub and sub-sub-sub-... directories, so that any directory should be 'self-identifying' even if located in an identifying higher directory. In one case, I counted the same module ID repeated seven times in a complete path string. This naming standard obviously created problems for DOS-friendly file systems with a maximum path length of 260 characters. Even if that 260 char limit sometimes was a pain in the horse, I think that naming rules frequently leading to path strings filling several lines of output are just as crazy!)
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
Well, the fact that only Linux supports diagonal orientation says something about the person wanting diagonal orientation.
"Too busy seeing if they COULD do it to be bothered with whether they SHOULD do it."
I’ve given up trying to be calm. However, I am open to feeling slightly less agitated.
I’m begging you for the benefit of everyone, don’t be STUPID.
|
|
|
|
|
In Norwegian slang, 'slanted' is a term for homosexual.
Are you referring to something like that? I wasn't aware of any similar slang term in English.
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
No, I meant the actual tilted monitor.
Some Linux users are elitist looking down their noses at other operating systems, so being able to have a tilted monitor could be another example.
I’ve given up trying to be calm. However, I am open to feeling slightly less agitated.
I’m begging you for the benefit of everyone, don’t be STUPID.
|
|
|
|
|
OK, I certainly follow your line of thought!
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
They think they're looking down, but they are actually looking up.
|
|
|
|
|
MarkTJohnson wrote: Some Linux users are elitist
Not sure I have seen a technology yet where someone would not claim that theirs was better.
And they always sputter when I ask what objective criteria they have for that.
|
|
|
|
|
I hate long lines.
On the show Supernatural the acting head of hell (Satan was otherwise locked up) decided that since inevitably some people enjoyed the various tortures dished out that he would make everyone stand in line for eternity.
"Nobody likes waiting in line"
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
honey the codewitch wrote: I hate long lines.
So you prefer macaroni to spaghetti? 
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
