Coded Smorgasbord: What the Hmm?

Our stories come from you, our readers- which, it's worth reminding everyone, keep those submissions coming in. There's nothing on this site without your submissions.

Now, we do get some submissions which don't make the page. Frequently, it's simply because we simply don't have enough context from the submission to understand it or comment on it effectively. Often, it's just not that remarkable. And sometimes, it's because the code isn't a WTF at all.

So I want to discuss some of these, because I think it's still interesting. And it's unfair to expect everyone to know everything, so for the submitters who discover they didn't understand why this code isn't bad, you're one of today's lucky 10,000.

We start with this snippet, from Guss:

#define FEATURE_SENSE_CHAN (1 << 0)#define FEATURE_SENSE_PEER (1 << 1)

Guss writes:

The Asterisk open source telephony engine has some features that need to know from which direction they've been invoked in a two-way call. This is called "sense" in the Asterisk lingo, and there are two macros defined in the source which allow you to textually know if you're talking about this direction or the other. This of course stands for 1 and 0 respectively, but they couldn't have just simply go on and say that - it has to be "interesting". Do also note, as this is a macro, it means that whenever someone sets or tests the "sense", another redundant bit shift operation is done.

First, minor detail- this stands for 1 and 2 respectively. And what's important here is that these fields are clearly meant to be a bitmask. And when we're talking about a bitmask, using bitshift operators makes the code more clear. And we can generally rely on a shift by zero bits to be a no-op, and any compiler should be smart enough to spot that and optimize the operation out. Hell, a quick check with GCC shows that even the (1 << 1) gets optimized to just the constant 0x2.

Not a WTF, but it does highlight something we've commented on in the past- bitmasks can be confusing for people. This is a good example of that. But not only is this not a WTF, but it's not even bad code.

(Now, it may be the case that these are never really used as a bitmask, in which case, that's a mild WTF, but that's not what Guss was drawing our attention to)

In other cases, the code is bad, but it may be reacting to the badness it's surrounded by. Greg inherited this blob from some offshore contractors:

RegistryKey RK = Registry.LocalMachine.OpenSubKey("SOFTWARE\\XXXXX\\YYYYY");string BoolLog = "";if (RK != null)BoolLog = ((string)RK.GetValue("LogSocket", "")).ToLower();if (BoolLog == "true" || BoolLog == "yes" || BoolLog == "1"){...}

Now, seeing a string variable called BoolLog is a big red flag about bad code inbound. And we see handling some stringly typed boolean data to try and get a truth value. Which all whiffs of bad code.

But let's talk about the Windows Registry. It's typed, but the types are strings, lists of strings, and various numeric types. There's no strictly boolean type. And sure, while explicitly storing a 1 in a numeric field is probably a better choice for the registry than string booleans, there are reasons why you might do that (especially if you frequently need to modify Registry keys by hand, like when you're debugging).

The real WTF, in this case, isn't this code, but is instead the Windows Registry. Having a single tree store be the repository for all your system configuration sounds like a good idea on paper, but as anyone who's worked with it has discovered- it's a nightmare. The code here isn't terrible. It's not good, but it's a natural reaction to the terrible world in which it lives.

Sometimes, the code is actually downright awful, but it's just hard to care about too much. Rudolf was shopping for bulk LEDs, which inevitably leads one to all sorts of websites based in China offering incredibly cheap prices and questionable quality control.

The site Rudolf was looking at had all sorts of rendering glitches, and so out of curiosity, he viewed the source.

{\rtf1\ansi\ansicpg1252\deff0\deflang2055{\fonttbl{\f0\froman\fcharset0 Times New Roman;}{\f1\fswiss\fcharset0 Arial;}}{\*\generator Msftedit 5.41.21.2509;}\viewkind4\uc1\pard\f0\fs24 <html>\par\par<head> <meta http-equiv="refresh" content="1; url=http://totally-fine-leds-really-its-fine.ch"> \par

Here we see someone wrote their HTML in WordPad, and saved the file as an RTF, instead of a plain text file. Which sure, is bad. But again, we need to put this in context: this almost certainly isn't the page for handling any transactions or sales (that almost certainly uses a prebaked ecommerce plugin). This is their approach to letting "regular" users upload content to the site- frequently documentation pages. This isn't a case where some developer should have known better messed up- this is almost certainly some sales person who has an HTML template to fill in and upload. It probably stretches their technical skills to the limit to "Save As..." in WordPad.

So the code isn't bad. Again, the environment in which it sits is bad. But this is a case where the environment doesn't matter- these kinds of sites are really hoping to score some B2B sales in bulk quantities, and "customer service" and "useful website" isn't going to drive sales better than "bargain basement prices" will. They're not trying to sell to consumers, they're trying to sell to a company which will put these into consumer products. Honestly, we should be grateful that they at least tried to make an HTML file, and didn't just upload PDFs, which is usually what you find on these sites.

Sometimes, we don't have a WTF. Sometimes, we have a broken world that we can just do our best to navigate. We must simply do our best.

[Advertisement] Picking up NuGet is easy. Getting good at it takes time. Download our guide to learn the best practice of NuGet for the Enterprise.