Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Have you ever had to work to coding standards that:

  • Greatly decreased your productivity?
  • Were originally included for good reasons but were kept long after the original concern became irrelevant?
  • Were in a list so long that it was impossible to remember them all?
  • Made you think the author was just trying to leave their mark rather than encouraging good coding practice?
  • You had no idea why they were included?

If so, what is your least favorite rule and why?

Some examples here


locked by World Engineer Dec 5 '13 at 19:11

This question exists because it has historical significance, but it is not considered a good, on-topic question for this site, so please do not use it as evidence that you can ask similar questions here. This question and its answers are frozen and cannot be changed. More info: help center.

closed as not constructive by Mark Trapp Sep 26 '11 at 8:19

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

I've asked a similar question (but not exactly the same) on SO before by the way:… – Brian R. Bondy Sep 8 '10 at 16:30
@Brian, thanks, I had seen your question but forgotten about it. – finnw Sep 8 '10 at 16:54
The real problem with coding standards is the time and effort wasted arguing over whether they are correct or not. Nothing beats a good curly-brace war for creating internecine strife... – MZB Oct 14 '10 at 16:07

56 Answers 56

up vote 97 down vote accepted

This may ruffle a few feathers, but standards that mandate templated block comments at the top of each method always bug the crap out of me.

1) They are always out of date since they are too far from the code that does the actual work to notice when you are updating things. Bad comments are worse than no comments.

2) They often just repeat information that is already contained the source control tool, just less accurate. For example: Last Modified by, list of modification date/reasons.

I find (at least now, earlier at school that seemed strange) that Commenting altogether is a bad practice – Shady M. Najib Sep 9 '10 at 15:52
Not only that but I've found that the overhead associated with creating a new class file when you have to put a load of boilerplate at the top actually dissuades devs from creating new classes and encourages enormous unwieldy classes and hence bad design. – Gaz Sep 9 '10 at 16:50
Disagree! We don't add useless ore reduntand information, but an actual textual explanation of what the function does (in the .h file) and it is so useful! Of course we are committed to maintain it in sync with the code. – Wizard Sep 9 '10 at 18:09
@Shady M Najib bad always or bad when allowed to go uncontrolled/unmaintained? Generally, good code will make its purpose obvious enough to avoid the need for comments- but that isn't always the case and I feel that in these scenarios commenting is crucial. I can't think of one bad reason to include XMLDoc comments. – Nathan Taylor Sep 9 '10 at 23:27
A block explaining what it does is good. A block simply re-iterating the types and names of the arguments and return value is bad. When I had to work with a standard mandating the latter, I wrote an emacs script to auto-generate the majority of it. – AShelly Sep 10 '10 at 16:53

Had a professor once who demanded we have at least one comment for each line of code.

//Set x to 3
var x = 3;

//if x is greater than 2

    //Print x

It was pretty ridiculous.

Isn't this just so the professor knows that you know exactly what is going on? – John MacIntyre Sep 8 '10 at 18:13
I think it's clear what's going on, and it ain't education. – Dan Ray Sep 8 '10 at 19:09
The example you have above is clear, but what if a student copies some function call from another app or a book or what ever, and doesn't really understand it? How will the prof know? This stupid rule doesn't allow any grey area (which in his defense, has probably been abused before). That's how I interpret this. ... mind you if I saw this in a non-academic environment it might scare me a bit. ;-) – John MacIntyre Sep 8 '10 at 19:55
+1, unless you’re coding in Assembly :) – Daniel Cassidy Sep 9 '10 at 17:36
What if you've accidentally got a useful comment in your code? Do you need to put // comment on the line before that? – configurator Sep 29 '10 at 3:49

