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.
One of the easiest ways to create a bug for yourself is to drop an empty catch into your application.
Today's rather short CodeSOD comes from Dex, and was found in a payment process. This is code that handles actual financial transactions, which is why the comment attached to a common mistake is relevant here:
Ilsa's organization uses Terraform to handle provisioning their infrastructure. This mostly works fine for the organization, but one day it started deleting their load balancer off of AWS for no good reason.
Ilsa investigated, but wasn't exactly sure about why that was happening. What she did find, however, was this particular ternary expression.
Tony sends us this snipped of C# code:
Feb 22 internal static bool TraceListner(ProjectInstance objPI,
Exception objError, int EntityID,
Enumerations.LogEntityType EntityType, int EntityInterfaceID,
Enumerations.LogReturnType ReturnType,
Enumerations.EventLevels EventLevel, string StartTime,
string EndTime, int UserID, string Description)
{
ProcessAudit objLog;
bool blnWrite;
try
{
// WRITE THE TRACE LOG IF PROCESS HAS AUDIT FLAG = TRUE
//AND THE CURRENT ACTIVTIY AUDIT FLAG = TRUE
// need to log all of the errors regardless of the activity
blnWrite = true;
// write to the log if it is an error type log
if (!(objError == null))
blnWrite = true;
if (blnWrite == true)
{
objLog = new PrjectAudit(objPI, objError, EntityID, Convert.ToInt32(EntityType), EntityInterfaceID, Convert.ToInt32(EventLevel), StartTime, EndTime, Convert.ToInt32(ReturnType), Description, UserID);
return objLog.Save();
}
}
catch
{
}
return false;
}
There are some coding practices which likely arise from a good intent, but sometimes feel misplaced. For example, the "only one return from a function" tends to make code more complex and harder to read, instead of easier, ever if it theoretically makes debugging easier. I can at least understand the intent and reasoning behind it, even if I don't like it.
Danny D's former co-worker had their own little rules. Specifically, sometimes when you write an if statement, you definitely need an else. Other times, you don't. That's confusing, because you have to make a choice. Instead of making a choice, just always use an else. Always.
We've had a bit of a run of PHP in the inbox lately, which is fine, but certainly isn't doing anything to help PHP's reputation as a WTF factory. This one comes from Lucio C, who was hired to fix a hacked WordPress installation.
Much of the fixing was figuring out what data was safe to recover, what files may have been tampered with, and generally assessing the damage.
Nora found a curious little C# helper method. It was called in exactly one place and it is… not exactly necessary in any case.
/// <summary>
/// Return the Filter Index
/// </summary>
/// <param name="item"></param>
/// <returns></returns>
private int GetFilterIndex(bool item) {
int index = 0;
switch (item) {
case true:
index = 1;
break;
default:
index = 0;
break;
}
return index;
}
Checking browser compatibility is less of a thing these days than it once was. In an ideal world, we check for the specific features we want to use, and fallback to a different approach, or fail gracefully if they don't exist. We use shims and polyfills and pile on all sorts of logic to navigate this mess.
What we hopefully don't do is use user-agent sniffing. The user-agent string is, honestly, one of the kludgiest, messiest, and just generally offensive ways to divine browser behavior. It was, however, once the standard, and thus there is still plenty of code, usually older code, which does use user-agent sniffing.
We've discussed extension methods in .NET in the past. If you write a method with a signature like public static void foo(this string input), then you can invoke this method like myString.foo(). It acts like an instance method to a caller, but it really just invokes foo(myString). It's a nice way to inject functionality into existing classes, and many .NET libraries use this feature.
Esromhaz's co-worker found an… application of this.
Visual Basic .NET is actually not a terrible language. I don't think it'd ever be anyone's favorite language, and these days it's basically deceased, but it's essentially C# with verbose syntax. Even the APIs are identical…
… almost.
Initech had a lovely little Content Management System built by a third party that was good at "building" CMSes. That is to say, this company knew its way around a WordPress template.
When Initech needed a new public-facing website, they went straight back to that vendor. Now, this new website was a complicated statistical tool, with all sorts of complicated business rules and requiring a large amount of custom programming. So the vendor that just cranked out WordPress templates may not have been a good fit for the project, but that didn't stop anybody.
Cat has some Java code which handles text layout. Now, someone writing the code didn't understand the idea of enumerated types, so every constant is a string.
That's a nuisance, but not a terrible problem. Of course, with Java's String handling, you also run into the fact that == will frequently work, because Java tries to reuse String instances, but it won't always work, and thus equals exists.
While jQuery isn't as popular today as it once was, its still a widely used "utility belt" library. Its popularity arises from the fact that it takes cumbersome APIs and wraps convenience functions around them.
But what if those convenience functions are too convenient, like Ryan's co-worker found. For example, if you want to perform an asynchronous HTTP request using jQuery, you could do something like:
The Strategy Pattern, like any other design pattern, is supposed to help us write code that's flexible and easy to modify. In the case of the strategy pattern, you have one class, the Context, which has a member which implements a Strategy interface. The actual implementation lives in the Strategy, but the Context is the object that other code in the program consumes. Ideally, this means that you can change the behavior of your Context by simply swapping a different Strategy implementation in.
On the flip side, when it gets out of hand, you might end up like Dotan, consuming an API from a major cloud vendor, written with a terminal case of "Pattern Brain".
When the pandemic started, a lot of companies needed to cut back, and Initech was no exception. In the Before Times™, Initech had an offshore development team that maintained an application inherited from an acquisition. Now that everyone was tightening their belts, though, that had to go. The offshore team was released and the application they supported ended up in the hands of Lovelace.
Lovelace dug in, and they quickly discovered a few things. From 2010-2017, the application's idea of source control was a folder on an FTP server and a lot of files named some_module.php.old and some_module.php.donotuse. In 2017, someone put the project into Git, but the commits were just point-in-time snapshots of the FTP folder. Deployment? Just work right on that FTP folder, it's fine. And if you forget to commit those changes back to source control? No biggie- consider the FTP folder the source of truth.
Marco sends us some code that he wrote, back in the far off days of 2003. He wrote some code to handle network addresses. Unfortunately, it never quite worked. Specifically it could only handle addresses in the /24 subnet.
Now, this was written in Perl, so you know it involves regexes.
Starting in 1985, a tiny little language called Clipper briefly conquered the world. It was a dBase-derivative, with the bonus that its programs could be compiled and run as stand-alone software on MS-DOS. That meant small programs which couldn't justify getting time on a mainframe or a minicomputer could be whipped up to run on a desktop. It was popular, and for about a decade, it was everywhere. Then Windows 95 came out, and Clipper refused to pivot to Windows and became a footnote in history.
It mostly worked pretty great, or at least as great as one of those tiny business-focused languages ever got. Unfortunately for Drake, he encountered some issues in the latter days of Clipper in the early 90s.
Patricia's employer hired her because she knew Python. They were a Python shop, at least at this point, but they'd never actually hired a developer with Python experience before.
At some point, their PHP developer wanted to branch out, and decided to solve a problem using a small Python script. It was very successful, and features got added to it. In a surprisingly short amount of time, the script expanded until it was two separate web applications which were absolutely critical to business operations.