David inherited a codebase that's a few decades old. As each developer has taken it over, they've done their best to follow the code standards that the previous developers used, to at least keep the codebase consistent. A few rebels may have gone a different route, like the right one, but too many just followed the patterns that were already there.

This means that there are a lot of variables named things like a and aa and aaa. There are 4,000 line functions and loads of copy/pasted code.

We've all seen the empty catch block, the "swallow errors and ignore them". David sends us a "superior" example of that anti-pattern, with several bonuses to make it even more of a WTF.

/**
 * Insert the method's description here.
 * @param bean java.lang.Object
 * @param bean_template java.lang.StringBuffer
 * @param bufXML java.lang.StringBuffer
 */
protected static void appendBeanTemplate(Object bean, StringBuffer bufXML) {

      int                                            iEndTag;
     StringBuffer  xmlTemplate = new StringBuffer();
        
 try {
               iEndTag = bufXML.toString().lastIndexOf("</" + getClassName(bean) + ">");
           writeChildBeanDescription(bean, xmlTemplate);
         bufXML.insert(iEndTag, xmlTemplate.toString());     
      }
      catch (Exception e) {
                try {
                      throw new Exception("Error creating xml bean description.");
               }
               catch (Exception ex) {
                }
        } 
}

There are certain things I can't remember for the life of me. For example, as per yesterday, the number of nanoseconds in a millisecond.

One of the other is the specific little formatting tokens for printf. I use it all the time, but the various riffs on %d escape my brain faster than I can put them in. Even just getting the hex values dumped for debugging requires a search. But I at least do that search, unlike Mike's co-worker.

There's bad date handling, which frequently involves reinventing date handling yourself, frequently using strings or integers along the way. Then there's the bad date handling which uses the date handling framework, and still manages to be bad.

This C# comes from TheColonial.

When looking at code which juggles threads, there are definitely a few red flags. sleeps spammed through the code is an obvious one- either wait on a shared resource or block on another thread or something, but spurious sleeps are suspicious.

Until today, I would not have included "atomic operations" as a code smell in multi-threaded code, but we all learn new things.

Code changes over time. As business requirements change, you need to update your code to reflect that, and the best way to do that is to structure your code and plan for changes before you even know what changes you need to make. Making your code flexible and changeable without making it meaninglessly abstract is the real art of software development.

Unless you're the document management provider that Daef works with. They have a very different approach for how they integrate new features and custom code paths.