For a change of pace, the code in this CodeSOD isn’t the real WTF. Our Anonymous submitter works for a company that handles meeting scheduling for corporate customers. This entails shipping off loads of HTML-emails, and that means using a relatively terrible WYSIWYG editor that generates code like this:

<p class="MsoNormal"><strong style="color: #003877;">Meals</strong></p>
<p class="MsoNoSpacing">
<span style="font-size:9.0pt;font-family:" verdana",sans-serif;="" mso-fareast-language:en-gb"="">
All breakfasts and lunches will be served in Food Capital on the ground floor of the hotel.
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;
</span></p>
<p class="MsoNoSpacing"><span style="font-size:9.0pt;font-family:" verdana",sans-serif;="" mso-fareast-language:en-gb"="">
We look forward to hosting you for the following dinners:
<o:p></o:p></span></p>

Writing quality database code is a challenge. Most of your commands need to be expressed in SQL, which is a mildly complicated language made more complicated by minor variations across databases. Result sets often have a poor mapping to our business logic’s abstractions, especially in object-oriented languages. Thus, we have Object-Relational-Mapping tools, like Microsoft’s EntityFramework.

With an ORM, you use an object-oriented approach to fetching your objects, and could write something like: IList<HJFRate> rates = db.HJFRates.where(rate=>rate.typeOfUse == typeOfUse) to return all the rows as objects. There’s no concern about SQL injections, no need to process the result set directly. While ORMs can generate poor SQL, or create really inefficient data-access patterns, their ease-of-use is a big selling point.

“Mrs S” works for a large software vendor. This vendor has a tendency to quickly increase staffing to hit arbitrary release targets, and thus relies heavily on contractors. Since they’re usually doing this during a time crunch, these contractors may have a… dubious skill set.

They also don’t care. There is no documentation, no tests, and no explanation. They are just paid tho write the code, not maintain it. They’ll be on another contract before long, so it’s some other schmuck’s problem.

Given the common need to have getter/setter methods on properties, many languages have adopted conventions which try and make it easier to implement/invoke them. For example, if you name a method foo in Ruby, you can invoke it by doing: obj.foo = 5.

In the .NET family of languages, there’s a concept of a property, which bundles the getter and setter methods together through some syntactical sugar. So, something like this, in VB.Net.