Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What was the strangest coding standard rule that you were forced to follow?

stackoverflow.com

Post reply on HN
Print view View original

41–50 of 83 posts

Re: What was the strangest coding standard rule that you were forced to follow?

#41

Post by drothlis »

wladimir wrote: post #20
moocow01 wrote: post #11

Maybe someone knows of a solution but it would be great if SVN/version control was able to store a standard formatted version of source code and then depending on client/user preferences could reformat the file accordingly on checkout and then also be able to factor in / unformat when doing diffs/checkins. I feel like if it could work like this it would mitigate a lot the inevitable battles that take place over small…

What I've always found an intriguing idea is to store the abstract semantic graph of the program instead of (just) the text of the program in the revision control system. The source code could then be formatted / visualized in any way for the programmer while manipulating it. Kind of like a TeX, or CSS, but for source code. And I suppose it could also help with making sensible diffs, no longer need to be annoyed by a…

"A language should be designed in terms of an abstract syntax and it should have, perhaps, several forms of concrete syntax: One which is easy to write and maybe quite abbreviated; another which is good to look at and maybe quite fancy, but after all, the computer is going to produce it; and another, which is easy to make computers manipulate."

--John McCarthy, http://www.infoq.com/interviews/Steele-Interviews-John-McCar...

Re: What was the strangest coding standard rule that you were forced to follow?

#42

Post by edw519 »

No numerics permitted in function names.

Theory: It's prettier.

Reality: Just try to understand the hierarchical relationship between 247 functions in a 10,000 line Material Requirements Planning module of an ERP system when every function name must be all alpha.

Re: What was the strangest coding standard rule that you were forced to follow?

#43

Post by ygra »

moocow01 wrote: post #11

Maybe someone knows of a solution but it would be great if SVN/version control was able to store a standard formatted version of source code and then depending on client/user preferences could reformat the file accordingly on checkout and then also be able to factor in / unformat when doing diffs/checkins. I feel like if it could work like this it would mitigate a lot the inevitable battles that take place over small…

This won't work, except for trivial codebases, I guess. Dean Whelton argued a similar thing once [1]. There are always things that resist automated formatting or that are downright destroyed when using it. I use Ctrl+Shift+F or Ctrl+E,D sparingly for that reason. Eclipse has a tendency to mangle Javadoc comments sometimes. Sometimes you're breaking a long method invocation or formula over multiple lines for readability and not exactly at the 80-char boundary, etc.

Of course, trivial things like braces on the same or next line or whitespace around operators are solvable that way, but in general, as long as source code is text (and it will remain that way for quite some time). What perpetuates this state is obviously that we have lots of tools that deal with text and very few that deal with more specialised content. In general I find this sad, though, as text is often neither easiest to work with nor most expressive, despite of what diehard Unix users say.

What would be really lovely in my eyes woul be a source control tool that actually understood its content and could say "order of parameters of that function was changed" or "method added", etc. It's sometimes astonishing how the pursuit of optimal diffs masks the intent of a change where an added method diff starts with the closing brace of the previous method, for example.

[1]: http://welbog.homeip.net/glue/71/Whitespace_is_not_a_problem

Re: What was the strangest coding standard rule that you were forced to follow?

#44

Post by nwatson »

moocow01 wrote: post #11

Maybe someone knows of a solution but it would be great if SVN/version control was able to store a standard formatted version of source code and then depending on client/user preferences could reformat the file accordingly on checkout and then also be able to factor in / unformat when doing diffs/checkins. I feel like if it could work like this it would mitigate a lot the inevitable battles that take place over small…

Eclipse has pretty good code-formatting control for Java, quite customizable. It's very nice in that:

  * you can elect to turn off formatting for sections of your code
  * you can save/export your formatting convention in an XML file that looks like this: http://pastebin.com/fKjKRuZg
  * you can import that code convention into new/other projects
  * you can select any number of files or projects and choose to apply the formatting to the Java source
  * the result is very readable
This might not tie in directly to your source control tool as is but would make taming and standardizing source from multiple developers a bit easier. As long as every contributor's code eventually is coerced into this form your own/central copy can easily be diff'ed across versions. Also, you could apply other conventions with other formatters for clients that see things differently.

Re: What was the strangest coding standard rule that you were forced to follow?

#45

Post by afandian »

Deestan wrote: post #26

Not so much strange, as Twilight Zone-esque insane: All methods and properties must be commented with XML . Sounds like a good idea, until you see how this turns terse and readable code into a bag of chatty noise. Basically this: public enum ConnectionState { Disconnected, Connecting, Connected } Was not compliant ("There's no comments! It's not readable!"), while this: /// /// The Connection State. /// public enum C…

I too was forced to do that. I too found it ridiculous. But not for long. There was a utility for generating the documentation strings (it got them right most of the time) and there's a lot to be said for consistency, even if it produces the occasional pointless-looking artefact. The reason this requirement is in the C# style guidelines is because it gives a consistent way of commenting and, of course, allows extraction of documentation and intellisense. I am no drone by any means, but this isn't so insane if you give it some thought.

Re: What was the strangest coding standard rule that you were forced to follow?

#46

Post by bruceboughton »

Shivetya wrote: post #33
biot wrote: post #17

> 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…

>> Even with a good CMS keeping commented out code can serve another purpose [..]

This, here, is your problem.

Re: What was the strangest coding standard rule that you were forced to follow?

#47

Post by bruceboughton »

afandian wrote: post #45
Deestan wrote: post #26

Not so much strange, as Twilight Zone-esque insane: All methods and properties must be commented with XML . Sounds like a good idea, until you see how this turns terse and readable code into a bag of chatty noise. Basically this: public enum ConnectionState { Disconnected, Connecting, Connected } Was not compliant ("There's no comments! It's not readable!"), while this: /// /// The Connection State. /// public enum C…

I too was forced to do that. I too found it ridiculous. But not for long. There was a utility for generating the documentation strings (it got them right most of the time) and there's a lot to be said for consistency, even if it produces the occasional pointless-looking artefact. The reason this requirement is in the C# style guidelines is because it gives a consistent way of commenting and, of course, allows extract…

If you're using auto-doc-generation, there is no information in the generated documentation that isn't in the API.

Re: What was the strangest coding standard rule that you were forced to follow?

#48

Post by unimpressive »

panacea wrote: post #32
mrb wrote: post #12

None 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 :)

(

Is there something clever I'm missing here?

Re: What was the strangest coding standard rule that you were forced to follow?

#49

Post by d4nt »

I've come to believe that coding standards always end up being either too simplistic to deal with every scenario or longer and just an inferior in-house implementation of Steve McConnell's "Code Complete". Either way you're wasting your time.

Style guides are ok though, so long as they're short and not enforced too bluntly.

Re: What was the strangest coding standard rule that you were forced to follow?

#50

Post by afandian »

bruceboughton wrote: post #47
afandian wrote: post #45

Earlier quoted context omitted.

I too was forced to do that. I too found it ridiculous. But not for long. There was a utility for generating the documentation strings (it got them right most of the time) and there's a lot to be said for consistency, even if it produces the occasional pointless-looking artefact. The reason this requirement is in the C# style guidelines is because it gives a consistent way of commenting and, of course, allows extract…

If you're using auto-doc-generation, there is no information in the generated documentation that isn't in the API.

Not sure what you mean by "the API". You mean C# interfaces? And what about Intellisense?
Post reply on HN