Recent CodeSOD

Code Snippet Of the Day (CodeSOD) features interesting and usually incorrect code snippets taken from actual production code in a commercial and/or open source software projects.

Nov 2021

Filtering Out Mistakes

by in CodeSOD on

We all make simple mistakes. It's inevitable. "Pobody's nerfect," as they say, and we all have brain-farts, off days, and get caught up in a rush and make mistakes.

So we use tools to catch these mistakes. Whether it's automated testing or just checking what warnings the compiler spits out, we can have processes that catch our worst mistakes before they have any consequences.

Are You Doing a Bit?

by in CodeSOD on

"Don't use magic numbers," is a good rule for programming. But like any rule, you shouldn't blindly apply it. We know what happens when people do, however: we get constants that might as well be magic numbers.

Still, there are sometimes novel versions of this old song. Shmuel F sends us this one in C:

Counting Arguments

by in CodeSOD on

Lucio C inherited a large WordPress install, complete with the requisite pile of custom plugins to handle all the unique problems that the company had. Problems, of course, that weren't unique at all, and probably didn't need huge custom plugins, but clearly someone liked writing custom plugins.

One of those plugins found a need to broadcast the same method invocation across a whole pile of objects. Since this is PHP, there's no guarantee of any sort of type safety, so they engineered this solution:

Templated Comments

by in CodeSOD on

Mike's company likes to make sure their code is well documented. Every important field, enumeration, method, or class has a comment explaining what it is. You can see how much easier it makes understanding this code:

/// <summary> /// Provides clear values for Templates /// </summary> public enum TemplateType { /// <summary> /// 1 /// </summary> TEMPLATE_1 = 1, /// <summary> /// 2 /// </summary> TEMPLATE_2 = 2, /// <summary> /// 3 /// </summary> TEMPLATE_3 = 3, /// <summary> /// 6 /// </summary> TEMPLATE_6 = 6, /// <summary> /// 8 /// </summary> TEMPLATE_8 = 8, /// <summary> /// 10 /// </summary> TEMPLATE_10 = 10, /// <summary> /// 12 /// </summary> TEMPLATE_12 = 12, /// <summary> /// 17 /// </summary> TEMPLATE_17 = 17, /// <summary> /// 18 /// </summary> TEMPLATE_18 = 18, /// <summary> /// 20 /// </summary> TEMPLATE_20 = 20, /// <summary> /// 32 /// </summary> TEMPLATE_32 = 32, /// <summary> /// 42 /// </summary> TEMPLATE_42 = 42, /// <summary> /// 54 /// </summary> TEMPLATE_54 = 54, /// <summary> /// 55 /// </summary> TEMPLATE_55 = 55, /// <summary> /// 57 /// </summary> TEMPLATE_57 = 57, /// <summary> /// 73 /// </summary> TEMPLATE_73 = 73, /// <summary> /// 74 /// </summary> TEMPLATE_74 = 74, /// <summary> /// 177 /// </summary> TEMPLATE_177 = 177, /// <summary> /// 189 /// </summary> TEMPLATE_189 = 189 }

A Sort of Random

by in CodeSOD on

Linda found some C# code that generates random numbers. She actually found a lot of code which does that, because the same method was copy/pasted into a half dozen places. Each of those places was a View Model object, and each of those View Models contained thousands of lines of code.

There's a lot going on here, so we'll start with some highlights. First, the method signature:

Efficiently Waiting

by in CodeSOD on

Alan was recently reviewing some of the scriptlets his company writes to publish their RPM installers. Some of the script quality has been… questionable in the past, so Alan wanted to do some code review.

In the uninstallation code, in the branch for AIX systems specifically, Alan found a block that needs to check that a service has successfully shut down. Since properly shutting down may take time, the check includes a pause- implemented in an unusual way.

A Select Sample

by in CodeSOD on

"I work with very bad developers," writes Henry.

It's a pretty simple example of some bad code:

It's Not What You Didn't Think it Wasn't

by in CodeSOD on

Mike fired up a local copy of his company's Java application and found out that, at least running locally, the login didn't work. Since the available documentation didn't make it clear how to set this up correctly, he plowed through the code to try and understand.

Along his way to finding out how to properly configure the system, he stumbled across its logic for ensuring that every page except the login page required a valid session.

Giving Up Too Late

by in CodeSOD on

"Retry on failure" makes a lot of sense. If you try to connect to a database, but it fails, most of the time that's a transient failure. Just try again. HTTP request failed? Try again.

Samuel inherited some code that does a task which might fail. Here's the basic flow:

Delete Column From List

by in CodeSOD on

Anastacio knew of a programmer at his company by reputation only- and it wasn't a good reputation. In fact, it was bad enough that when this programmer was fired, no one- even people who hadn't met them- was surprised.

The firing wasn't all good news, though. That code needed to be maintained, and someone had to do it. That's how Anastacio suddenly owned 50,000 lines of code written by his predecessor. It didn't take long to see that this didn't need to be anything like 50,000 lines long, though.

Bad Code Exists

by in CodeSOD on

It's time to round up a few minor WTFs today. Some are bad, some are just funny, and some make you wonder what the meaning of all of this actually is.

We'll start with Tom W. After winning a promotional contest at a fast food restaurant, he received a confirmation email. Unfortunately, at the top of that email, was the following content in plaintext:

Bop It

by in CodeSOD on

Over twenty years ago, Matt's employer started a project to replace a legacy system. Like a lot of legacy systems, no one actually knew exactly what it did. "Just read the code," is a wonderful sentiment, but a less practical solution when you've got hundreds of thousands of lines of code and no subject-matter experts to explain it, and no one is actually sure what the requirements of the system even are at this point.

There's a standard practice for dealing with these situations. I'm not sure it should be called a "best practice", but a standard one: run both systems at the same time, feed them the same inputs and make sure they generate the same outputs.

A Replacement Operation

by in CodeSOD on

Apolena supports an application written by contractors many years ago. It tracks user activity for reporting purposes, as one does. They then want to report on this, because why else are you gathering this information?

The contractor supplied this query to do the work.

Unable to Focus

by in CodeSOD on

We've talked about Microsoft's WebForms in the past. Having used it extensively in the era, it was a weird mismatch, an attempt to get Visual Basic-style GUI designer tools attached to web applications, where button presses on the client side web page were exposed as events on the server side.

It also meant that you could manipulate the GUI objects on the server side, and the rendered HTML would represent that. So as part of processing a request, you might manipulate one of these "server side" controls. So, if you wanted to ensure that the search field had focus when the page loaded, you could simply invoke txtSearch.Focus() as part of handling the request.

Contractor's Leftovers

by in CodeSOD on

There once was a developer who had a lot of hustle. They put out a shingle as a contractor, knocked on doors, made phone calls, and targeted those small businesses that needed something a little more custom than just off-the-shelf could get, but didn't have the money to afford a larger dev shop.

And after finishing a handful of projects and building a reputation, this developer took a job at a large firm, in another town, and left a lot of unhappy customers with unfinished software behind.

A Repetition of Repetition to Repeat

by in CodeSOD on

Inheritance is often described as a tool for code reuse, and those discussions inevitably wander down an alley parsing out the nature of has a and is a relationships, when to favor composition, and how inheritance trees get fragile.

When Megan D inherited a Java application which had been largely untouched since 2006, she expected it to be full of all kinds of ugly problems. But they couldn't be that ugly- the software was used and well liked by the end users. Of course, it was hard to tell if they actually liked it, or had just been with it so long they'd adjusted to its flaws, because the whole workflow was extremely fragile and frequently failed.