For those who have not yet stumbled on it, thedailywtf.com is a treasure-store of such golden nuggets.
What was the strangest coding standard rule that you were forced to follow?
31–40 of 83 posts
Re: What was the strangest coding standard rule that you were forced to follow?
#32None were strange. I agreed with all the coding standards I have been forced to follow. The key to not be annoyed by them is to not work at places enforcing stupid standards :)
(
Re: What was the strangest coding standard rule that you were forced to follow?
#33> To NEVER remove any code when making changes. We were told > to comment all changes. I'm afraid given this rule, I would abuse it horribly. My backspace key would no longer function and every typo I make would introduce a new set of /* */ comments. Every refactoring would have the old type, variable, line, function, or entire class commented out with the fixed code alongside it. Bonus points for interleaving the ol…
I understand the rule, we have this rule in place with a caveat. The rule protects us from a few common events, first being that where some developers just love to tinker with code outside the scope of their project. The second is simply a bad design where the results affected other code in unexpected ways.
There have been a few times were code was reverted and having the code merely commented out saved time, time spent cut/pasting from archive. Even with a good CMS keeping commented out code can serve another purpose, knowing what was when and why. That way we can avoid the "well back in year X we had a rule" because we have the code readily accessible.
For large blocks (subroutines/procedures/etc) it is not uncommon to move the whole to the end of the source.
Re: What was the strangest coding standard rule that you were forced to follow?
#34Many answers show a common trend: absurd prefixing rules. They're not only useless, but also counterproductive, because they prevent the incremental searches that are present in so many parts of the development tools.
If you prefix every table name with "tbl", you can't search for them in the DB manager console, the IDE table listing, a directory list of the creation scripts, etc.
I suffered an extreme version of this: there was some prefix that was also the directory name. So the files were called "prefix/prefixBlah". Also the prefix was used as class name and the fields were also prefixed with it.
The result was that a reference could become "prefix/prefixBlah/prefixBlah.prefixDoh", an awful noise to signal rate.
I complained without success. That way was "a lot more orderly and tidy" .
Re: What was the strangest coding standard rule that you were forced to follow?
#35Earlier quoted context omitted.
I know a solution: Agree on the broad points of formatting - ie. tabs/spaces, where the braces generally go. Make engaging in formatting battles a firing offense, but listen to anyone who can make substantial arguments in favour of a practise. Automatic reformatting is evil - sometimes codes is more readable if formatted in a particular way. Readability and maintainability always trumps adhering to rules.
I guess what Im saying is if you could have a tool that could compare 2 pieces of source code, be able to merge them, and maintain the formatting of each persons local copy it would be great. Its probably a pipe dream because your version control would have to have an intimate knowledge of the specs of any particular language used in the source code (nevermind the version of the language you are using)
Yes, for merging, that would be incredibly helpful.
But what I'm saying is that the formatting of a file may contain contextual clues that will help someone reading the code to understand what it does. Formatting isn't just chrome around the code.
Example: In Java, when writing a custom predicate to filter by foos that are bars, I prefer
filter(myList, new Predicate() {
@Override public boolean apply(Foo foo) { return foo.isBar(); } });
filter(myList, new Predicate() {
@Override
public boolean apply(Foo foo) {
return foo.isBar();
}
});
especially when there are multiple of them and they line up neatly underneath each other.
Any meaningful autoformatter would change the latter to the former, and in the process loose readability.
EDIT: Another example would be when using the builder pattern - getting those methods to line up to be neatly readable often takes some none-standard indentation.
Re: What was the strangest coding standard rule that you were forced to follow?
#36In my first job out from school I worked with a bunch of ex COBOL programmers who were re-writing the system in this new-fangled language called "C".
One convention was that all "procedures" should be prefixed with a name indicating where they were in the call graph of the program.
So the main method was always:
int main()
{
a_initialize();
b_process();
c_shutdown();
}
void a_initialize()
{
aa_connect_database();
ab_read_accounts();
ac_read_ledger();
...
}
Of course, sometimes you had to write a function that had to be called from more than one place (strange I know!!)
For this, the naming convention "pzzDDDD" was used where D was a digit from 0-9. "p" for procedure and "zz" because these functions didn't belong to any one place in the hierarchy.
We had a print out of the "pzz"s because just the number was hard to remember. But I can still remember a few of them:
* pzz0030 was for looking up account information from the database (but also for maintaining this information).
* pzz0031 for contracts
* pzz0241 I think was for looking up fees and commissions.
Most of the "functions" had lots of parameters so that they could do different things (modify, update, delete accounts etc.). This soon became unwieldy so eventually you had:
* pzz0241_a_setupcharges()
* pzz0241_c_cleanup()
or something. I forget the details for this last bit.
This was in 1997.
Neat huh? ;-)
Re: What was the strangest coding standard rule that you were forced to follow?
#37> To NEVER remove any code when making changes. We were told > to comment all changes. I'm afraid given this rule, I would abuse it horribly. My backspace key would no longer function and every typo I make would introduce a new set of /* */ comments. Every refactoring would have the old type, variable, line, function, or entire class commented out with the fixed code alongside it. Bonus points for interleaving the ol…
I understand the rule, we have this rule in place with a caveat. The rule protects us from a few common events, first being that where some developers just love to tinker with code outside the scope of their project. The second is simply a bad design where the results affected other code in unexpected ways. There have been a few times were code was reverted and having the code merely commented out saved time, time sp…
"saved time, time spent cut/pasting from archive"
Surely source control would be a nicer way than copy/pasting old code back in?
Re: What was the strangest coding standard rule that you were forced to follow?
#38Earlier quoted context omitted.
I know a solution: Agree on the broad points of formatting - ie. tabs/spaces, where the braces generally go. Make engaging in formatting battles a firing offense, but listen to anyone who can make substantial arguments in favour of a practise. Automatic reformatting is evil - sometimes codes is more readable if formatted in a particular way. Readability and maintainability always trumps adhering to rules.
Automatic reformatting is the only solution, because you want to be able to make unreadable code readable without conscious effort. My preferred policy would be something like: 1. There is an agreed autoformatting template, checked into version control. 2. It is always ok to format the lines you are working on however you like, with the understanding that other people may run the autoformatter on the file. 3. It is a…
I mostly agree, although I'd like to enhance the bit in point 3 and 4 about only ever reformatting code you're actually working on - meaning, you take responsibility for any code that your autoformatter changes is just as readable as before.
Changing the name of a constant on line three doesn't give you license to autoformat the rest of the file.
Re: What was the strangest coding standard rule that you were forced to follow?
#39Earlier quoted context omitted.
I'm not sure what you're referring to, but in all instances of Hungarian notation I've seen (especially in Windows programs) it was the data type (pointer to char, 8 bit int, 32 bit int etc) encoded and not "the nature of the thing". I agree that adding the "nature of the thing being counted" makes sense, but then you don't have to call it Hungarian notation anymore, "number_of_apples" is just a sensible variable nam…
Joel Spolsky wrote a good summary about the Hungarian notation, and how it got corrupted within Microsoft: http://www.joelonsoftware.com/articles/Wrong.html
Thanks for the explanation. The original idea was pretty good.
But I've only, ever, seen the corrupted variant in the wild. And coding standards that enforce it. Hence my annoyance.
Re: What was the strangest coding standard rule that you were forced to follow?
#40Earlier quoted context omitted.
so I would have something on L249 and you would have it on L321? nonsense.
Yeah, you'd likely need some other way to refer so a position in the code than the line number. Maybe an anchor (like html) or a path in the syntax tree.
These tools already exist: JavaScript tools like minfiers or CoffeeScript can generate source maps which map code lines from one format to code lines in another format.
http://www.html5rocks.com/en/tutorials/developertools/source...