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.
As we all know, managing null values is its own challenge, especially when you're working in a functional style. So as languages like .NET add functional approaches like LINQ extension methods, they also add null coalescing operators and nullable types, making it easy to pass values around without getting surprised by an unexpected null.
Unless you're whoever wrote the code that Abbie found, because they've managed to keep some surprises.
It's Thanksgiving Day in the US. Yesterday, we looked at a classic "encryption" story, and today, we should all be thankful that we don't have to support this encryption code. Original --Remy
Richard's company builds, hosts, and maintains a variety of small- and mid-sized web-based applications for their clients. Recently, one of their clients asked Richard to help audit a fraudulent transaction, which meant that Richard needed to dig through the code to see how to decrypt bank account numbers stored in the database. The search led him to H88493247329(), the method responsible for encrypting customer data. After spending a minute to add linebreaks and rename the variables, Richard asked his coworker why he obfuscated the code. His coworker scoffed, you should always encrypt your encryption functions -- it's completely insecure otherwise
Is it that time of year already? Here in the US, we're prepping for the Thanksgiving holiday, so let's take a trip way back into the archives, and learn about the life of a moderately-paid-consultant. Original --Remy
Paul B always thought of himself as a moderately-paid consultant. With no real overhead, a policy against ties when meeting with prospective clients, and a general pickiness about the projects he'll take on, his rates tend to be pretty low. One company that looked right up his alley was a mid-sized manufacturing company that wanted a custom webshop. They went to the highly-paid consultants in town, but weren't too happy with the six-figure price tag. Paul's quote was in the five-figure range, which he felt was pretty moderate given that it was a several month project. Of course, the company wasn't too happy with his quote either, so they searched high and low for a three- or four-figure price. They eventually found one overseas.
Despite losing the bid, Paul never bothered unsubscribing from the company's mailing list - there was always something exciting about learning the latest in gimbal clamps and engine nozzle extensions. About a year and a half later, he received an exciting newsletter announcing that the webshop was finally live. Out of curiosity, he created an account to check things out. A few days later, he received an apology for lost orders - they didn't know who had ordered what, so they sent it to everyone who had signed up. And then came the "data breach" email — everyone's personal data (which, for Paul, was just his throw-away email) was now in the hands of some hackers. You get what you pay for never rang so true.
A fair bit of "bad code" requires at least a passing understanding of the language in question, or the domain involved. But bad comments transcend programming languages. Vilx sends us this one, which comes from code which is definitely running in production.
Oct 20// WARNING!!! Special case for [external API] testing.
// DO NOT LET THIS PIECE OF CODE FIND IT'S WAY TO PRODUCTION
Octavia (previously) didn't just inherit a C# application with dodgy approaches to string handling. It's also an application with questionable understandings of CSS.
CSS is far from perfect, and offers a lot of pitfalls and traps. There's a reason the "impossibility" of vertically centering text is a punchline. It's so flexibly declarative that, in many cases, there are many ways to achieve the same styling result, and it's difficult to pick out the correct one. But one would hope that developers could at least avoid the obviously terrible ones.
Octavia inherited a decade old pile of C#, and the code quality was pretty much what one would expect from a decade old pile that hadn't seen any real refactoring: nothing but spaghetti. Worse, it also had an "inner platform" problem, as everything they put in their API could conceivably be called by their customers' own "customizations".
One small block caught her eye, as suspicious:
Long-lived projects can have… interesting little corners. Choices made 13 years ago can stick around, either because they work well enough, or because, well, every change breaks somebody's workflow.
Today's anonymous submitter was poking around the code base of a large, long-lived JavaScript framework. In a file, not modified since 2007, but still included in the product, they found this function.
Alleen started by digging into a PHP method which was just annoying. _find_shipment_by_object_id would, when it couldn't find the ID, return false, instead of the more expected null. Not terrible, but annoying. Worse, it didn't return the shipment eihter, just a key which could be used to fetch a shipment from an array.
Again, all that's just annoying.
Cicely (previously) returned to the codebase which was providing annoyances last time.
This time, the code is meant for constructing objects based on a URL pattern. Specifically, the URL might have a format like api/resource/{id}. Looking at one of the constructors, though, it didn’t want an ID, it wanted an array of them. Cicely wasn’t passing multiple IDs off the URL, and wasn’t clear, from the documentation, how it worked, how you supplied those IDs, or frankly, what they were used for. Digging into the C# code made it clear, but still raised some additional questions.
Marlyn’s employer ships software for a wide variety of CPU architectures. And depending on which branch of the product you were digging into, you might have code that builds for just i386, x86_64, PPC, and PPC64, while another branch might add s390, s390x, and aarch64.
As you might imagine, they have a huge automated test suite, meant to ensure that changes don’t break functionality or compatibility. So it’s a pity that their tests were failing.
Russell F sends us this C# "fuction", and I have to be honest: I have no idea what it's supposed to do. I can trace through the logic, I can see what it does, but I don't understand why it does it.
private List<LaborService> Tranpose(List<LaborService> laborService)
{
int half = (int)Math.Ceiling((decimal)(laborService.Count)/2);
for (int i = 0; i < laborService.Count; i++)
{
if (i < half)
laborService[i].Order = 2 * i;
else
laborService[i].Order = (i - half) + 1;
}
return laborService.OrderBy(x => x.Order).ToList();
}
As a personal perspective, I don't tend to believe that mastery of a programming tool is nearly as important as mastery of the codebase and problem domain you're working on. But there are some developers who just don't want to learn the codebase or what other developers are doing.
Take Jessica's latest co-worker, which is similar to some previous co-workers. In this case, there was a project in flight that was starting to fall behind schedule. Management did what management does in this situation: they threw warm bodies at the project and ensured that it fell further behind.
In .NET, if you want to get the first item from an IList object, you could just use the index: list[0]. You also have a handy-dandy function called First, or even better FirstOrDefault. FirstOrDefault helpfully doesn’t throw an exception if the list is empty (though depending on what’s in the list, it may give you a null).
What I’m saying is that there are plenty of easy, and obvious ways to get the first element of a list.
When it comes to backwards compatibility, Microsoft is one of those vendors that really commits to it. It’s not that they won’t make breaking changes once in awhile, but they recognize that they need to be cautious about it, and give customers a long window to transition.
This was true back when Microsoft made it clear that .NET was the future, and that COM was going away. To make the transition easier, they created a COM Interop system which let COM code call .NET code, and vice versa. The idea was that you would never need to rewrite everything from scratch, you could just transition module by module until all the COM code was gone and just .NET remained. This also meant you could freely mix Visual Basic and Visual Basic.Net, which never caused any problems.
One of the lines between code that's "not great, but like, it's fine, I guess" and "wow, WTF" is confidence.
For example, Francis Gauthier inherited a WinForms application. One of the form fields in this application was a text box that held a number, and the developers wanted to always display whatever the user entered without leading zeroes.