If you don’t add comments, even rudimentary ones, or you don’t use a naming convention that accurately describes the variables or the functions, you’re a bad programmer. It doesn’t matter if you know what it does now, just wait until you need to know what it does in 6 months and you have to stop what you’re doing an decipher it.
Self documenting code is infinitely more valuable than comments because then code spreads with it’s use, whereas the comments stay behind.
I got roasted at my company when I first joined because my naming conventions are a little extra. That lasted for about 2 months before people started to see the difference in legibility as the code started to change.
One of the things I tell my juniors is, “this isn’t the 80s. There isn’t an 80 character line limit. The computer doesn’t benefit from your short variable names. I should be able to read most lines of code as a single non-compound sentence in English with only minor tweaks and the English sentence should be what is happening in most of those lines of code.”
80 character limit is helpful though when you need to have many files open at a time. Maybe 100 is more reasonable. Fighting indentation is important too.
I, too, remember the days before ultra high definition ultra wide monitors.
I thought this argument was bogus in the 90s on a 21" CRT and the argument has gotten even less valid since then. There are so many solutions to these problems that increase productivity for paltry sums of money it’s insane to me that companies don’t immediately purchase these for all developers.
You have a point, devs should be using multiple large monitors. I will often need to have 3-4 files open at once, plus some browser windows. Having some limit on line length helps with this and for fighting code complexity.
The most important thing is comprehension. If something is too long and the length makes it less readable then it is too long.
But if having 3-4 files open at the same time makes it harder for you to comprehend a single file because you can’t get the full picture, that’s on you.
I have a massive ultrawide and I still 100% believe in line limits. Long lines are harder to read in general but even with a limit of 100 I frequently have 3 files opened next to each other and I can’t read entire lines easily. Line limits just aren’t about the size of the monitor and I can’t believe people still say that.
I understand the concern, but readability and comprehension are way more important than line length. If the length impairs readability, it’s too long. Explicitly limits are terrible. Guidelines, fine.
Ultimately, you do you. I still think your crazy and I think your argument is poor.
Yes a strict 80 character limit would be bad but that’s why modern formatters aren’t strict and default to 90-100.
I’ve pretty much never seen code that would have been more readable had the lines been longer than that.
My main argument is still that shorter lines are more readable. I just think it’s a bullshit argument to say that long lines are fine because large monitors exists. I don’t see how that makes me crazy.
See, I think length limits and readability are sometimes at odds. To say that you 100% believe in length limits means that you would prefer the length limit over a readable line of code in those situations.
I agree that shorter lines are often more readable. I also think artificial limits on length are crazy. Guidelines, fine. Verbosity for the sake of verbosity isn’t valuable… But to say never is a huge stretch. There are always those weird edge cases that everyone hates.
We can agree on “not all situations”. Often the answer to “why did we do it this way?” is blazingly obvious, and no one wants a comment.
But we all know that sometimes the “why” isn’t obnoxious at all.
As far as I can tell, developers who do believe in self-documenting code either haven’t learned the power of “why?”, or they have a secret technique for encoding “why?” into their code structure.
If it’s the second thing, I would be delighted to be brought in on it. (No sarcasm. Maybe I’ve missed a trick here.)
This is why code review exists. Writer’s can’t always see what’s wrong with their work, because they have the bias of knowing what was intended. You need a reader to see it with fresh eyes and tell you what parts are confusing.
That’s not to say you shouldn’t try to make it readable in the first place. But reviewing and reading other people’s code is how you get better.
Let’s take this one step further. I should be able to get the core ideas in your code by comments and cs 101 level coding (eg basic data structures, loops, and if/then).
If you don’t add comments, even rudimentary ones, or you don’t use a naming convention that accurately describes the variables or the functions, you’re a bad programmer. It doesn’t matter if you know what it does now, just wait until you need to know what it does in 6 months and you have to stop what you’re doing an decipher it.
However, engineers who rely solely on comments to explain their code, are bad at writing readable code.
Possibly, but I’d prefer this scenario over the other.
If I don’t know what it does now my comment of “I have no idea wtf this does” won’t help me in 6 months.
Apparently, I’ve debugged your code.
Self documenting code is infinitely more valuable than comments because then code spreads with it’s use, whereas the comments stay behind.
I got roasted at my company when I first joined because my naming conventions are a little extra. That lasted for about 2 months before people started to see the difference in legibility as the code started to change.
One of the things I tell my juniors is, “this isn’t the 80s. There isn’t an 80 character line limit. The computer doesn’t benefit from your short variable names. I should be able to read most lines of code as a single non-compound sentence in English with only minor tweaks and the English sentence should be what is happening in most of those lines of code.”
Absolutely agree, yeah
80 character limit is helpful though when you need to have many files open at a time. Maybe 100 is more reasonable. Fighting indentation is important too.
I, too, remember the days before ultra high definition ultra wide monitors.
I thought this argument was bogus in the 90s on a 21" CRT and the argument has gotten even less valid since then. There are so many solutions to these problems that increase productivity for paltry sums of money it’s insane to me that companies don’t immediately purchase these for all developers.
You have a point, devs should be using multiple large monitors. I will often need to have 3-4 files open at once, plus some browser windows. Having some limit on line length helps with this and for fighting code complexity.
The most important thing is comprehension. If something is too long and the length makes it less readable then it is too long.
But if having 3-4 files open at the same time makes it harder for you to comprehend a single file because you can’t get the full picture, that’s on you.
I have a massive ultrawide and I still 100% believe in line limits. Long lines are harder to read in general but even with a limit of 100 I frequently have 3 files opened next to each other and I can’t read entire lines easily. Line limits just aren’t about the size of the monitor and I can’t believe people still say that.
I understand the concern, but readability and comprehension are way more important than line length. If the length impairs readability, it’s too long. Explicitly limits are terrible. Guidelines, fine.
Ultimately, you do you. I still think your crazy and I think your argument is poor.
Yes a strict 80 character limit would be bad but that’s why modern formatters aren’t strict and default to 90-100.
I’ve pretty much never seen code that would have been more readable had the lines been longer than that.
My main argument is still that shorter lines are more readable. I just think it’s a bullshit argument to say that long lines are fine because large monitors exists. I don’t see how that makes me crazy.
See, I think length limits and readability are sometimes at odds. To say that you 100% believe in length limits means that you would prefer the length limit over a readable line of code in those situations.
I agree that shorter lines are often more readable. I also think artificial limits on length are crazy. Guidelines, fine. Verbosity for the sake of verbosity isn’t valuable… But to say never is a huge stretch. There are always those weird edge cases that everyone hates.
There’s no such thing as self documenting code, unless every method and variable name has the word “because” in it.
Anyone can read what the code does. The comments are there to answer why it does what it does the way it does.
Why is invariably lost to time, if it’s not committed to a comment here and there.
This is a pretty ridiculous position to take but if you believe it then I’m glad you write the comments you do.
There is an argument that commenting on the lack of expected code is valuable for this reason, but it certainly isn’t true in all situations.
We can agree on “not all situations”. Often the answer to “why did we do it this way?” is blazingly obvious, and no one wants a comment.
But we all know that sometimes the “why” isn’t obnoxious at all.
As far as I can tell, developers who do believe in self-documenting code either haven’t learned the power of “why?”, or they have a secret technique for encoding “why?” into their code structure.
If it’s the second thing, I would be delighted to be brought in on it. (No sarcasm. Maybe I’ve missed a trick here.)
This is why code review exists. Writer’s can’t always see what’s wrong with their work, because they have the bias of knowing what was intended. You need a reader to see it with fresh eyes and tell you what parts are confusing.
That’s not to say you shouldn’t try to make it readable in the first place. But reviewing and reading other people’s code is how you get better.
Let’s take this one step further. I should be able to get the core ideas in your code by comments and cs 101 level coding (eg basic data structures, loops, and if/then).