76
votes

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

3
  • 4
    I've asked a similar question (but not exactly the same) on SO before by the way: stackoverflow.com/questions/218123/… Sep 8, 2010 at 16:30
  • @Brian, thanks, I had seen your question but forgotten about it.
    – finnw
    Sep 8, 2010 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, 2010 at 16:07

56 Answers 56

97
votes

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.

25
  • 12
    I find (at least now, earlier at school that seemed strange) that Commenting altogether is a bad practice Sep 9, 2010 at 15:52
  • 14
    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, 2010 at 16:50
  • 13
    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, 2010 at 18:09
  • 5
    @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. Sep 9, 2010 at 23:27
  • 7
    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, 2010 at 16:53
128
votes

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
if(x>2){

    //Print x
    Print(x);
}

It was pretty ridiculous.

18
  • 10
    Isn't this just so the professor knows that you know exactly what is going on? Sep 8, 2010 at 18:13
  • 80
    I think it's clear what's going on, and it ain't education.
    – Dan Ray
    Sep 8, 2010 at 19:09
  • 18
    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. ;-) Sep 8, 2010 at 19:55
  • 4
    Yeah, except you can always write comments that just repeat the code and don't show any understanding. Does he make you right "// Ending Brace" before the ending brace? Sep 8, 2010 at 21:07
  • 6
    What if you've accidentally got a useful comment in your code? Do you need to put // comment on the line before that? Sep 29, 2010 at 3:49
102
votes

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.

15
  • 11
    I tried to up vote this a dozen times...
    – TGnat
    Sep 9, 2010 at 17:54
  • 22
    If you think you need #REGION, I think you need to refactor.
    – Jay Bazuzi
    Sep 9, 2010 at 19:56
  • 23
    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. Sep 11, 2010 at 8:23
  • 26
    We have a simple coding standard: never nest regions. Just use them to group related methods (initialisation, serialisation, properties, etc) Sep 11, 2010 at 21:53
  • 6
    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: stackoverflow.com/questions/523220/awesome-visual-studio-macros/…
    – Kyralessa
    Sep 29, 2010 at 1:28
80
votes

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)

19
  • 14
    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, 2010 at 23:32
  • 71
    No vowels??! You’re joking, right? Sep 9, 2010 at 17:37
  • 39
    Did the people who enforced this standard have ridges on their foreheads and often discuss honour and battle? Sep 9, 2010 at 18:13
  • 10
    Haha, well they were DBAs, so... ;)
    – Damovisa
    Sep 9, 2010 at 21:49
  • 14
    You should have sent your column names through a url shortner. PersonFirstNameVarchar30NotNull = bit.ly/cULlQc Sep 16, 2010 at 16:42
47
votes

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

e.g:

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

    while (baz)
    {
       farb();
    } // End while (baz)
} // End For
11
  • 21
    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, 2010 at 19:56
  • 5
    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, 2010 at 20:06
  • 7
    that was a great idea for a world with no powerful IDE.
    – IAdapter
    Sep 9, 2010 at 22:17
  • 9
    @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. Sep 11, 2010 at 8:32
  • 3
    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, 2010 at 19:55
37
votes
#define AND  &&
#define OR   ||
#define EQ   ==

'nuff said.

13
  • 9
    Wouldn't #include <iso646.h> be much better choice?
    – AndrejaKo
    Sep 8, 2010 at 19:48
  • 3
    @AndrejaKo: this predated <iso646.h>; this was an attempt to make C look like FORTRAN.
    – Niall C.
    Sep 9, 2010 at 2:00
  • 2
    Was this really a coding standard? i.e. was there a company policy against writing the operators directly?
    – finnw
    Sep 9, 2010 at 9:13
  • 21
    Did it also have #define BEGIN { and #DEFINE END } ? Sep 9, 2010 at 9:37
  • 3
    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. Apr 13, 2011 at 18:28
36
votes

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

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

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.
13
  • 2
    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 Sep 9, 2010 at 17:55
  • 3
    wait.. in all seriousness, I thought SP's WERE better, performance-wise, than straight SQL calls from, say, C#?
    – Sk93
    Sep 10, 2010 at 8:14
  • 3
    Sounds like you know exactly why they were included. :P Sep 10, 2010 at 23:38
  • 4
    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.
    – Jé Queue
    Sep 16, 2010 at 17:19
  • 3
    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. Sep 29, 2010 at 4:01
36
votes
  • 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.’”
7
  • 3
    +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, 2010 at 18:43
  • 1
    Exactly. (Though in this case, reading umpteen variablenameslike thiscanreally adduptoquitea greatburden.) Sep 9, 2010 at 18:58
  • 57
    Amuse yourself by inventing names than be parsed two ways. pageshits, penisup, etc.
    – Jay Bazuzi
    Sep 9, 2010 at 19:59
  • 4
    @Jay *sexchange Sep 29, 2010 at 4:04
  • 2
    @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, 2010 at 6:33
33
votes

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.

3
  • 5
    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. Sep 13, 2010 at 23:18
  • 1
    @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. Oct 14, 2010 at 18:00
  • I'd tell him to code it himself.
    – user4595
    Aug 12, 2011 at 14:30
31
votes

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      }
14
  • 5
    Ow ow ow ow ow ow! Sep 9, 2010 at 17:57
  • 22
    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, 2010 at 18:54
  • 8
    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. Sep 11, 2010 at 21:51
  • 5
    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 Sep 29, 2010 at 3:59
  • 3
    @configurator: Joel's example is horrid, he'd be better off having different types, then the compiler would enforce the use. Oct 14, 2010 at 17:57
28
votes

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

WTF.

5
  • 93
    I once worked in a language that required every variable – EVERY variable – be prefixed with "$".
    – nohat
    Sep 10, 2010 at 2:03
  • 6
    @nohat: And you realized that it was amazing, didn't you?
    – Josh K
    Sep 20, 2010 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. Sep 23, 2010 at 14:51
  • 3
    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, 2010 at 19:37
  • 1
    Sounds like various versions of Perl...
    – user1249
    Sep 26, 2010 at 22:06
26
votes

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.

2
  • 2
    This is a horrible policy. I hope this manager was canned.
    – Bernard
    Mar 16, 2011 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, 2011 at 17:54
24
votes

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.

17
  • 13
    'Validations the handler' - uh-oh
    – Eric
    Sep 8, 2010 at 21:46
  • 8
    +1 Ugh I hate this. I think if your using software to generate comments then you dont need them.
    – bleevo
    Sep 8, 2010 at 23:40
  • 9
    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, 2010 at 9:18
  • 3
    @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, 2010 at 13:27
  • 7
    Classic case of undocumentation. Comments that don't tell anything apart from the blatantly obvious should be killed on sight.
    – Cumbayah
    Sep 9, 2010 at 17:05
23
votes

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.

2
  • 6
    And no one was aware of svn log?
    – Htbaa
    Mar 16, 2011 at 14:51
  • 1
    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, 2011 at 11:06
20
votes

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?

4
  • 3
    I've been deleting a lot of old commented out code recently. Oct 5, 2010 at 20:03
  • 2
    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. Oct 6, 2010 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 Apr 13, 2011 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, 2013 at 17:39
17
votes

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.

16
votes

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.

6
  • That's pretty heinous Sep 11, 2010 at 8:31
  • 5
    Mmm. Dim Sum... Sep 29, 2010 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. Oct 31, 2010 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). May 20, 2011 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. Jun 2, 2011 at 15:43
14
votes

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
{
   public:
      void MyClass_Public_setValue(int value);
}
2
  • 1
    Did you ask them why? I'd just love to know their motivation.. Oct 15, 2010 at 21:42
  • 1
    Wow, why is that guy even using classes? Nov 21, 2010 at 23:51
9
votes

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.

2
  • That's a horrible, horrible coding standard to have to follow. And a stupid reason for it, too!
    – gablin
    Sep 23, 2010 at 21:00
  • 4
    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, 2011 at 15:11
8
votes

Being required to indent all code by four spaces ;)

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

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

4
  • 7
    Do not mock older dinosaurs, please. They made us possible.
    – P Shved
    Sep 11, 2010 at 7:24
  • 4
    Sounds like job security.
    – MIA
    Sep 24, 2010 at 1:22
  • 7
    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. Sep 29, 2010 at 4:20
  • 2
    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, 2010 at 1:12
8
votes

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.

2
  • Is either company still running today?
    – finnw
    Oct 4, 2010 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, 2010 at 3:59
6
votes

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!

5
  • 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, 2010 at 18:11
  • 1
    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, 2010 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, 2010 at 22:01
  • 1
    +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. Sep 9, 2010 at 22:32
  • 6
    Sigh... another one of those "IDE's are for pussies" people.
    – Nailer
    Sep 23, 2010 at 13:41
6
votes

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.

6
votes

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.

6
votes

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!

6
  • 9
    You'd be hard pressed to return something from a function declared as void. Sep 9, 2010 at 18:16
  • 7
    @MAttB Consider under what conditions the final (else) branch would be taken.
    – Richard
    Sep 9, 2010 at 19:52
  • 6
    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"); Sep 10, 2010 at 19:23
  • 1
    This is horrific. What's wrong with return verbose ? someString : someOtherString;? Sep 24, 2010 at 10:45
  • 1
    @callum Ternary operator might be banned :) been there before...
    – hplbsh
    Jan 11, 2011 at 4:30
6
votes

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.

2
  • "Don't use confusing names" seems fair enough to me...
    – 8128
    Oct 2, 2010 at 15:15
  • 1
    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, 2010 at 15:00
4
votes

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."
2
  • 6
    What was wrong with the project lead's HeapSort?
    – 7wp
    Sep 9, 2010 at 18:02
  • 4
    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. Sep 9, 2010 at 22:17
4
votes

I'm forced to have XML documentation for all classes and class members. Including private. I'm encuraged to use default ghostdoc comments.

public class User 
{
    /// <summary>
    /// the _userID
    /// </summary>
    private int _userID;
}
3
  • Very similar to this earlier answer.
    – finnw
    Sep 10, 2010 at 9:18
  • Yes. All thou I'm required to comment private members also. Which makes even less sense. Sep 10, 2010 at 9:35
  • Encouraged to use ghostdoc?! Gah Sep 29, 2010 at 4:21

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