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

  • 4
    I've asked a similar question (but not exactly the same) on SO before by the way: stackoverflow.com/questions/218123/… – 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
  • 4
    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


Nearly any sort of variable naming convention that reiterates the variable type, mutability, scope / storage class, and/or their reference. Basically, any construct intrinsic to the language. This is no longer necessary in the 21st century with modern IDEs (and in my opinion only originally solved poor code layout / practices to begin with). This includes hungarian notation and its variants:

  • bigBlobStr - A string.
  • bigBlobStrCurLocPtr - A pointer to the "current location" in said string.
  • someIntArray - Array of integers

or things like:

  • e_globalHeading - External variable
  • sg_prefPoolSz - Static global variable

and of course one the farthest reaching eyesore in OOP, m_ for all members. If you can't be sure / keep track of which variables are local, members, globals, static, or final/const, you might be writing unclear, poorly factored, spaghetti code.

This is wholey different than specifying a prefix/suffix convention for things like min, max, avg, size, count, index, et cetera, which is fine.

  • 1
    Sometimes there are good reasons for including type information in variable names. – finnw Sep 14 '10 at 2:09
  • 3
    Umm... interesting that you quote Spolsky's article on it, as it's more to the point, "The dark side took over Hungarian Notation." It's all about "Apps Hungarian" being twisted into "Systems Hungarian" because people make an incorrect inference about what Simonyi meant when he said "type". It's to see wrongness when you are assigning a "colX" to a "rowY", not so that you can keep track of the fact that something is a long integer as opposed to a short. Also, I specifically call out only variables. I foresee a -1 from swaths embedded devs still using vi and C++ devs as it's "just the way". – charstar Sep 14 '10 at 6:18

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.


Worst standard I've ever had to face:

StyleCop for C#

Take every pointless standard ever and put it into a tool that runs at compile time instead of in the IDE at design time.

//this is not a legal comment.
//  nor is this

// must be followed by a single space, if you are debugging, use //// to comment code. Properties must also have 'triple slash' comments and they must read "Gets or Sets xxxxx" complete with a period at the end and properly capitalized.

Ugh. Maybe there's a point with widely published APIs but my main beef is they surely could have built it as a plugin a la R#.

  • There's a plugin for ReSharper (Style Cop For ReSharper), which makes styleCop a lot more useable. – Ed James Nov 15 '10 at 17:53
  • My personal standard for period at the end is: if it's not a complete sentence, leave it out. It's fine to have a period here: // Initialize balloon release context. , but not here: // If malloc fails. – Joey Adams Dec 14 '10 at 4:06
  • StyleCop is great, though, IF you go in and remove those pointless standards that just make unnecessary work. Some things that StyleCop enforces are actually very, very useful. – Andrew Arnold Mar 3 '11 at 16:24
  • Using a different syntax to comment out code temporarily for debugging, and to write actual comments, makes sense. – MatrixFrog Jul 9 '11 at 1:04

Mandatory inclusion, expansion of $Log$ information when our SCC was antiquated version of PVCS. We had some files where the $Log$ information was much, much longer than the actual code in the file.

  • Can just put the $Log$ line at the end of the file, I've had to do that too, but sometimes I actually figured a few bugs out this way. – Jé Queue Sep 16 '10 at 17:23
  • 1
    If we were allowed to do sanity saving things like that, it wouldn't be in this thread. :) It was mandatory it appeared at the top of the file too. – Ian C. Sep 17 '10 at 16:20

The worst was a project (C++) where classes were prefixed with module abbreviations.

For example, if something was in the MessagePassing module, and part of the Response mechanism, it might be called MESPAS_RESSomeobject.

Working on that code made me want to gouge out my eyes.

Not the worst, but my current job requires a c_ prefixes on classes and e_ prefixes for enums. Nothing for structs. but _t postfix on typedefs. It's pretty ugly too.

Oh, and function header comments in BOTH .h and .cpp (declaration and definition) which of course almost never match.

  • Use struct's with private members instead of classes then. – Joe D Sep 24 '10 at 19:43
  • Never heard of namespaces? – configurator Sep 29 '10 at 4:13
  • 1
    @Joe D. Yeah, because I, a lowly developer, can change the coding standard for a company that employs 3,000+ other developers. – µBio Sep 30 '10 at 16:37
  • 2
    @configurator it's not a matter of whether I consider myself lowly or not. I check in code out of coding standard format, it doesn't go to trunk. Period. And so my tasks don't get complete. Who looks bad, the engineers who define the standards for the entire industry, or me, who didn't complete my task? – µBio Oct 1 '10 at 22:18
  • 1
    With repesect to the second part of your answer: The class prefix is the really bad one. I'm indifferent about the _t for typedefs, since the C standard library (and thus much of the C++ standard library) uses that convention, and I can see some value in going with the language's standard convention. I'm not really a fan of the enum prefix, but can see some tiny value in it as a reminder that it is only a thin wrapper over an integer, and may have invalid values. – Kevin Cathcart Apr 23 '12 at 18:37

My favorite is the "No magic numbers" rule applied cluelessly. For example, I once saw a comment in a code review stating then the "No magic numbers" rule had been violated by this line of code:

if (fscanf(file, "%s %hd",name, nbrObject ) != 2 )

I guess the reviewer wanted a constant instead of 2, such as #define TWO 2

  • 1
    I'm in favor of magic numbers. You want to know the semantics of the "2" so a constant of TWO defeats the purpose. – Toon Krijthe Sep 15 '10 at 8:48
  • 4
    My C is a little rusty and I don't know what fscanf returns. Therefore this test is incomprehensible to me. Either a constant or a comment would solve this problem. – Foole Sep 20 '10 at 3:26
  • 28
    I think you misunderstood your reviewer. He probably wanted you to to add write it like this: const int itemsToRead = 2; if (fscanf(file, "%s %hd",name, nbrObject ) != itemsToRead ) – Nailer Sep 23 '10 at 13:34

All output in a PHP script must be echoed line by line.

echo "<div id=\"foo\">";
echo "<h1>" . $title . "</h1>";
echo paragraphs($body); // just an example
echo "</div>";

