
What was the strangest coding standard rule that you were forced to follow? - leak
http://stackoverflow.com/questions/218123/what-was-the-strangest-coding-standard-rule-that-you-were-forced-to-follow
======
Patient0
In 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();
        }
    

The first function called by a_initialize had to be called "aa_", then "ab_"
and so on:

    
    
        void a_initialize()
        {
            aa_connect_database();
            ab_read_accounts();
            ac_read_ledger();
            ...
        }
    
    

and so on.

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? ;-)

------
Deestan
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:

    
    
        /// <summary>
        /// The Connection State.
        /// </summary>
        public enum ConnectionState {
            /// <summary>
            /// The Connected State.
            /// </summary>
            Connected,
    
            /// <summary>
            /// The Disconnected State.
            /// </summary>
            Disconnected,
    
            /// <summary>
            /// The Connecting State.
            /// </summary>
            Connecting
        }
    

Was considered Compliant and Good. This example has not been simplified, by
the way.

~~~
afandian
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.

~~~
Deestan
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.

~~~
afandian
Fair enough. I found that in a collaborative environment (people making and
sharing code) the style guidelines had a net positive effect (and believe me,
my first gut reaction was along the 'this is insane' lines). As process go,
the degree of automation and strict automatic enforcement (and fixing) of
rules felt lightweight after a bit.

We're neither of us going to convince the other, I just thought I'd add a
datapoint. FWIW I now write Python and although PEP8 isn't as hard-line, I
think it similarly does a lot of good.

------
biot

      > 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 old code and replacement code.

~~~
Shivetya
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.

~~~
glennsayers
"saved time, time spent cut/pasting from archive"

Surely source control would be a nicer way than copy/pasting old code back in?

------
jgrahamc
The worst thing I've ever seen: [http://blog.jgc.org/2007/08/why-you-dont-
want-to-code-for.ht...](http://blog.jgc.org/2007/08/why-you-dont-want-to-code-
for.html)

~~~
arethuza
Most amusing I've seen was Java code that was rather over zealous about DRY
and no-string-literals in code (i.e. all strings had to be define as
constants).

This resulted in code like:

    
    
       url = HTTP + COLON + SLASH + SLASH + WWW + DOMAIN_NAME + DOT + COM;
    

based on lots of definitions like:

    
    
       public final static String COLON = ":";
       public final static String SLASH = "/";
       public final static String DOT = ".";
       public final static String COM = "com";
    

[Apologies if this contains any Java syntax errors, I pretty much stopped
using Java soon after this experience]

Also I've just realised that I'm _really_ glad Java doesn't have a standard
pre-processor - truly evil things would then have been possible <shudder>

~~~
minikomi
COLON + OPEN_BRACKET

------
pooop
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 'clever' and 'obfuscated' for production.

No new language features allowed. IBM maintained languages and tools always
acquire large amounts of feature bloat over the decades. Only a small subset
of these features was 'white listed' by the CTO.

~~~
prof_hobart
> 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.

~~~
kibwen
Normally I'd tend to agree with you, but if the gp was using an AS/400, I bet
their software was written in RPG.

Now, let's play a game. :) I'm going to Gist the example RPG program from
Wikipedia, but with all the comments stripped out. Take a guess as to what it
does:

<https://gist.github.com/4204324>

(Note that the spacing shown here is _absolutely essential_. Keep this in mind
if you ever feel like complaining about whitespace in Python.)

Answer:

<http://en.wikipedia.org/wiki/IBM_RPG#Example_code>

My company's entire internal business infrastructure is written in, perhaps,
millions of lines of this (commented, thankfully).

"Right," you may say, "but this is surely easy enough to read for someone
who's used RPG for a while." Now consider that (afaik) RPG hasn't been taught
in schools since the 70s, and that this entire format is alien to folks reared
on Java. Even a poor comment in this environment is like suddenly stumbling
across a line of semi-cogent English scribbled in the margins of the
Necronomicon. Which is to say, it might just hold the insanity at bay for a
while longer. :)