Our company (C#) coding standard called for extensive use of #REGIONs (for those who don't know, it marks blocks of source code that will be collapsted to a single line in Visual Studio). As a consequence, you always opened what seemed to be a nicely structured class, only to find piles and piles of garbage swept under deeply nested rugs of #REGION constructs. You'd even have regions around single lines, e.g. having to fold out a fold out a LOG region to find one single declaration of the Logger. Of course, plenty of methods added after some region was made, were placed in the "wrong" region scope as well. The horror. The horror.

Regions are one of the worst features ever added to Visual Studio; it encourages structuring the surface rather than the actual OO structure.

Nowadays, I kill #REGIONs on sight.

I tried to up vote this a dozen times... – TGnat Sep 9 '10 at 17:54
If you think you need #REGION, I think you need to refactor. – Jay Bazuzi Sep 9 '10 at 19:56
I generally organize code by regions into constructors, properties, events, methods, and members. It makes managing and navigating the source a cinch (especially in some static utility classes that can grow pretty large). I wouldn't use them any more than that though. – Evan Plaice Sep 11 '10 at 8:23
We have a simple coding standard: never nest regions. Just use them to group related methods (initialisation, serialisation, properties, etc) – Jason Williams Sep 11 '10 at 21:53
The only good purpose of #regions is to hide code that doesn't need to be edited. That could be generated code, or code with a difficult-to-get-right algorithm that you'd rather people not touch, or maybe ugly debugging-code blocks. But not code that people will be working on. For those stuck in a #region shop, I have a macro that collapses to definitions but expands regions. See here:… – Kyralessa Sep 29 '10 at 1:28

In one job we were forced to use some weird form of Hungarian notation in the database.

I can't remember the details, but from memory, each field name had to contain:

  • No vowels
  • All uppercase letters
  • A reference to the table
  • A data type indicator
  • A data length
  • A nullable indicator

For example, the column holding a person's first name might be called: PRSNFRSTNMVC30X (Person table, First Name column, Varchar 30 characters, Not Null)

Sorry, but what happens when you refactor the database or when you decide that the length of the VARCHAR needs to be different. Suddenly, you've got to go through all your code and change... oh god. That looks horrific. – Tom Morris Sep 8 '10 at 23:32
No vowels??! You’re joking, right? – Daniel Cassidy Sep 9 '10 at 17:37
Did the people who enforced this standard have ridges on their foreheads and often discuss honour and battle? – Ryan Roberts Sep 9 '10 at 18:13
Haha, well they were DBAs, so... ;) – Damovisa Sep 9 '10 at 21:49
You should have sent your column names through a url shortner. PersonFirstNameVarchar30NotNull = – Billy Coover Sep 16 '10 at 16:42

Insisting that all braces be followed by comment for what the brace ends:


for (int i = 0; i < 10; i++)
    if (foo > bar)
        printf("Foo greater than bar");
    } // End If (foo > bar)

    while (baz)
    } // End while (baz)
} // End For
More seniable: if you need a comment to say what the start of the block was, then the block is too long, or its content is too complex => refactor. – Richard Sep 9 '10 at 19:56
I want to vote down, because long, deeply nested blocks can be hard to sort out, and these comments might help. I want to vote up, because those comments will become wrong (and very confusing) pretty soon, and because long, deeply nested blocks are a sign you need to refactor, not add more comments. – Jay Bazuzi Sep 9 '10 at 20:06
that was a great idea for a world with no powerful IDE. – IAdapter Sep 9 '10 at 22:17
@Jay in any decent IDE you can highlight one brace and it'll highlight the other corresponding brace. I personally loathe when people do this. – Evan Plaice Sep 11 '10 at 8:32
While your example is a bit on the crazy side (as they aren't long enough that it would matter and would slow you down when changing the logic), this isn't always a bad thing. Comments like that are really useful for closing namespaces/endif declarations that span an entire file. – jsternberg Oct 31 '10 at 19:55
#define AND  &&
#define OR   ||
#define EQ   ==

'nuff said.

Wouldn't #include <iso646.h> be much better choice? – AndrejaKo Sep 8 '10 at 19:48
@AndrejaKo: this predated <iso646.h>; this was an attempt to make C look like FORTRAN. – Niall C. Sep 9 '10 at 2:00
Was this really a coding standard? i.e. was there a company policy against writing the operators directly? – finnw Sep 9 '10 at 9:13
Did it also have #define BEGIN { and #DEFINE END } ? – JBRWilkinson Sep 9 '10 at 9:37
That reminds me of a Daily WTF article I saw that had some C++ programmer have a ton of defines to make it look like Visual Basic (or maybe just Basic, some dialect). #define void Sub, #define } End, things like that. – Wayne M Apr 13 '11 at 18:28
  • Local variable names are all lowercase with no underscores

Real examples: paymentmethodtotalshtml, contracttypechangecontexts, customsegmentspectexts, potentialmsceventref

The New York Times weighs in:

“Word spaces should not be taken for granted. Ancient Greek, the first alphabet to feature vowels, could be deciphered without word spaces if you sounded it out, and did without them. […] Latin, too, ceased to separate words by the second century. The loss is puzzling, because the eye has to work much harder to read unseparated text. But as the paleographer Paul Saenger has explained, the ancient world did not desire ‘to make reading easier and swifter.’”
+1. The minor annoyances add up. Also they are hard to argue against because the coding standards editor or PM can say "It's no great burden so it's not worth changing it." – finnw Sep 9 '10 at 18:43
Exactly. (Though in this case, reading umpteen variablenameslike thiscanreally adduptoquitea greatburden.) – John Siracusa Sep 9 '10 at 18:58
Amuse yourself by inventing names than be parsed two ways. pageshits, penisup, etc. – Jay Bazuzi Sep 9 '10 at 19:59
@Jay *sexchange – configurator Sep 29 '10 at 4:04
@configurator: When the Visual Studio debugger team was working on a feature to let you see the currently-in-flight exception in the watch window, they were going to add a pseudo-variable called "$ex". We didn't notice for a long time. Then we renamed to "$exception", but I still read it as having an 's'. – Jay Bazuzi Sep 29 '10 at 6:33

All interaction with the database has to be done through stored procedures. It might make sense if we're living in 1997 and not 2010.

I just realized that this actually covers all the criteria of the original question:

  • Greatly decreased your productivity? CHECK. Please - just use an ORM.
  • Were originally included for good reasons but were kept long after the original concern became irrelevant? CHECK. The manager was a developer for a database server 1000 years ago and put this coding standard in.
  • Were in a list so long that it was impossible to remember them all? CHECK. This included 'as much logic should be stored in the database as possible'.
  • Made you think the author was just trying to leave their mark rather than encouraging good coding practice? CHECK. Keeps coming back to the manager being an ex-database server developer.
  • You had no idea why they were included? CHECK.
We've got some people in this camp in my workplace. It's funny when they try to play the performance card and demonstrate just how out of date their knowledge is – Doctor Jones Sep 9 '10 at 17:55
wait.. in all seriousness, I thought SP's WERE better, performance-wise, than straight SQL calls from, say, C#? – Sk93 Sep 10 '10 at 8:14
Sounds like you know exactly why they were included. :P – Mason Wheeler Sep 10 '10 at 23:38
When I grew up I finally understood why everything should go through the DB :) In all seriousness, this simplifies so many things, don't try and re-invent the wheel. – Xepoch Sep 16 '10 at 17:19
I've heard the lovely reasoning "We can't use an OR/M because all interaction must use SPs". Such a waste of man-power. – configurator Sep 29 '10 at 4:01

I was asked by the software leader of a company to do "simple, rendundant code". It was forbidden, for example, to add a new parameter to an existing function. You instead had to duplicate the function, leaving the original untouched in order to avoid regressions. No formal testing of course (waste of time).

We were also forbidden from using merge software; each file could only be modified by one programmer at a time. Revision control software was science fiction, of course.

The happiest day of my life was when he was fired (consider that it is very, very difficult to fire someone in Italy).

he might never heard word 'refactoring' – nanda Sep 9 '10 at 18:05
He never heard also a lot of other words... – Wizard79 Sep 9 '10 at 18:58
Well you didn't need formal testing because you never changed methods... – configurator Sep 29 '10 at 4:02

Not being allowed to use the STL or other standard C++ libraries because the CTO believed 'we' could do it better and faster. Even basic constructs like lists and the string class.

The only time I've ever heard of anyone not using the STL because it wasn't fast enough, and being right, was for games. EA made their own implementation of the STL for their games. I highly doubt it matters anymore (modern games are GPU limited) and I doubt they use it. But even still, it was an implementation of the STL, not a whole new library. You were still using the STL when using EASTL. – Matt Olenik Sep 13 '10 at 23:18
@Matt: to add to this, EA complaint was centered on memory usage and initialization. Their own implementation consumed less memory, released it sooner, and avoided initializing objects that would be initialized later. – Matthieu M. Oct 14 '10 at 18:00
I'd tell him to code it himself. – rightfold Aug 12 '11 at 14:30

Hungarian notation

Sample extracted from "Charles Simonyi's explication of the Hungarian notation identifier naming convention" on MSDN.

1  #include “sy.h”
2  extern int *rgwDic;
3  extern int bsyMac;
4  struct SY *PsySz(char sz[])
6      {
7      char *pch;
8      int cch;
9      struct SY *psy, *PsyCreate();
10      int *pbsy;
11      int cwSz;
12      unsigned wHash=0;
13      pch=sz;
14      while (*pch!=0
15        wHash=(wHash11+*pch++;
16      cch=pch-sz;
17      pbsy=&rgbsyHash[(wHash&077777)%cwHash];
18      for (; *pbsy!=0; pbsy = &psy->bsyNext)
19        {
20        char *szSy;
21        szSy= (psy=(struct SY*)&rgwDic[*pbsy])->sz;
22        pch=sz;
23        while (*pch==*szSy++)
24            {
25            if (*pch++==0)
26              return (psy);
27            }
28        }
29      cwSz=0;
30      if (cch>=2)
31        cwSz=(cch-2/sizeof(int)+1;
32      *pbsy=(int *)(psy=PsyCreate(cwSY+cwSz))-rgwDic;
33      Zero((int *)psy,cwSY);
34      bltbyte(sz, psy->sz, cch+1);
35      return(psy);
36      }
Ow ow ow ow ow ow! – Doctor Jones Sep 9 '10 at 17:57
The biggest problem with this sample is the meaningless variable names. Strip away the Hungarian prefixes and some of them are 1 or even 0 characters long. – finnw Sep 9 '10 at 18:54
This is Systems hungarian, which is useful in weakly-typed languages (as it encodes the type information that is critical for working in these languages in the names) - it's useless in strongly typed languages. The better alternative for strongly typed languages is Apps Hungarian, which encodes important information about the usage of a variable (member, pointer, volatile, indexer) - something the language itself provides no support for. – Jason Williams Sep 11 '10 at 21:51
Oh please. I've never ever confused a local with a member, and I don't use that silly Hungarian for members/locals/fields/whatever. I think they might be useful for differentiating between different kinds of strings, like 'safe' and 'unsafe', like Joel's example in Making Wrong Code Look Wrong – configurator Sep 29 '10 at 3:59
@configurator: Joel's example is horrid, he'd be better off having different types, then the compiler would enforce the use. – Matthieu M. Oct 14 '10 at 17:57

I once worked on a project in which the project lead mandated that every variable - EVERY variable - be prefixed with "v". So, vCount, vFirstName, vIsWarranty, etc.

Why? "Because we're working in VBScript and everything is a Variant anyway".


I once worked in a language that required every variable – EVERY variable – be prefixed with "$". – nohat Sep 10 '10 at 2:03
@nohat: And you realized that it was amazing, didn't you? – Josh K Sep 20 '10 at 22:26
I once worked in a language where all my variables began with punctuation like '$' or '%' or '@'. I still do, now and then. – David Thornley Sep 23 '10 at 14:51
This only really becomes a problem when your required to put an f before functions, then your code is truly fUcked (vUp). – Joe D Sep 24 '10 at 19:37
Sounds like various versions of Perl... – user1249 Sep 26 '10 at 22:06

Almost forgot this one:

Quote from a manager:

Do not fix or document any bugs of issues you find in your own code. The customer will pay us to identify and fix them over the next few years.

This wasn't for consumer software, but custom for a single large organization. Needless to say, the customer did pay for years afterwards. May seem trivial, but trying to ignore bugs is harder than finding them.

This is a horrible policy. I hope this manager was canned. – Bernard Mar 16 '11 at 15:37
@Bernard-In most organizations creating a long term revenue stream is grounds for rapid promotion. Hopefully, somebody else saw the insanity in this and accidentally ran him/her over in the parking lot. – Jim Rush Jul 8 '11 at 17:54

Enforced XML comments on all non-private methods, constants, enums, and properties.

It led to some pretty cluttered code, especially since the end result was people either just hitting /// to create an empty comment stub for everything or installing GhostDoc and having it add auto-generated comments:

/// <summary>
/// Validations the handler.
/// </summary>
/// <param name="propertyName">The property name.</param>
public void ValidationHandler(string propertyName) 
   // whatever

[Edit] The reason I mention this as a ridiculous standard isn't because I think method comments are stupid but because the quality of these comments wasn't enforced in any way and resulted in just creating lots and lots of clutter in the code files. There are better ways of creating meaningful code docs than blind "must have a comment" build requirement.

'Validations the handler' - uh-oh – Eric Sep 8 '10 at 21:46
+1 Ugh I hate this. I think if your using software to generate comments then you dont need them. – bleevo Sep 8 '10 at 23:40
I don't think this is a bad rule. When reading a method that I have to maintain for the first time it helps a lot if I have specifications for all the arguments. There are usualy subtleties (e.g. what happens if the argument is null, what if it's an empty collection, the name of a nonexistent file etc.) Another good (IMHO) rule is method names should be verbs but in your example it's a noun. – finnw Sep 9 '10 at 9:18
@finnw I think it's a good practice, but a bad standard. If developers are on board and writing meaningful method comments when they're warranted (exception details, etc), that's great. If not, you end up with a big mess. And in the former case, you don't need compilation-level enforcement at all. – Adam Lear Sep 9 '10 at 13:27
Classic case of undocumentation. Comments that don't tell anything apart from the blatantly obvious should be killed on sight. – Cumbayah Sep 9 '10 at 17:05

Not really a coding standard, but we had a file in source control called 'changelog.txt'

Every time you made a checkin, you had to manually add an entry to this file. This entry was the subversion revision number and your checkin comment.

When the new CTO started and someone told him this, he promptly made an executive decision and said, "We're not going to do this anymore" and deleted the file. This had been going on for years.

And no one was aware of svn log? – Htbaa Mar 16 '11 at 14:51
Those who started the policy were long gone and those that followed kept it going. I started within the same week as the new CTO (friend of mine) and we both looked at this and said WTF? – Jim A Mar 30 '11 at 11:06

Some of the places I've worked with insisted on commenting out unused or deprecated code instead of deleting it. Instead of trusting the VCS for history, etc. it was painfully maintained in the files through commented out code.

The big problem I found with this is that you often had no idea why the code was commented out. Was it because some dev was actively making changes and wanted to keep it around for reference or was it no longer needed?

I've been deleting a lot of old commented out code recently. – CoderDennis Oct 5 '10 at 20:03
I usually delete commented out code unless it is accompanied by a good explanation for why it's commented out and why it should be kept in place. – Jeremy Wiebe Oct 6 '10 at 0:35
I totally agree. Commenting code out as long as you work with it is okay, but everything that goes into a release version/main branch should be void of commented code. Someone told me that they "liked to know how it could be done differently". I just find it irritating for the reasons mentioned: Is that obsolete, a workaround, another way to do it? WTF – Anne Schuessler Apr 13 '11 at 16:12
With VS2013 "Peeks" this is all out the window. But we put a comment that says "Changed Equation - Initials" or something, so somebody wondering what the old code was would look in TFS/VCS if they needed to. So it's one line instead of 10 commented-out lines. But VS2013 is awesome, it shows TFS history right there for you. – Suamere Sep 16 '13 at 17:39

The worst coding standard I've ever participated in is code bases which had none at all. I'd rather follow a coding standard I completely disagree with than work in code bases where there is none at all. It makes it that much harder to learn new parts of the code base.


Forcing inline comments for version control was about the most pointless coding standard I ignored.

//Changed on 2/2/2004 By Ryan Roberts for work item #2323332
Dim Some Horrendous VB
//End Changed

The Oracle DBA that insisted on correct use of whitespace while 'maintaining' a database with a highly contended table that had over 200 fields and 40 triggers comes close.

That's pretty heinous – Evan Plaice Sep 11 '10 at 8:31
Mmm. Dim Sum... – configurator Sep 29 '10 at 4:06
I did this, before we had source control, of course. Once we had source control, it was such a habit, we practically needed an intervention for the team to stop doing it. Eventually we stopped and deleted all the existing ones when we found them. – Scott Whitlock Oct 31 '10 at 19:24
Our senior dev still tries to force us to do this. I ignore the policy whenever I think I can get away with it (and sometimes when I know I can't). – Joshua Smith May 20 '11 at 14:23
We have a guy on our team who still does this everywhere (he also includes huge "Change Log" things on our SQL scripts which are also under version control). The argument, as explained to me, is that after a few changes/commits you don't remember the date something was changed, so the change log is good to immediately notice who changed what and why when you open up a file. – Wayne M Jun 2 '11 at 15:43

I did code reviews on a project led by a C++ first timer who decided that all class member functions should be prefixed with the class name and visibility:

class MyClass
      void MyClass_Public_setValue(int value);
Did you ask them why? I'd just love to know their motivation.. – JBRWilkinson Oct 15 '10 at 21:42
Wow, why is that guy even using classes? – Mateen Ulhaq Nov 21 '10 at 23:51

Being required to indent all code by four spaces ;)

How was this bad? – Jay Bazuzi Sep 9 '10 at 20:06
Because then every line has 4 unneeded spaces at the beginning of it? – nohat Sep 10 '10 at 2:09
Oh, I get it now. – alternative Sep 10 '10 at 22:21
Yeah, StackOverflow has really bad coding standard. :-) – Pavel Shved Sep 11 '10 at 7:22
Big indents force you to keep the code nesting level low. I have seen indents of 8 and it worked fine. – Toon Krijthe Sep 15 '10 at 8:49

I had a job years ago where all our code had to be left-aligned - no indenting. The guy who came up with that policy disliked having to scroll back and forth horizontally when viewing long lines of code, equating it playing ping-pong with his eyes.

That's a horrible, horrible coding standard to have to follow. And a stupid reason for it, too! – gablin Sep 23 '10 at 21:00
If you need to scroll horizontally (for example more than half a page) there's probably something wrong as well. No indenting isn't good either as it makes code completely unreadable. I try to stick with a 78-col limit, but if required to go over that amount I don't mind, but I do try to avoid it. – Htbaa Mar 16 '11 at 15:11

This more an example of how not having coding standards can hurt.

A contractor working at a large bank insisted that following the standards were the best ever. The application was written in dBase/Clipper which he was the sole developer for and of course he came up with the standard.

  • Everything is in upper case. I mean everything, including the rare comments he made.
  • No indentation.
  • Variable naming was something along the lines of APRGNAME. A = scope of variable, eg P for public, PRG = first three characters of the source file that created the variable, NAME = variable name in the remaining 6 characters that dBase/Clipper allowed.
  • The first 4 and last 4 lines of the source code were 80 * long. Why? So he could hear the dot matrix printer starting and finishing the printing of a file. Memory is the entire program was printed via the mainframe weekly, 20,000 pages.
  • I'm sure there were many more that I've managed to dump from my brain.

I was a very new self-taught programmer at that stage but knew enough not to listen to the mad scientist and get the hell out of there before I asked to take over the project.

And yes we told management how bad these practices were but always got the usual "were paying this contractor top dollar he must know what he's talking about".

Do not mock older dinosaurs, please. They made us possible. – Pavel Shved Sep 11 '10 at 7:24
Sounds like job security. – MIA Sep 24 '10 at 1:22
Having an audio marker so you know when each file is printing is ingenious. I'm going to add \07 to the start of each file now. – configurator Sep 29 '10 at 4:20
Using a naming scheme like this (Not the upper case) made some sense as dBase's variable "scoping" rules were non-existant. Everything was effectively global. An i used to index an array in one procedure could interfere with an i in a calling procedure. You need to use PRIVATE ALL LIKE m* and PRIVATE i to prevent this "shadowing" – Gerry Sep 30 '10 at 1:12

One more blast from my past.

Quote from company owner:

There will be no code written using interpretive languages because I lost 25 million on that {expletive} project written in Java.

The Java project was a stock trading system designed to handle a few dozen stocks, that was now being used to process thousands. Instead of addressing the design flaws or poor hardware, the whole company was forced to convert all non C/C++ applications to C/C++, and all new development had to be in C/C++. Interpretive languages meant anything not compiled, and the owner only considered Assembler, C and C++ compiled.

For an 800 person company, in which most of the code was in Java and Perl, this meant the whole company spent most of their time over the next couple of years rewriting perfectly fine code in C/C++.

Funny enough, some twenty years before this fiasco, I was at another company in which the tech lead decided that our sorting logic (it was a Bubble Sort) needed to be recoded in assembler instead of being replaced by Quick Sort because -- Algorithms do not improve performance. The only way to improve performance was to rewrite the same logic in assembler.

In both cases, I left shortly after the dictates came down.

Is either company still running today? – finnw Oct 4 '10 at 9:36
The one that 'moved' off Java is, the other is long since gone. They never survived the move from TRS-80 to a PC. – David B Oct 5 '10 at 3:59

Like a lot of programmers (but not enough), I hate code decoration. It infuriates me when I have to use a dollar sign($) prefix for variable names, or underscores for private variables, even with no getters/setters. If you need to decorate you code to understand it, then you need to get the hell out!

Well, as "Will" says, "I prepend with the underscore so that my private variables are grouped in my intellisense. However, I only do this for variables scoped to a type. Variables declared within a method or narrower scope I leave the underscore off. Makes it easy to keep them separate and keep less used variables together." and I have to agree with him. – 7wp Sep 9 '10 at 18:11
I don't think grouping your variables together in your favourite proprietary IDE is a good enough reason to deface all your code. – Adam Harte Sep 9 '10 at 20:44
If it's your code, making it usable in your IDE seems completely reasonable. Also, prepending underscores is common in many languages, so whenever people see it, they know what it means. – rjmunro Sep 9 '10 at 22:01
+1 Using a good IDE (one that can use regex search) makes more sense to me. Scratch IDE, learn to use a text editor and terminal and you will be a much better programmer. As a side note, I don't particularly like the perl sigils, but at least they have a use, unlike the PHP ones. – alternative Sep 9 '10 at 22:32
Sigh... another one of those "IDE's are for pussies" people. – Nailer Sep 23 '10 at 13:41

I've been working with a web system for a while where all parameters passed had to be named P1, P2, P3 etc. No chance in hell to know what they where for without extensive documentation.

Also - although not strictly a coding standard - in the same system, every single file was to be named xyz0001.ext, xyz0002.ext, xyz0003.ext, etc - where xyz was the code for the application in itself.


This was a LONG time ago -- 1976 to be exact. My boss had never heard of Edsger Dijkstra or read an issue of CACM, but he had heard a rumor from somewhere that "GOTO is bad", so we were not allowed to use GOTO in our COBOL programs. This was before COBOL added the "end if", so at the time it had only two-and-a-half of the three classic control structures (sequence, if / then / else, perform (i.e. do while)). He grudgingly allowed GOTO in our Basic programs, and branch instructions in our Assembler language programs.

Sorry that this is a sort of "you had to be there" story. As far as I know, every language invented since 1976 has adequate control structures so that you never need to use GOTO. But the point is, the boss never knew WHY GOTO was considered harmful, or which language was the infantile disorder and which was the fatal disease.


I worked in a project were the chief architect demand to write (way too) explicit code. One of the worst examples I found in the code (and he happily approved) was the following.

private string DoSomething( bool verbose )
    if ( verbose ) { return someString; }
    else if ( !verbose ) { return otherString; }
    else { return string.Empty; }

Even ReSharper told you this is wrong!

You'd be hard pressed to return something from a function declared as void. – Mircea Chirea Sep 9 '10 at 18:16
@MAttB Consider under what conditions the final (else) branch would be taken. – Richard Sep 9 '10 at 19:52
else { return string.Empty; } will execute when the above 2 lines have been edited by a maintenance developer 5 years from now. However, returning string.Empty will hide the fact that is used to be an impossible condition. It should instead throw InvalidOperationException("This code wasn't intended to support three value logic"); – MatthewMartin Sep 10 '10 at 19:23
This is horrific. What's wrong with return verbose ? someString : someOtherString;? – Callum Rogers Sep 24 '10 at 10:45
@callum Ternary operator might be banned :) been there before... – hplbsh Jan 11 '11 at 4:30