(Disclaimer: I didn't have to follow it, but a team I worked with did.)


At a previous job, the C# standard was to have at least two spaces between type name and variable name in declarations, the method name must begin on the next line from the access modifiers and return type, a space must occur before any open-punctuation (parenthesis or bracket), all variable declarations at the beginning of the method, declarations separate from assignment and the indentation was 3 spaces. Example:

private static int
ThisIsTheMethod (int  code, string  message)
   int  i;
   int  j;
   int  k;

   for (i = 0; i < message.Length; i++)
      if (message [i] == '!') return -1;

   j = SomeMethod (code);
   k = OtherMethod (j);

   return k;

While ugly, it was workable with the exception that Visual Studio really didn't want things that way and it was more an extra step after coding "normally" to reformat it as this.

  • 1
    My head would explode. Seriously, WTF?! – Marcel Lamothe Sep 23 '10 at 15:21
  • 2
    Some of these you can configure in VS options (like the space before the parentheses), but not the double spacing. That doesn't make enough sense to be configurable. – Kirk Broadhurst Sep 24 '10 at 1:32
  • 1
    I've come to the conclusion people using C# need to realize IT IS NOT VB6. You can set variables on the same line as declaration. You don't need Hungarian Notation. You don't need this "m_" crap for member-level variables. I swear, most of my frustration with C# comes from people who still think in the old Classic VB mentality. I'm mad, bros. – Wayne Molina Jun 2 '11 at 16:00
  • Preach it, Brother Wayne! – Jesse C. Slicer Jun 2 '11 at 16:37

Our method names had to be in the format 'Get/Set/Add/Delete' + name of the target object + names of all the parameters.


Fair enough - but the rule very strict. Complex object types were not allowed to be abbreviated, and operations always had to list every request parameter, no matter how ridiculous:


After adding in the full variable names (which weren't allowed to be shortened, either) you can imagine how long some simple method calls were. Word wrappingly long.

  • I don't really see the problem. When using autocomplete at least. The function names are very descriptive. – rightfold Aug 12 '11 at 14:34
  • The problem is about usability - when you can't see the name of a method and all of its parameters in a single screen width (i.e. you have to horizontally scroll to see the whole call) then it becomes significantly less usable. – Kirk Broadhurst Aug 14 '11 at 0:47

at my previous job, which I gladly quit 3 months ago:


  • Table names had to be uppercase.
  • Table names had to be prefixed TBL_
  • Fields had to be prefixed: DS_ (for varchar, which made no sense) NU_ for numbers CD_ for ("bit fields") DT_ for dates
  • database fields had also to be uppercase [CD_ENABLED]
  • same with sp names [SP_INFINITY_USER_GROUPS_QRY] and database names [INFINITY]
  • did I mention sp names were actually like that? SP_ prefix, then database name SP_INFINITY_ then table name, SP_INFINITY_USER_GROUPS then what the sp was actually expected to do (QRY,UPD,DEL,INS) jesus, don't even get me started on queries that weren't just CRUD queries.
  • all text fields had to be varchar(MAX), unequivocally.
  • numbers were either int or double, even when you could have used other type.
  • "boolean" fields (bit) were int, no reason.
  • stored procedures had to be prefixed sp_productname_

asp.net / c# / javascript

  • EVERY single function had to be wrapped in try{}catch{}, so the applications wouldn't "explode" (at least that was the official reason), even when this produced things not working and not having a clue why.
  • parameters must be prefixed with p, e.g pCount, pPage
  • scope variables had to be prefixed with w (as in "working", what the hell does that even mean?)
  • statics with g, etc.
  • everything post framework 1.1 was offlimits, like you had any real uses for linq and generics anyways. (I made it a point to enforce them to let me use jquery though, I succeded at that, at least).
  • If your DBMS was MS SQL Server then there is a reason to avoid bit - it cannot be part of an index, whereas a tinyint can be part of an index and you can add a CHECK constraint to restrict it to the values 0 and 1. +1 for the try/catch rule. – finnw Nov 19 '10 at 12:25
  • I can guarantee that wasn't the issue at all, in fact all numeric fields were int (even fields supposed to be decimal), which led to obscure errors in the math department. – bevacqua Nov 19 '10 at 13:27
  • What a bunch of clueless idiots! I especially hate the "p" prefix for a parameter (code I am working on is full of that, sometimes with underscores sometimes without, sometimes without a p in general). Do people not understand that all of this pseudo-Hungarian Notation crap can be invalidated if you actually name things meaningfully?? – Wayne Molina Jun 2 '11 at 15:54

I currently work in a company where SQL queries are done through something called "Request Class". How ridiculous:

In "include/request.class.php"

class RequestClass
    // ... some code.

    public function getUser($where)
        global $initrequest

        $sql = $initrequest['users']
        $sql.= $where;

        return execute($sql);

In initrequest.php:

$initrequest['users'] = 'SELECT * FROM users WHERE ';

And it was called from the application in this way:

$request = new request();
$tmpquery = "username = $username AND password = $password";

And they have a similar template system based in "blocks", but after understanding what I show here, I kept pressing to trash our whole software and rewrite it in Symfony.

  • BTW I forgot to say that this is properly indented because I wrote it that way. Don't expect that in the production code. – Arie Deckelmann Sep 9 '10 at 17:50

Where I'm working now the variable naming process for anything dealing with the database is:

  • $sql for statements
  • $result for query results

Which makes sense, however when I brought up the point that the convention was too generic and that this would end up with variable overlap the response was "use result_alt or sql_alt." My feelings on commenting, if you used proper variable names that signify purpose you wouldn't need comments or as many of them.


Having what amounted to C header files, in a Java project.

Interfaces exist for some good reasons, but this standard mandated an interface (foo.java) for every single class (fooImpl.java) whether it made any sense or not. Lots of stuff to keep in sync, complete disruption of Eclipse click-into-method, pointless busy-work.

The build system enforced it, but I cannot imagine what the original purpose was. Fortunately we ditched it for new code when we switched to a new version-control and build system, but there's still a lot of it about.

At the same time we also ditched the stupid version-control-info-in-file-comments habit which had been mandatory.

  • If you are using Eclipse, you also have "Extract interface" and "Pull up" and if there is only one implementation you will only get one result for "Find implementing methods." I agree this would be a pain in some editors, but not in Eclipse. And interfaces must be the #1 "Holy War" issue for Java coders. – finnw Sep 9 '10 at 18:51
  • This only makes sense if your creating a library, honestly, where you want any one class to be easily replacable simply by implementing the correct interface. Secondly, it is the interface that should be named weirdly, like IFoo or FooInterface or something... – alternative Sep 9 '10 at 22:47
  • @mathepic, I disagree because the interfaces tend to be referred to more often than the classes (for example you often see void someMethod(Set<X> s) but not void someMethod(HashSet<X> s)) and if you use the plain name for the class it can be ambiguous (is class Set<X> a tree or a hash table? And what if you already have one in your library and want to add the other?) – finnw Sep 10 '10 at 9:14
  • 2
    +1 to rally against the belief that every class someone writes might some day be part of an far-reaching public API of global importance and therefore needs a rigid interface separate to its implementation... as if it's destined for the IETF or something. Most of time I see "Impl", it makes my blood pressure go up because this tells me you didn't write the interface to specify class compliance (good), you did it to because "everything is a framework" (bad+wrong). – charstar Sep 13 '10 at 23:00
  • 1
    "Find Implementing Methods" is all very well, but it's not much help when you see foo.frobnosticateWith(bar);, ctrl-click on frobnosticateWith, and find yourself at the interface definition of the method rather than the implementation you wanted to see. It's fine when interfaces are being used for good, and maybe there are (or could be) multiple implementations, but this is not the case here. – user763 Oct 5 '10 at 16:28

The worst coding standard I ever had to follow was "All object variable names must be prefixed with 'obj'". This was on a big Java project, so almost everything was an object. The worst part was, almost everyone adopted a policy of naming variables by simply prepending "obj" to the class name. We wound up with stuff like Person objPerson1 throughout the code. I objected once, and had one of the other developers interject that she liked the convention "because then I don't have to think about my variable names". That place was a real horrorshow...

  • Sounds very painful since everything inherits from Object... that's a short lifespan on your 'o' 'b' and 'j' keys :) – anon Aug 21 '11 at 23:19

Maybe The Huawei Software Company's coding standard. They want you to declare all members public:))


Writing anything in Fortran (WATFOR, FORTRAN 77) where a non-whitespace character in column 1 was a comment, and the compiler didn't warn you if you went beyond column 72, it would just silently ignore it.

At least I only spent seven years doing this.

  • Ouch - How much time did you waste? – Basic Oct 4 '10 at 10:32
  • It's a bit fuzzy, being this happened almost 20 years ago. You also need to know that a non-whitespace character in col 6 was a continuation of the previous line. I had an if statement that spanned multiple lines and what was out beyond col 72, when you ignored it, was still syntactically correct, so the compiler wasn't really wrong, but it could have put out a warning. I spent a total of about four hours figuring this out. This was on an HP-1000 mini running RTE. – Mark Thalman Oct 5 '10 at 12:10
  • That's not a coding standard so much as either a language or compiler problem. I assure you that if you'd been using punch cards with an 029 keypunch and a proper control card, you'd never have had that problem. – David Thornley Nov 15 '10 at 22:51
  • I missed punch cards by a half dozen years or so. My first programming class was taught on Commodore Super Pets with a cassette tape for storage. – Mark Thalman Nov 16 '10 at 15:48
  • Isn't being restricted to certain columns a coding standard? – Mark Thalman Nov 16 '10 at 15:48

My favorite would have to be the database naming guidelines we currently are trying to abide by. All tables used for many-many relationships should be named using the names of the linked tables and must be suffixed with "Link". And of course, no pluralization of table names.

  • OrderLines? Nope. It should be called OrderProductLink
  • Friends? Nope. It should be PersonPersonLink
  • 1
    How about a friend of a friend? PersonPersonLinkPersonLink? – Billy Coover Sep 16 '10 at 21:41
  • @CodingInsomnia What's the name of the Enemies table? Also PersonPersonLink? – Max Nanasy Aug 10 '12 at 7:51

"Do not use C++ comment style for C code".

While this may still have a small value if there is risk of needing to port your program to an obsolete compiler, it's mostly just a hassle. My biggest objection is that it makes it really hard to use /* to block comment out a large region during development or unit testing. */

  • +1. One of my projects came 'full circle". The original C compiler allowed only /* comments. Then an upgraded version allowed // comments. Then // comments were deprecated because the compiler vendor wanted to follow the standard more strictly. Then eventually we switched to another C99 compiler. Then we adopted another standard where /* comments were deprecated. Each time we had to change all comments in the whole project. Fortunately the project was relatively small (~200K LOC) – finnw Sep 10 '10 at 18:44
  • 4
    I use #if 0 and #endif to block out regions, myself. – David Thornley Sep 23 '10 at 15:01

No more than one line of code allowed in Main()

A professor at my university who I was fortunate enough not to have insisted that her junior C# students not be allowed to put more than one line of code in their console applications' entry point.

This makes a reasonable amount of sense when developing a professional application, but when the program's only intent is to take few basic inputs and produce a single output (i.e. MultiplyTwoNumbers.exe), such a requirement is more pain than good.

On top of the "one line of code in main" the professor also insisted that every line of code have a descriptive comment and every class member have a verbosely descriptive name. Points lost if the professor didn't feel that these requirements had been met "adequately".

The students forced to stick to these rules were (almost) all newbies to programming and thus I can see the value of enforcing conducts like good-naming and separation of concerns. Despite that, as the .NET Tutor at my university I was constantly helping her students meet these mundane and obnoxious requirements long after they had gotten their code working.

In my opinion, when educating someone who is brand new to a programming language the first concern should be how to create code, not how to create standards-based code.

  • 4
    Sorry, that isn't standards-based code. That is crazy-based code. – configurator Sep 29 '10 at 4:29
  • Write a program and just remove al newlines using find & replace before showing it to your teacher. – rightfold Aug 12 '11 at 14:36
  • I wonder how many programs simply called a function called Main2() or something like that... – anon Aug 21 '11 at 23:16


All return values had to be HRESULTS (the standard ones - not user defined hresults)

This was just a few years ago. The senior people were still so infatuated with COM and they never read or learned of other best practices. It was an amazingly closed environment.

The same place also did not allow using STL.

I left shortly after I found out that tidbit.


My ADA lecturer at uni insisted that every method had a comment outlining preconditions, postconditions and big O. The biggest issue with this was that he never bothered to explain what big O actually meant and never checked if they were correct so I found myself copying and pasting this comment block hundreds of times.

-- Method_Name
-- O(n) = n

In Visual Basic 6.0, we had to add error handling blocks to every single method. No exceptions. So we did.

Then we had to explain why parts of the application were slow.

  • No problem. ON ERROR RESUME NEXT – configurator Sep 29 '10 at 4:24

Limited space for variable/object names is probably my largest irritation. I've worked in a relatively modern, proprietary language that only allows 10 characters. This is a holdover from its original versions.

The net result is that you end up with funny naming conventions defining what each character of your allowed 10 is to represent. Something like:

  • 1-3: application prefix
  • 4-6: module prefix
  • 7-9: user defined section
  • 10: a number just in case two...or 9 are named the same thing.
  • I know this is prevalent in online PLC programming due to limited storage space, but what modern language limits namespace like this? Why 10? – Christopher Jul 8 '11 at 14:58

At one company we had to write technical documenation that explained how we will write a functionality. It fast got out-dated since you wont think about everything when youre programming in UML.


Being forced to add a file description in each file (it's a C# project).

// --------------------------------------------------------------------------------------------------------------------
// <copyright file="User.cs" company="Company">
//   Copyright (C) 2009 Company. All rights reserved.
// </copyright>
// <summary>
//   The user.
// </summary>
// --------------------------------------------------------------------------------------------------------------------
  • I can sorta see the copyright bit, but I'm pretty sure you can have Visual Studio do it for you. – Matt Olenik Sep 13 '10 at 23:30
  • 1
    Or a macro. Is this that bad? Think about why your company needs this - if a Google search for 'Copyright <my company>' turns up something... – JBRWilkinson Oct 15 '10 at 21:41

I find many of the Mono coding guidelines to be pointless or counter-productive. For example:

  • 80 column limit - considering we're all using widescreen monitors these days is just wasting the limited vertical space we don't have, and not making use of the horizontal space we do have.
  • Tabs for spaces - perfect way to make your code look like a mess when opened in different editors which have different tab sizes. (Also, eight space tabs is just wasting the very limited 80-columns you have to work with anyway).
  • Inconsistent brace positioning, for what reason? What's wrong with 1TBS?

There are a number of other guidelines there which are just "good practices", without reasoning.

  • 6
    There is good readability reasons for limiting the width of text, but should be a guideline to avoid indefinitely long lines rather than a hard limit. – Richard Sep 9 '10 at 7:09
  • sparkie, turn your two monitors sideways? – Peter Boughton Sep 9 '10 at 17:10
  • 4
    I prefer tabs over spaces just so that, if my co-worker likes 2 space indentation and I prefer 4, we can just set our editors to be different. – Ben Doom Sep 9 '10 at 18:22
  • 5
    Am I the only person who likes 80 column limits because that way I can have multiple files open side by side, and so side-by-side diffs can be displayed without line wrapping? – nohat Sep 10 '10 at 2:11
  • 2
    If your using tabs, you don't have to make them 8 spaces. – alternative Sep 10 '10 at 22:27

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