Forums
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.
"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:
Apr 22 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;
}