Stupid Programming Standards -- 80 chars?
-
See, while I disagree with this as a requirement, 99% of my functions do have only one return statement, it is a good principle to aim for, what's wrong is when it becomes a hard and fast rule and you have to write code around the rule.
Christian Graus - Microsoft MVP - C++ "also I don't think "TranslateOneToTwoBillion OneHundredAndFortySevenMillion FourHundredAndEightyThreeThousand SixHundredAndFortySeven()" is a very good choice for a function name" - SpacixOne ( offering help to someone who really needed it ) ( spaces added for the benefit of people running at < 1280x1024 )
-
See, while I disagree with this as a requirement, 99% of my functions do have only one return statement, it is a good principle to aim for, what's wrong is when it becomes a hard and fast rule and you have to write code around the rule.
Christian Graus - Microsoft MVP - C++ "also I don't think "TranslateOneToTwoBillion OneHundredAndFortySevenMillion FourHundredAndEightyThreeThousand SixHundredAndFortySeven()" is a very good choice for a function name" - SpacixOne ( offering help to someone who really needed it ) ( spaces added for the benefit of people running at < 1280x1024 )
Christian Graus wrote:
See, while I disagree with this as a requirement, 99% of my functions do have only one return statement, it is a good principle to aim for, what's wrong is when it becomes a hard and fast rule and you have to write code around the rule.
What I really disliked about this rule was code that should look like this void Function(int param) { if(param < 0) return; //lots more code } now becomes void Function(int param) { if(param >= 0) { //lots of code } //nothing here } I found that often the "real work" of the function would be many levels of indentation deep
-
As a contractor/consultant, I have worked in a lot of places over 25 years. Without fail, everyone of them has had a rule that source code should not exceed 80 chars per line. I've always asked if this is because they are backing everything up to punched cards. Back in the Win 3.1 days, they would tell me that there was always some asshole who used DOS edit (or even edlin) for writing code. I always thought this was a good reason to suggest that they pursue another career. Now in the VS 2005 IDE, with my widescreen monitor, even with some toolbars added to the sides, 80 chars doesn't even go half way across my screen. And yet, we still have the 80 char rule (which I completely ignore). Hell, even the mainframe printers from the 1960's would print 120 chars (I think -- that was a lot of beers ago, but I know it was > 80). If you are still writing code in an 80 char mode editor or using a dot matrix printer, there are plenty of jobs at McDonalds (or the Smithsonian perhaps). People need to stop blindly following rules that make no sense. This is an especially bad problem with computer nerds. If no one can explain why a rule exists, then get rid of it and ignore it until someone does.
-
As a contractor/consultant, I have worked in a lot of places over 25 years. Without fail, everyone of them has had a rule that source code should not exceed 80 chars per line. I've always asked if this is because they are backing everything up to punched cards. Back in the Win 3.1 days, they would tell me that there was always some asshole who used DOS edit (or even edlin) for writing code. I always thought this was a good reason to suggest that they pursue another career. Now in the VS 2005 IDE, with my widescreen monitor, even with some toolbars added to the sides, 80 chars doesn't even go half way across my screen. And yet, we still have the 80 char rule (which I completely ignore). Hell, even the mainframe printers from the 1960's would print 120 chars (I think -- that was a lot of beers ago, but I know it was > 80). If you are still writing code in an 80 char mode editor or using a dot matrix printer, there are plenty of jobs at McDonalds (or the Smithsonian perhaps). People need to stop blindly following rules that make no sense. This is an especially bad problem with computer nerds. If no one can explain why a rule exists, then get rid of it and ignore it until someone does.
-
I just love those JavaScripter's that like to remove all whitespace as a cheap form of obfuscation.
Try code model generation tools at BoneSoft.com.
-
Christian Graus wrote:
See, while I disagree with this as a requirement, 99% of my functions do have only one return statement, it is a good principle to aim for, what's wrong is when it becomes a hard and fast rule and you have to write code around the rule.
What I really disliked about this rule was code that should look like this void Function(int param) { if(param < 0) return; //lots more code } now becomes void Function(int param) { if(param >= 0) { //lots of code } //nothing here } I found that often the "real work" of the function would be many levels of indentation deep
-
As a contractor/consultant, I have worked in a lot of places over 25 years. Without fail, everyone of them has had a rule that source code should not exceed 80 chars per line. I've always asked if this is because they are backing everything up to punched cards. Back in the Win 3.1 days, they would tell me that there was always some asshole who used DOS edit (or even edlin) for writing code. I always thought this was a good reason to suggest that they pursue another career. Now in the VS 2005 IDE, with my widescreen monitor, even with some toolbars added to the sides, 80 chars doesn't even go half way across my screen. And yet, we still have the 80 char rule (which I completely ignore). Hell, even the mainframe printers from the 1960's would print 120 chars (I think -- that was a lot of beers ago, but I know it was > 80). If you are still writing code in an 80 char mode editor or using a dot matrix printer, there are plenty of jobs at McDonalds (or the Smithsonian perhaps). People need to stop blindly following rules that make no sense. This is an especially bad problem with computer nerds. If no one can explain why a rule exists, then get rid of it and ignore it until someone does.
I set up VS to draw guidelines at 80 and 120 chars. I stop at or around 80 for comments, and try to stay below 120 for code. Generally, this keeps it easy to read - i don't care how wide your screen is, i doubt your field of vision is really wide enough to take in much more than that without a lot of left-right scanning. And, i do like to print out code now and then, without having to wrap lines or shrink the font down.
-
As a contractor/consultant, I have worked in a lot of places over 25 years. Without fail, everyone of them has had a rule that source code should not exceed 80 chars per line. I've always asked if this is because they are backing everything up to punched cards. Back in the Win 3.1 days, they would tell me that there was always some asshole who used DOS edit (or even edlin) for writing code. I always thought this was a good reason to suggest that they pursue another career. Now in the VS 2005 IDE, with my widescreen monitor, even with some toolbars added to the sides, 80 chars doesn't even go half way across my screen. And yet, we still have the 80 char rule (which I completely ignore). Hell, even the mainframe printers from the 1960's would print 120 chars (I think -- that was a lot of beers ago, but I know it was > 80). If you are still writing code in an 80 char mode editor or using a dot matrix printer, there are plenty of jobs at McDonalds (or the Smithsonian perhaps). People need to stop blindly following rules that make no sense. This is an especially bad problem with computer nerds. If no one can explain why a rule exists, then get rid of it and ignore it until someone does.
We don't have that rule here... :-) Feel free to apply :laugh:
V.
Stop smoking so you can: Enjoy longer the money you save. Moviereview Archive -
As a contractor/consultant, I have worked in a lot of places over 25 years. Without fail, everyone of them has had a rule that source code should not exceed 80 chars per line. I've always asked if this is because they are backing everything up to punched cards. Back in the Win 3.1 days, they would tell me that there was always some asshole who used DOS edit (or even edlin) for writing code. I always thought this was a good reason to suggest that they pursue another career. Now in the VS 2005 IDE, with my widescreen monitor, even with some toolbars added to the sides, 80 chars doesn't even go half way across my screen. And yet, we still have the 80 char rule (which I completely ignore). Hell, even the mainframe printers from the 1960's would print 120 chars (I think -- that was a lot of beers ago, but I know it was > 80). If you are still writing code in an 80 char mode editor or using a dot matrix printer, there are plenty of jobs at McDonalds (or the Smithsonian perhaps). People need to stop blindly following rules that make no sense. This is an especially bad problem with computer nerds. If no one can explain why a rule exists, then get rid of it and ignore it until someone does.
You need a limit somewhere - I agree that a hard limit of 80 is a little low, but I'm working with a code generation tool at the moment - it generates some lines of with more than 400 characters - that's a bit on the long side :-) Looking at *my* code, my hard limit seems to be about 150 characters, but I try to use multi-line and indentation if a statement goes over about 100 characters. I just try and make the code reasonably readable, without unnecessarily fragmented lines.
-
Exactly. It's a good guideline, in that returns deep in the bowels of the code just make it harder to follow... but common sense dictates there is a time and a place for just getting the hell out of a function now.
Especially from the function dodge() ;)
-- Kein Mitleid Für Die Mehrheit
-
Christian Graus wrote:
See, while I disagree with this as a requirement, 99% of my functions do have only one return statement, it is a good principle to aim for, what's wrong is when it becomes a hard and fast rule and you have to write code around the rule.
What I really disliked about this rule was code that should look like this void Function(int param) { if(param < 0) return; //lots more code } now becomes void Function(int param) { if(param >= 0) { //lots of code } //nothing here } I found that often the "real work" of the function would be many levels of indentation deep
the defensive coding against that sort of standard is to move all the validation into a separate function, so that you only have level of indent. bool FooValidator(...) { bool retVal = true; reval &= cond1; reval &= cond2; ... return retVal; } void Foo(...) { if (ValidateFoo(..)) { ... } }
-
I set up VS to draw guidelines at 80 and 120 chars. I stop at or around 80 for comments, and try to stay below 120 for code. Generally, this keeps it easy to read - i don't care how wide your screen is, i doubt your field of vision is really wide enough to take in much more than that without a lot of left-right scanning. And, i do like to print out code now and then, without having to wrap lines or shrink the font down.
-
Where is that option at?
-- Join the Campaign to Help Stamp Out and Abolish Redundancy The preceding is courtesy of the Bureau of Unnecessarily Redundant Repetition Department.