Footnote: the Wikipedia article mentions a "FREE" mode that makes writing RPG
much more similar to modern languages (what an old hand here might call
"freeform" languages, a.k.a. languages that aren't column-based). But I get
the feeling that the gp's company would regard such notions as heresy.

------
wlue
I worked at a start-up whose engineering lead brought familiar coding style to
a project that was inherited. We were imposed a combination of C89-esque and
Microsoft kernel coding style on an Objective-C source code. Things like
defining all variables at the beginning of the function definition in
alphabetical order in CamelCase, having instance variables prefixed with the
class abbreviation, and other inane rules. It went something like this:

    
    
      - (void)
      doSomethingOnObjectAndNumber:
        (NSObject *) MyObject :
        (NSInteger) MyNumber
      
      /*++
      Some unstandard doc format.
      --*/
    
      {
        
        ...
        return;
      }
    

Before I started, I was told that the project migrated from git to svn to
"make branching easier". I do not work there any more.

------
moocow01
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 things like formatting/etc.
There are obviously things like variable names that it wouldnt be able to
solve but at least nobody would be complaining about where Joe put his curly
bracket. I guess you can do something similar with an SVN hook but its hard to
get a seamless process.

~~~
mseebach
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.

~~~
lmm
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 always ok to run the autoformatter on a file you are working on
(autoformatters only really work at file granularity).

4\. It is not ok to format code you are not working on.

~~~
mseebach
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.

~~~
lmm
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.

~~~
samuellb
I'd say this depends on the project and the developers. In some projects
_reading_ code is done a lot more often (and by more people) than actually
writing code, so then you might want to spend more time on e.g. formatting,
documenting, etc..

------
contingencies
The company must scale! Sysadmin and webdev must be split! Therefore all
(junior, barely unix-aware) web developers must provide automated Freebsd-
specific install, test, start and stop scripts in a custom and ill-considered
package format with no inter-component runtime or instllation-time dependency
support. For every project. Therefore the perlmonger in charge and sysadmin
extraordinaire can automate their dabblings.

Needless to say, getting barely PHP capable people who'd heard of unix to
automate dependency installation and maintenance on such a platform didn't
work out well. Did I mention this was 2010?

------
RyanMcGreal
In one project, I had to use camelCase and cargo-cult-Hungarian prefixes in
table objects: tblTableName, sVarcharColumn, iIntegerColumn, vViewName and so
on. I actaully surprised myself with just how deeply and viscerally I hated
this convention. I could no longer easily convert column names into human-
readable headings on reports; and the prefixes were just redundant, completely
missing the point [1] of Hungarian Notation.

[1] [http://msdn.microsoft.com/en-
us/library/aa260976%28v=vs.60%2...](http://msdn.microsoft.com/en-
us/library/aa260976%28v=vs.60%29.aspx)

------
Zenst
The strangest one was when I was a COBOL programmer in the mid 80's and was
forced to learn and used the GOTO verb. Having learned COBOL JSP style I was
unaware that goto even existed in COBOL until then.

There again same place made me retest a program I'd tested and was fully
working as a full-stop was missing of a comment line.

Crazy days.

------
narag
Many 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"
<sigh>.

------
josh_fyi
For those who have not yet stumbled on it, thedailywtf.com is a treasure-store
of such golden nuggets.

------
duiker101
I really feel bad for some people in this thread :( this is really painful to
read...

------
unimpressive
I was talking to someone today, and they commented:

"Good programmers eventually learn to misspell words like void or int so that
they can name their variable names what they want to name them."

I of course told him that this was terrible advice, and would mess with the
next person who had to maintain the code because you couldn't tell at a glance
if a word was a keyword or a keyword mispelled. I asked him what language he
was using.

FORTRAN.

Where did he work.

The United States Air Force.

For how long?

Six years.

When?

Before 2000.

Since he had more experience, he claimed I was de facto wrong.

I fought him on it some more.

He told me it was personal preference. I told him you'd have to make me do it.

It was at that moment I figured that someone, somewhere, had probably had to
do this as part of a coding guideline.

~~~
josh_fyi
klass for a variable of type Class is totally normal in Java.

~~~
ygra
Isn't it usually clazz?

But such things are quite annoying for automatic code generators, though, as
they have to make sure that they won't ever emit an identifier that clashes
with a keyword. The ability to just prepend @ in C# is quite helpful in that
regard.

------
regularfry
On a vaguely related note, there was a project kicking around a month or so
ago to store editor-neutral code formatting specs in the project root. Can
anyone remember what it was? My google-fu is failing.

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

~~~
panacea
(

~~~
unimpressive
Is there something clever I'm missing here?

------
Jare
In my first job as part-time programmer at a bank back in 89, we were
developing a large system in C, pretty advanced stuff compared to the usual
'buy from IBM' approach at the time. The 'systems analyst' broke down the
design into modules and functions for the entire system, and everything was
named something like 'ABM10EI00405'. Yeah, those were the actual names we had
to use for .c files and functions.

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

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

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

    
    
       FloopTwentySeven
    

rather than

    
    
       Floop27
    

:-)

------
SenorWilson
I'm not sure what's up with all the hate for reverse hungarian notation, but I
personally think it is helpful when writing C/C++.

~~~
wladimir
I think it is crazy. Especially today, when IDEs can show you the declaration
of a variable or method while hovering over it, there is no need to encode the
type of a variable into the name. Variable names need to be sensible to
humans, the compiler doesn't do checking on them anyway: it's all too common
for the type prefixes to become misleading when a program has been refactored
and they don't match up anymore.

~~~
raverbashing
It is crazy if you misuse Hungarian Notation like 99% of the people out there

For the 1000th time

"there is no need to encode the type of a variable into the name"

It's not the data type (int, char, etc), it's the nature of the thing being
counted!

Number of apples, height, distance, etc

But of course when saying "type" most people would think it's the data type
when it's not

~~~
wladimir
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 name...

~~~
djpowell
Joel Spolsky wrote a good summary about the Hungarian notation, and how it got
corrupted within Microsoft:

<http://www.joelonsoftware.com/articles/Wrong.html>

~~~
wladimir
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.

~~~
antidoh
Yeah, Hungarian Notation may have flowered in the Councils of Elrond, the mere
sound of which would give men Knowledge, Wisdom and inflation-adjusted semi-
annual raises, but out here on the edge of Mordor it's been horribly twisted
into something only an Orc could love and look upon. If an Orc could love.

------
dejv
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.

~~~
jacquesm
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.

------
ebzlo
I've been asked that I avoid using classes, because my boss didn't understand
OOP (LAMP stack).

------
segmond
put everything in a class!

------
dschiptsov
That is why _only_ products made by engineers for themselves should be re-used
(nginx, redis, etc.) and those been "managed" by idiots should be avoided.)

Over-management is much more common and much worse problem than over-
engineering.)

