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.

May 2021

Classic WTF: All Pain, No Gain

by in CodeSOD on
It's a holiday here in the states. So enjoy this classic from the far off year of 2009. --Remy

"My company has very strict policy on direct access to the database," Steve writes, "no hand-built SQL in the front-end code and always use a stored procedure to access the data. The reasoning behind this was simple and sound: Avoid SQL injection attacks and increase database performance. "

"The execution, however, was not so simple and sound. They went through all the pain of needing to use stored procs, but none of the gain. I'll leave it as an exercise to the reader to see why."

A More Functional Approach

by in CodeSOD on

In functional programming languages, you'll frequently see some variation of the car/cdr operations from LISP. Given a list, these functions can split it into the head (or first element) of the list, and the tail (the rest of the list). This is often used to traverse a list recursively: function f performs an operation on the head of the list, and then recursively calls f on the tail of the list.

I bring this up because we're talking about C# today. C# has plenty of fun functional programming features, and you can certainly use them to write very clean, comprehensible code. Or, like Nico's co-worker, you could do something like this.

Without a Map, Without a Clue

by in CodeSOD on

Ali was working on an app for a national government. The government provided its own mapping API for its own custom mapping services. It did not provide any documentation, and the only "sample" code was hitting "view source" on an existing map page on the government's websites.

Ali writes: "I was going through their own implementations, looking for something that would help, when I stumbled upon this gem. I think it speaks for itself, no?"

Making a Weak Reference

by in CodeSOD on

There are times when performance absolutely matters. And the tech lead that Janell was working with (previously) was absolutely certain that their VB.Net project needed to be "designed for performance". Performance was so important that in the final design, they used a home-brewed JSON database (which, at its lowest level, was just a JSON file on disk), and it took 7 round-trips to their home-brewed database to read a single record.

Despite all this attention on performance, the system had a memory leak! As we've covered in the past, garbage-collected languages can have leaks, but they may take a little more effort than the old-school versions. Janell fired up a debugger, looked at the memory utilization, and started trying to figure out what the problem was.

Subline Code

by in CodeSOD on

Have you ever needed to prune an order line? Y'know, prune them. This is an entirely common operation you do on orders all the time, and requires absolutely no context or explanation. There's absolutely no chance that you might need to wonder, exactly what is being pruned.

Bartholomew A. was a little bit confused by the prune method in the codebase. Fortunately, reading through the code makes everything clear:

Meaningful Article Title

by in CodeSOD on

There was an era where UI designer tools output programmatic code representing that UI. So, say, if you were dragging and dropping objects in the Windows Forms designer in Visual Studio, the output would be C# code. Now, the designer would have some defaults. When you added a new button, it might identify it as button15. Of course, you wouldn't leave that name as it was, and you'd give it a meaningful name. That name would then become the property name of that field in the class generated by the designer.

Well, you might give it a meaningful name. Gormo inherited some Windows Forms code, which challenges the meaning of "meaningful names".

Mastery Through Repetition

by in CodeSOD on

When I was a baby programmer, I subscribed to a computer magazine. In those olden times, these magazines would come with pages of program code, usually BASIC, so that you could type this program into your computer and run it. If you were careful about typos, you could accomplish quite a bit of "programming" without actually programming. What you were doing, in practice, was just typing.

One of Anthony's predecessors was quite the accomplished typist.

Authentic Mistakes

by in CodeSOD on

John's employer needed a small web app built, so someone in management went out and hired a contracting firm to do the work, with the understanding that once it was done, their own internal software teams would do maintenance and support.

Fortunately for John's company, their standard contract included a few well-defined checkpoints, for both code quality audits and security audits. It's the last one that's relevant in this case.

A MLearning Process

by in CodeSOD on

If you go by the popular press articles on the tech field, anyone who's anyone has migrated into the "machine learning" space. That's where all the "smart" programmers go.

Of course, ML is really just statistics and automated model fitting. It's a powerful tool, and it does require some highly specialized skills- skills that might involve programming, but maybe don't quite overlap with programming.

Getting Funky

by in CodeSOD on

When RJ was trawling through some SQL Server stored procedure code, they spotted this line:

IF LEN(LTRIM(RTRIM(@funky_interval))) = 0 SET @funky_interval = NULL

Javascript Best Practices

by in CodeSOD on

For those looking to get into software development, there's never been more access to tutorials, guides, training programs, and communities of developers ready to foster those trying to get started.

Unfortunately, you've got folks that think because they've written a few websites, they're ready to teach others, and write up their own tutorials without having the programming background or the educational background to effectively communicate best practices to the public.

A Key to Success

by in CodeSOD on

Sometimes bad code arises from incompetence, whether individual, or more usually institutional. Sometimes it's overly tight deadlines, misguided architecture. And sometimes… it's just the easiest way.

Naomi writes in to confess to some bad code.

Touch of Death

by in CodeSOD on

Unit testing in C offers its own special challenges. Unit testing an application heavily dependent upon threads, written in C, offers even more.

Brian inherited an application where the main loop of the actual application looked something like:

A Real Switcheroo

by in CodeSOD on

Much of the stories and code we see here are objectively bad. Many of them are bad when placed into the proper context. Sometimes we're just opinionated. And sometimes, there's just something weird that treads the line between being an abuse of code, and almost being smart. Almost.

Nic was debugging some Curses-based code, and found this "solution" to handling arrow key inputs: