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

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

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

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


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.


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

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

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


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

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

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

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


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

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

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.


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

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

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.


Almost forgot this one:

Quote from a manager:

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

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

This is a horrible policy. I hope this manager was canned. – Bernard Mar 16 '11 at 15:37

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

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

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

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

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.


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


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.

If you need to scroll horizontally (for example more than half a page) there's probably something wrong as well. No indenting isn't good either as it makes code completely unreadable. I try to stick with a 78-col limit, but if required to go over that amount I don't mind, but I do try to avoid it. – Htbaa Mar 16 '11 at 15:11


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.


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.

My head would explode. Seriously, WTF?! – Marcel Lamothe Sep 23 '10 at 15:21
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
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 M Jun 2 '11 at 16:00

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.


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.

Sometimes there are good reasons for including type information in variable names. – finnw Sep 14 '10 at 2:09
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

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.

Sorry, that isn't standards-based code. That is crazy-based code. – configurator Sep 29 '10 at 4:29

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