Forums
Matt P was spending a few hours trawling through a Java code base, working through the poorly documented logic and the bugs and the odd conventions. It was the kind of code base that rightly eschewed "magic numbers", favoring constants, but was also the kind of code base which took that to an extreme which arguably didn't help readability.
For example:
In many places, driver's licenses work on a point system. As you commit infractions, you gain or lose points, when your point score hits a certain threshold, your insurance company raises your rates or you may even lose your driver's license. Where Christopher Walker lives, you start with twelve points, and each infraction takes a few away. Once a year, you have the option to attend a workshop on safe driving, where you can then regain a few of those points.
It's complicated and tedious, so several organizations, from the local department of motor vehicles to various insurance companies, have set up systems to manage this information. One of those organizations built a PHP application about fifteen years ago, and it gradually grew in kruft and complexity and confusion from that point forward. It works, but it's entirely unmaintainable.
Linda discovered a new anti-pattern, helpfully explained with comments.
Apr 22try {
this.initializeConfig(this.configFile);
} catch (ADWException e) {
// something went terrible wrong... but we go on, since
// following errors will be thrown.
}
Kerin inherited a scheduling application for a university. This application stored the scheduled days for a class in the database… as one comma-separated field. This was a problem for Kerin, who was hired to add predictive scheduling and classroom density measurements to the system.
This particular function was written to take that data and transform it for display. Sort of.
Nullable types, at least in theory, make our code simpler and easier to maintain. If nothing else, we know when there's a risk of a null value, and can handle it with some grace. At least, that's how it works if we understand what they do.
Boaz's co-worker knows that nullables are valuable, but doesn't quite get it.
"Don't concatenate long strings," is generally solid advice in most languages. Due to internal representations, strings are frequently immutable and of a fixed length, so a block like this:
string s = getSomeString();
s = s + "some suffix";
Martin's company had written a set of command line tools which their internal analysts could then string together via shell scripts to do their work. It was finicky and fragile, but frankly didn't work too badly for most cases.
There was one tool, however, which seemed to be the source of an unfair number of problems. Eventually, Martin sat down with an analyst to see what was going wrong. The program would exit successfully, but wouldn't actually do any of the work it was supposed to. Instead of doing the normal thing and writing errors to STDERR, the tool wrote to a file. Which file, however, was determined by reading some shell variables, but the shell variables used by each of the tools were slightly different, because why would you build a consistent interface for your suite of analytical tools?
Let's say you saw a method called StrToGuid, in a C# codebase. Your first thought might be: "Wait, isn't there a built in parse? Well, I guess maybe they might do some sort of exception handling. But it still doesn't seem right." And then you'd take a look at the method signature and see that it takes both a string, and an integer named counter, and you'd think: "Wait, what?"
Henrik H had a similar experience. His team hired a new developer, someone with 15+ years of experience. This is what they contributed to the codebase:
"There are a few more functions like this in the same file," writes Jenny, about today's submission. This is one which largely does speak for itself.
const gright = () => {
setIscountright(isCountright + 1);
if(isCountright === 0) {
setIsleft(!isLeft);
setIsfirstdot(!isFirstdot);
setIssecdot(!isSecdot);
setInfof('Once activated buttons on the right panel will appear');
setIssquareleft(!isSquareleft);
setIsanimBottRightIn(!isAnimBottRightIn);
}
if(isCountright === 1) {
setIssecdot(!isSecdot);
setIsthirddot(!isThirdtdot);
setInfof('Tap on them to change content of the projection on the wall');
setIselmscale(!isElmscale);
setIssquareleft(!isSquareleft);
setIsmap(!isMap);
setIsmapdot(!isMapdot);
setIsborderwhite(!isBorderwhite);
}
if(isCountright === 2) {
setIsright(!isRight);
setIsthirddot(!isThirdtdot);
setIsfourthdot(!isForthdot);
setInfof('Use the menu bar in top left corner to switch between pages');
setIssquareleft(isSquareleft);
setIsanimBottRightIn(!isAnimBottRightIn);
setIselmscale(!isElmscale);
setIsmap(!isMap);
setIsmapdot(!isMapdot);
setIsborderwhite(!isBorderwhite);
setIsindicator(!isIndicator);
setTimeout(():void => {
setAnimain(false);
setMainsec(true);
setIsindicator(false);
setIsindicator2(true);
}, 1000);
setTimeout(():void => {
setMainsec(false);
setMainth(true);
setIsindicator2(false);
setIsindicator3(true);
setShowdone(true);
}, 2200);
}
}
Austin's team received a bug report. When their C# application tried to load certain settings, it would crash. Now, since this was a pretty severe issue in their production software, impacting a fair number of customers, everyone on the team dove in.
It didn't take Austin long to spot the underlying problem, which isn't quite the WTF.
In the endless quest to get asynchronous operations right, we're constantly changing approaches. From callbacks, to promises, to awaits, to observables. Observables are pretty straight forward: we observe something, like a socket or a HTTP request, and when something happens, we trigger some callbacks. In a lightly pseudocode version, it might look something like:
requestFactory.postFormRequest(url).subscribe(
resp => myResponseHandler(resp),
err => myErrorHandler(err),
() => myRequestCompleteHandler()
)
Lacy's co-worker needed to collect groups of strings into "clusters"- literally arrays of arrays of strings. Of great importance was knowing how many groups were in each cluster.
Making this more complicated, there was an array list of clusters. Obviously, there's a code smell just in this data organization- ArrayList<ArrayList<String[]>> is not a healthy sounding type name. There's probably a better way to express that.
Giles's company has a hard time with doing things in the database.
In today's example, they attempt the very challenging task of generating unique IDs in a SQL Server database. Now, what you're about to see follows the basic pattern of "generate a random number and see if it's already been used", which is a fairly common anti-pattern, but it's managed to do this in some of the worst ways I've ever seen. And it can't even hide behind the defense of being written a long time ago- it's a handful of years old.
Carolyn's company has a bunch of stringly-typed enums. That's already a problem, even in Python, but the other problem is that they need to display these in a human readable format. So, "ProductCategory" needs to become "Product Category". Now, it's true that every one of these stringly typed enums follows the PascalCase convention. It's also true that the list of them is constantly growing.
So this is the method someone wrote for formatting:
Steve's predecessor knows: sometimes, stuff happens that makes you go "WTF". While Steve was reviewing some inherited PHP code, he discovered that this predecessor had built some code to handle those situations.
namespace WtfInc;
##use \Exception as Exception;
class WTFException extends \Exception
{
public function __construct($message = null, $code = null)
{
if (! $message) {
$message = "WTF!?";
} else {
$message = "WTF!? " . $message;
}
parent::__construct($message, $code);
}
}
When companies reinvent their own accounting software, they usually start from the (reasonable) position of just mirroring basic accounting processes. You have transactions, for an amount, and then tagged with information about what the transaction actually represents. So, for example, if you wanted to find all the transactions which represent tax paid, you'd need to filter on some metadata and then sum up the amounts.
It quickly gets more complicated. In some organizations, that complexity keeps growing, as it turns out that each department uses slightly different codes, the rules change over time, this central accounting database gradually eats older databases which had wildly different rules. Before long, you end up with a database so krufty that it's a miracle SQL Server doesn't just up and quit.
Shery sends us perfectly innocent looking Java class, marked up with some annotations. The goal of this class is to have an object which contains a list of names that is definitely not null. Let's see how we did.
@Data
@Builder
@NoArgsConstructor
@AllArgsConstructor
public class NamesHolder {
@NotNull
private List<String> names;
}