Stupid Programming Standards -- 80 chars?
-
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.
Well, maybe 80 chars max width is a bit narrow minded, but I understand the reluctance to let programmers go wild. Personally, I hate having to scroll horizontally. Drives me nuts! I tend to cut expressions and statements down into several rows. For instance:
FunctionCall(parameter1, parameter2, expression1, expression2, expression3, etc...)
becomes
FunctionCall(
parameter1,
parameter2,
expression1,
expression2,
expression3,
etc...
);But that's just me. I've seen code whose width was measured in hundreds of chars (I'm exaggerating - a little! ;)). Sad sight indeed.
-- Kein Mitleid Für Die Mehrheit
-
Well, maybe 80 chars max width is a bit narrow minded, but I understand the reluctance to let programmers go wild. Personally, I hate having to scroll horizontally. Drives me nuts! I tend to cut expressions and statements down into several rows. For instance:
FunctionCall(parameter1, parameter2, expression1, expression2, expression3, etc...)
becomes
FunctionCall(
parameter1,
parameter2,
expression1,
expression2,
expression3,
etc...
);But that's just me. I've seen code whose width was measured in hundreds of chars (I'm exaggerating - a little! ;)). Sad sight indeed.
-- Kein Mitleid Für Die Mehrheit
I should have clarified. I've never seen lines that went for hundreds of chars, but since C++ does not require CRLF's, the goofballs can go crazy. I typically stay within 120 chars. Sometimes 140 if the code is not all that interesting to the flow. And separating params as you suggest is a good idea, but falls under a different standard.
-
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.
-
Well, maybe 80 chars max width is a bit narrow minded, but I understand the reluctance to let programmers go wild. Personally, I hate having to scroll horizontally. Drives me nuts! I tend to cut expressions and statements down into several rows. For instance:
FunctionCall(parameter1, parameter2, expression1, expression2, expression3, etc...)
becomes
FunctionCall(
parameter1,
parameter2,
expression1,
expression2,
expression3,
etc...
);But that's just me. I've seen code whose width was measured in hundreds of chars (I'm exaggerating - a little! ;)). Sad sight indeed.
-- Kein Mitleid Für Die Mehrheit
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.
-
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.
CurtD wrote:
we still have the 80 char rule (which I completely ignore).
Perhaps you could develop a program that will convert your source code into the 80 line junk they want. A comment such as //F&$@*! symbolizes a new line, the program will scan until it finds the 80th char, add that comment and enter a new line. When you want to edit your code, your program can undo it and remove those comments. Its not quite that simple, but you get the idea.
Word, write letters and sh*t yo.
-
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.
CurtD wrote:
Hell, even the mainframe printers from the 1960's would print 120 chars
aw hell, we could print 132 characters. fyi - the remnants of the 80 position rule still exists in the mainframe world, largely a result of the punch card rule you mention. Mainframe library systems still maintain the 80 position rule but append data to assist the library system maintenance functions.
Mike The NYT - my leftist brochure. Calling an illegal alien an “undocumented immigrant” is like calling a drug dealer an “unlicensed pharmacist”. God doesn't believe in atheists, therefore they don't exist.
-
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.