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

51–60 of 83 posts

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

#51

Post by lmm »

mseebach wrote: post #38
lmm wrote: post #24

Earlier quoted context omitted.

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.

I think it does. Carefully maintained manual formatting takes too much programmer effort. If you open a file to actually work on, you should be permitted to hit the autoformat button without thinking, because then formatting becomes something you just don't think about. It's not as good as good manual formatting, but it's good enough, and frees up mental resources for more important things.

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

#52

Post by arethuza »

edw519 wrote: post #42

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.

Wouldn't that rule just end up with people writing:

   FloopTwentySeven
rather than

   Floop27
:-)

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

#53

Post by prof_hobart »

pooop wrote: post #28

The strangest coding standards were imposed when I was working at an AS/400 shop a dozen years ago. No indentation allowed. Even though the modern compilers supported it, it looked ugly to veterans who had worked with fixed-format compilers for 30 years. No comments in the code allowed. The function had to be entirely clear by looking at the code. Any code that needed comments for clarification was considered too 'cl…

> No comments in the code allowed.

That's not necessarily bad advice - at least as a starting point. If you use descriptive variable/function names, then a huge amount of your commenting usually needs go away.

The big advantage is that people are rarely very good at updating comments - at which point they become at best useless and often downright misleading, Whereas most coders will hopefully at least consider renaming a function or a variable when it's no longer accurate.

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

#54

Post by wladimir »

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…

I've seen this mostly as workaround for broken source control systems, along with a change log at the top of each file. For example with ClearCase it can be a hell to find out preceding revisions of a file (the tools are slow and very user unfriendly), actions that are trivial with more modern systems.

I tend to agree more with coding guidelines that go exactly the other way: Do not leave around any commented out or dead code. It breaks the flow of reading the code and can cause confusion as to what is actually happening. If you need to refer to an old state of the code, just provide a commit id in your comment.

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

#55

Post by jacquesm »

dejv wrote: post #3

One company where I worked decade ago have tables numbered, like tbl01_users or tbl14_places. Still have no idea why they establish it this way.

Likely because it tied into a data dictionary from a documentation system.

The tbl01 makes it unique (so you can have a users and someone else can have theirs too), the data dictionary then tells you what fields exist in that particular table and how those fields relate to other tables.

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

#56

Post by Deestan »

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…

There wasn't "the occasional pointless-looking artifact"; I would have been fine with that. 95% of all code comments merely mimicked the type signature. People were using Visual Studio plugins to autogenerate the "documentation". Pressing SHIFT+ALT+J (or something) would read the function name and type signature and regurgutate some XML doc matching it.

> allows extraction of documentation and intellisense.

These already give you type signature and function name. If intellisense already gives you "bool isValid", what possible gains do you get from an extra "boolean value indicating whether the value is valid"?

> I am no drone by any means, but this isn't so insane if you give it some thought.

Trust me, I have given it plenty of thought. Some conclusions from these thoughts:

- Code comments that merely mimic the type signature add nothing. Not for readability, not for intellisense, not for documentation extraction.

- They increase the signal-to-noise ratio of the code immensely, making it harder to read. Comments with actual useful information will now drown in the sea of drivel.

- Fuck it, I'm not working here anymore.

The main fallacy here is that More Process and More Rules can make bad programmers write good code.

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

#57

Post by bruceboughton »

afandian wrote: post #50
bruceboughton wrote: post #47

Earlier quoted context omitted.

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?

Intellisense is generated from the types, methods, fields, and properties (the API). If there is XML documentation it is added to Intellisense popup. If the documentation is auto-generated from the code structure then it will add nothing that is not already present in the Intellisense.

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

#58

Post by bruceboughton »

Deestan wrote: post #56
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…

There wasn't "the occasional pointless-looking artifact"; I would have been fine with that. 95% of all code comments merely mimicked the type signature. People were using Visual Studio plugins to autogenerate the "documentation". Pressing SHIFT+ALT+J (or something) would read the function name and type signature and regurgutate some XML doc matching it. > allows extraction of documentation and intellisense. These alr…

>> Code comments that merely mimic the type signature add nothing. Not for readability, not for intellisense, not for documentation extraction.

Agreed. In fact, over time, they are likely to be not merely useless but harmful as the API signature evolves over time, unless the developer also updates the (pointless) comment.

Post reply on HN