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 2017

Aarb!

by in CodeSOD on

C++’s template system is powerful and robust enough that template metaprogramming is Turing complete. Given that kind of power, it’s no surprise that pretty much every other object-oriented language eschews templates for code generation.

Java, for example, uses generics- essentially templates without the metaprogramming. What we still keep is compile-time type-safety, and all the benefits of generic programming, but without the complexity of compile-time code generation.


The Delivery Moose

by in CodeSOD on

We know stereotypes are poor placeholders for reality. Still, if we name a few nations, there are certain traits and themes that come to mind. Americans are fat, loud, gregarious, and love making pointless smalltalk. The English are reserved, love tea, and have perfected the art of queuing. The French are snobbish, the Japanese have weaponized politeness, the Finns won’t stand within ten meters of another human being at the bus stop, and so on. They can range from harmless to downright offensive and demeaning.

Laurent is Canadian, working for an insurance company. Their software is Russian- in that it comes from a Russian vendor, with a support contract that gives them access to a Russian dev team to make changes. While reviewing commits, Laurent found one simply labeled: “Fix some Sonars issue”.


Arrject

by in CodeSOD on

There are some submissions that we get, and we simply sit on, because there’s nothing much to say about them. They’re awful code, but there’s no major comments to be added. It’s clear and simple in its awfulness.

For example, you have some code that needs to display details about colleges around the US. Each College has a name, a full name, a short name, a state and city where it exists, and full names for those states and cities. You are likely reaching for an object to store that information, but why do that, when you can employ what I call the “Arrject Pattern”. Y’know, when instead of using objects, you use multiple arrays and store related data at the same index? Stuff like what Kevin found in his codebase:


The Generated JavaScript

by in CodeSOD on

Once upon a time, I discovered a bug in some JavaScript. I went off to investigate the source, only to find… the JS wasn’t coming from a file. It was being generated by a server-side method. Through string concatenation. It was a simple generation, something along the lines of:

jsCode += "location.href = 'foo?id=" + someIdField + "';\n";

Delebation

by in CodeSOD on

When faced with an API or programming paradigm that requires repetitive, boilerplate code, a developer is left with two options. They may refine or adapt the API/paradigm, using the idioms of their language to make something tedious and verbose into something elegant and clear.

Or they just automate it. If you have a mile of boilerplate that’s mostly the same across the application, just generate that. It’s like copy/paste, but, y’know… automatic.


One's Company

by in CodeSOD on

The more you learn about something, the less confident you often become in making statements about it, because you understand the complexities of the matter. If, for example, I asked you to help me refine my definition of how dates and times work, you know that many assumptions are wrong. Or if we tried to define what makes a string a person’s name, we’ll run into similar problems. This is even true for a value we’ve all probably seen implemented as a boolean value: gender. The more you learn about these subjects, the more complex and nuanced your understanding of them becomes. More and more, your answers start with, “It’s complicated…”.

Eugene was going through some code at a customer’s site, and he found that their business logic depended heavily on a flag ISCOMAPNY (sic), but there was no ISCOMPANY field anywhere in the database. There was, however, a SEX field on the customer records, implemented as an integer.


Lowest-Bidder Conversion

by in CodeSOD on

Circa 2003, or so, Annie’s employer contracted a lowest-bidder to produce a relatively massive .NET Web Forms project. The code was built, signed off, and chucked into production without any of the in-house developers being involved, despite being the team that would support it in the long term. There was no documentation, no knowledge transfer, and no code review.

Over the next few years, there was a rush of feature requests as gaps in functionality were found. A series of in-house developers passed through, doing their best to patch them in, but the original project’s code quality didn’t exactly make it maintainable, and since they were operating in a rush, they weren’t exactly improving the code quality.


The Distract Factory Pattern

by in CodeSOD on

The Gang-of-Four design patterns have an entire category of creational patterns, to handle the complexities of creating objects. And yes, it can get complicated, especially when we think in terms of the single-responsibility principle. Often, creating an instance of an class is itself so complex that we need a new class to do it.

Thus, we have the Factory pattern. And the Abstract Factory Pattern. And the Abstract Factory Factory Abstract Provider Bean pattern, if you’re using Spring. The purpose of these patterns is to add indirection between the client, calling code, and the creation of the objects- different concrete implementations can be instantiated, without the client code needing to worry about what actual type it received. Polymorphism wins the day. Code is more loosely coupled, because the client code never needs to name the concrete type it uses.


Switching the Search

by in CodeSOD on

We return to Virginia N’s refactoring efforts (previously: here, and here).

This code is elegant in its stupidity, combining two anti-patterns in one glorious, “No, don’t do that, whyyyyyyyyyy!”. To wit, the for-switch, and the “build SQL statements through string concatenation”:


An Academic Consideration

by in CodeSOD on

Becky is not a programmer, but a physicist. She works in academia, alongside other scientists. Modern science generally requires some sort of heavy computation, which means scientists write code. It’s often not very good code, but that’s just the nature of the beast. The code exists to provide an analysis, not to be deployed as an app to the masses.

Most of the time. A few civil engineers were working on a brand new Android app for traffic analysis, with plans to distribute it. Unfortunately, they had some problems, and wanted more experienced eyes. Becky set aside the Fortran77 she was working on to trace through their Java code, and found this: