Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

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

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

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 never heard also a lot of other words... – Wizard79 Sep 9 '10 at 18:58

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

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

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

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.

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
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
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
If your using tabs, you don't have to make them 8 spaces. – alternative Sep 10 '10 at 22:27

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!

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

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

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.

Mmm. Dim Sum... – configurator Sep 29 '10 at 4:06

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


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

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

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.


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.


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

Interfaces exist for some good reasons, but this standard mandated an interface ( for every single class ( 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.

+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
"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

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.

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

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.

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

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.

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

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
Yeah, StackOverflow has really bad coding standard. :-) – Pavel Shved Sep 11 '10 at 7:22

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

  • 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

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
How about a friend of a friend? PersonPersonLinkPersonLink? – Billy Coover Sep 16 '10 at 21:41

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

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

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.

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

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

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