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.
We don’t receive many CSS-based submissions, possibly because CSS is already pretty horrible. There are real-world, practical things that you simply need to take a hacky, awkward approach with.
Matthew found this code, however, which isn’t a clever hack to work around a limitation, and instead just leaves me scratching my head.
PastorGL inherited some front-end code. This front-end code only talks to a single, in-house developed back-end. Unfortunately, that single backend wasn’t developed with any sort of consistency in mind. So, for example, depending on the end-point, sometimes you need to pass fields back and forth as productID, sometimes it’s id, productId, or even _id.
Annoying, but even worse is dealing with the dreaded date datatype. JSON, of course, doesn’t have a concept of date datatypes, which leaves the web-service developer needing to make a choice about how to pass the date back. As a Unix timestamp? As a string? What kind of string? With no consistency on their web-service design, the date could be passed back and forth in a number of formats.
There’s an old saying, that if your code is so unclear it needs comments to explain it, you should probably rewrite it. Dan found this code in a production system, which invents a bizarre inversion of that principle:
Jan 17static BOOLEAN UpdateFileStoreTemplates ()
{
BOOLEAN NotResult = FALSE;
NotResult |= !UpdateFileStoreTemplate (DC_EMAIL_TEMPLATE); // Not-ing a fail makes it true, so if Not result is True we've had a failure
NotResult |= !UpdateFileStoreTemplate (DC_TABLE_HEADER_TEMPLATE); // Not-ing a fail makes it true, so if Not result is True we've had a failure
NotResult |= !UpdateFileStoreTemplate (DC_TABLE_ROW_TEMPLATE); // Not-ing a fail makes it true, so if Not result is True we've had a failure
NotResult |= !UpdateFileStoreTemplate (DC_TABLE_FOOTER_TEMPLATE); // Not-ing a fail makes it true, so if Not result is True we've had a failure
NotResult |= !UpdateFileStoreTemplate (WS_EMAIL_TEMPLATE); // Not-ing a fail makes it true, so if Not result is True we've had a failure
NotResult |= !UpdateFileStoreTemplate (WS_TABLE_HEADER_TEMPLATE); // Not-ing a fail makes it true, so if Not result is True we've had a failure
NotResult |= !UpdateFileStoreTemplate (WS_TABLE_ROW_TEMPLATE); // Not-ing a fail makes it true, so if Not result is True we've had a failure
NotResult |= !UpdateFileStoreTemplate (WS_TABLE_FOOTER_TEMPLATE); // Not-ing a fail makes it true, so if Not result is True we've had a failure
return !NotResult;
}An email from Andrea Ci arrived in our inbox, with nothing more than some code and a very simple subject line: “VB Conversion: a year in hell”.
A lot of people have that experience when encountering Visual Basic code, especially when it’s VB6, not VB.Net. Even so, could it really be that bad? Well, let’s look at the sample Andrea provided.
Microsoft recently announced that they’re changing how they handle .NET languages. Up to this point, the focus has been on keeping them all feature compatible, but going forward, they’ll be tuning VB.Net towards beginners, C# towards professionals, and F# towards people who have to use .NET but want to “be functional”.
VB.Net’s biggest flaw is that it’s inherited all of the Visual Basic programmers. You may be able to write bad code in any language, but I’m not convinced you can write good code in VB6 or earlier. Those bad habits, like Hungarian notation, can mark out “modern” code written with a distinctly “non-modern” mindset.
