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.
There are many moments where our multi-threaded code needs to gurantee only one code path is executing at a time. That’s why we have locks, semaphores, mutexes, and so on. But those are all pretty complicated. Vincent H recently was reviewing someone’s code, and they found a far more elegant solution, which simply uses booleans.
For example, you could whip up a wait loop with a simple block like this:
Today, any sort of data access layer we build is going to be rooted in some sort of object-oriented design. It might be a full ORM, it might be an object-store database, it might be one of any number of kinds of database mapping tool.
What we usually don't do anymore is get a resultset with no type information, where we have to invoke the proper "GetXXX" method to fetch data out of what behaves more-or-less like a dictionary. Oh, we might have to do this, but we'll almost always bury it under a layer of abstraction to hide the ugly details.
Kids these days have their flexboxes and their ems and their position absolutes. In the olden days of HTML, we arranged everything with table tags and we liked it. Well, some of us did. Mike was recently doing part of a redesign, and when the background color of the page was changed, a bunch of garbage text appeared in various input forms. How could changing the CSS background color cause garbage text to appear?
Mar 19<b>Billing Address Information</b>
<p class="style3">Billing Address 1:<font color=white>0ooo0.....</font><input type="text" name="BillStreet1"></p>
<p class="style3">Billing Address 2:<font color=white>o00000...</font><input type="text" name="BillStreet2"></p>
<p class="style3">Billing City:<font color=white>00o00..0.o...0..</font><input type="text" name="BillCity"></p>Kara's ongoing quest to tame her codebase continues. First it was serialization, then more strings, then some serial communication.
Today, it's threads.
“My program needs to send some emails,” the developer thought to themselves. The then thought about how this could go wrong, probably thinking that, boy, they’ve got an external server, and boy, spam is a problem, and that server might get upset if you’re sending too many messages at once, or too quickly. That’s a thing which could happen, right?
That’s at least a plausible line of thought for the code Juana found, which looks something like this:
Matthew D was recently helping a friend plan a trip to Europe from the US. After shopping around a bit, they found a rather affordable airline based out of Poland that fit both their budget and their destination, and started booking a flight.
It was going well until it came time for them to enter their passport information. The site complained that the expiry date was invalid. Since that complaint was happening without a page reload, Matthew was pretty sure it was a buggy bit of client-side validation, so he pulled up the dev tools and poked around.
Stored procedures are a bit of a WTF breeding ground. Your average stored procedure language is more limited than your average general purpose language, the syntax is usually clunkier, and everything is so data-focused that implementing logic beyond simplistic processes can be more challenging than one would expect.
Of course, this gets harder if you don’t bother to learn how to do string concatenation. Darrin found an example of that while debugging a store procedure:
PHP gets a lot of flack, but perhaps we're taking the wrong perspective on things. Perhaps the gods have condemned PHP to ceaselessly rolling CMSes and wikis up the hill, whence they roll back down under their own weight. The gods had thought, with some reason, that there is no more dreadful punishment than futile and hopeless labor.
I mean, look at this code:
You may remember Karl from a few months back. Karl's organization is notorious for crunch, and it results in some awful sins when you're trying to cram 50 hours of work into the last five hours before launch.
Karl didn't write this particular bit, but dreads the day when he has to look at it or change what it does.