At my last job, "standards" would be a very strong term for what I was given by the guy who hired me. Programming websites in ColdFusion and SQL, I was given coding requirements like:

  • Don't use includes. I like one big page
  • Always separate words in variable and column names with underscores (except isactive, firstname, etc.)
  • Never use abbreviations -- always write out firstname (he frequently wrote fname and so forth)
  • Don't use confusing names (like amount_charged and charge_amount, which measured differnt but related things)
  • Don't use DIVs, and use minimal CSS -- use nested tables instead (I found some six layers deep, once).
  • Don't cache any queries. Ever.
  • Going to use a variable on more than one page? Application scope.
  • Each page is its own try/catch block. We don't need/want a global error handler.

I started changing these as soon as he quit.

"Don't use confusing names" seems fair enough to me... – 8128 Oct 2 '10 at 15:15
It's absolutely a fair guideline. My point was that he didn't follow it at all. I guess his idea of "not confusing" and mine were different. – Ben Doom Oct 3 '10 at 15:00

In my life as C++ coder, two really nasty "rules" were enforced:

  1. "We can not use the STL, because VC++ 4.1 does not support it (and we can't switch to VC++ 6.0 at this time)."
  2. "Do not use QuickSort, because it can be O(n^2) in bad cases; use this implementation of the HeapSort algorithm I (name of project leader deleted) wrote as a student."
What was wrong with the project lead's HeapSort? – 7wp Sep 9 '10 at 18:02
Actually if code accepted external user input QuickSort may be wrong as it opens to O(n^2) DOS attacks (feeding worst-case input). Also why it wasn't possible to switch - it itself was valid excuse of not using STL. – Maciej Piechotka Sep 9 '10 at 22:17

I worked for a short time in Japan. I was doing complex mathematical coding. The company coding standard was to have absolutely no comments. It was difficult as I would have liked to add some comments to explain the complex calculations and not forget myself after few weeks. Pity the next guy who comes after me to understand what the code was doing.

It was the first time I ever saw that coding comments were prohibited.


Not the answer you're looking for? Browse other questions tagged or ask your own question.