A great reference on how not to code still is

How To Write Unmaintainable Code

Ensure a job for life ;-)

Roedy Green Canadian Mind Products

I am still amazed when browsing through code, how many people use one or more of the anti-patterns in it.

One example I came across was this piece of Delphi RTL code:

class function TMarshalUnmarshalBase.ComposeKey(clazz: TClass; Field: string): string;
begin
  if clazz <> nil then
    Result := clazz.UnitName + SEP_DOT + clazz.ClassName + SEP_DOT + Field
  else
    Result := '';
end;

So I did a quick search at in the Delphi RTL for clazz, then found these occurences, indicating not only the authors of them have been under a rock, but also the code reviewers:

• 98 in data\dbx\Data.DBXJSONReflect.pas
• 7 in data\dbx\Data.DBXTransport.pas
• 97 in data\rest\REST.JsonReflect.pas
• 3 in DUnit\src\TestFramework.pas
• 22 in indy\abstraction\IPPeerAPI.pas

I have seen similar things in many environments, even run-time libraries of others, though this is one of the worst examples and falls under the anti-pattern:

Thesaurus Surrogatisation

To break the boredom, use a thesaurus to look up as much alternate vocabulary as possible to refer to the same action, e.g. display, show, present. Vaguely hint there is some subtle difference, where none exists. However, if there are two similar functions that have a crucial difference, always use the same word in describing both functions (e.g. print to mean “write to a file”, “put ink on paper” and “display on the screen”). Under no circumstances, succumb to demands to write a glossary with the special purpose project vocabulary unambiguously defined. Doing so would be an unprofessional breach of the structured design principle of information hiding.

There is a great other anti-pattern in the document too:

Delphi/Pascal Only

: Don’t use functions and procedures. Use the label/goto statements then jump around a lot inside your code using this. It’ll drive ’em mad trying to trace through this. Another idea, is just to use this for the hang of it and scramble your code up jumping to and fro in some haphazard fashion.

Enjoy reading the anti-pattern descriptions, which are now maintained at [WayBack] GitHub – Droogans/unmaintainable-code: A more maintainable, easier to share version of the infamous http://mindprod.com/jgloss/unmain.html, as it was originally a multi-page hard to maintain set of small articles:

• [WayBack] unmaintainable code : Java Glossary
  • [WayBack] General Principles
  • [WayBack] Naming
  • [WayBack] Camouflage
  • [WayBack] Documentation
  • [WayBack] Program Design
  • [WayBack] Coding Obfuscation
  • [WayBack] Ambiguity
  • [WayBack] Testing
  • [WayBack] Choice of Language
  • [WayBack] Dealing With Others
  • [WayBack] Roll Your Own
  • [WayBack] Tricks In Offbeat Languages
  • [WayBack] Miscellaneous Techniques
  • [WayBack] Philosophy
  • [WayBack] The Shoemaker Has No Shoes
  • [WayBack] Contributors
  • [WayBack] Operation Termite

A lot of comments were posted because of it: [WayBack] Responses to Roedy’s Unmaintainable Code Essay

Via:

• [WayBack] How To Write Unmaintainable Code
• [WayBack] Naming Things | DevIQ:

  It is hard to overestimate the importance of choosing good names for source code elements in software development.  Much has been written on this topic, and it is often a source of great debate. […]

–jeroen