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.
Tina needs to write some software that integrates with a hardware device. Thatdevice controls access via behind a PIN, and thus Tina's team needs to track the valid PIN, so that they can, via software, update or alter the PIN.
There's just one problem. That device has some opinions about how a Personal Identification Number should be represented:
Picking random items without repetition is its own special challenge. It's one of those things that's not actually hard, but some programmers have a difficult time coming up with solutions to the problem. Abraham has found these two examples in some code he maintains:
Aug 22//pick 3 out of 4
int alreadyUsed = 0;
while (alreadyUsed < 3) {
int rand = random()%4;
if(!m_AllOptions[rand]->used) {
m_AllOptions[rand]->used = true;
alreadyUsed++;
}
}
A large company with facilities all over the Asia-Pacific region opted to modernize. They'd just finished a pile of internal development that extended the functionality of a 3rd party package, and they wanted to containerize the whole shebang.
That's where Fred came in, about 9 months into a 12 month effort. Things hadn't gone well, but a lot of the struggles were growing pains. Many of the containers were built as gigantic monoliths. A lot of the settings you might need to do a Kubernetes deployment weren't properly configured. It was a mess, but it wasn't a WTF, just a lot of work.
"Never trust your inputs" is a generally good piece of advice for software development. We can, however, get carried away.
Janice inherited a system which, among many other things, stores phone numbers. Like most such systems, the database validates phone numbers, and guarantees that numbers are stored in a canonical format, as text.
Penny uses a Python ORM. Like most ORMs, it involves a lot of "inherit from a BaseModel class, and get all your database access stuff for "free". Or at least, it used to. They've released an update.
def __init__(self, *args, **kwargs):
if hasattr(self, "ACCESS_POLICY_VIEWSET_NAME"):
deprecation_logger.warn(
f"The model {self.__class__} defines the 'ACCESS_POLICY_VIEWSET_NAME' class "
f"attribute which is no longer required and is discouraged to be set."
)
return super().__init__(*args, **kwargs)
Robert has inherited a .NET application. It's a big-ball-of-mud, full of monstrous classes of thousands of lines and no coherent purpose, complete with twenty constructors.
It's ugly and messy, but it's mostly just generically bad. This method, however, is a lot of bad choices in very few lines.
Embedded chip documentation is sometimes very bad, and very confusing. Frequently it's difficult to really understand the ins and outs of a given chip without simply getting experience.
Which is why Mr. Scrith was a bit surprised with this code, which came from someone who definitely should have known better.
Sam worked on an application which needed to parse files out of a directory. There was a ticket to change the search path for those files to search an additional directory. That didn't turn out to be terribly hard, but the existing code raised some serious eyebrows.
def get_info_for_identifier(base_name: str, identifier: str) -> dict:
...
all_ids = os.listdir(base_name)
...
results = {}
for i in all_ids:
results.update(parse_identifier(base_name, i))
...
return results[identifier]
Robert H was trawling through the JavaScript front-end for his team's ASP.NET MVC application. The goal was to prepare for a complete rewrite of the front-end, because, well, it had problems and wasn't reliable or maintainable.
As an example, Robert sends this:
Pearl was paying down some technical debt. She was trawling through their NodeJS application with a search for TODO and console.log. She was triaging the TODOs, and replacing the logs with a real logging framework.
The application was old, had many complicated routes for requests to be handled, and buried deep in a file was this code, which was clearly testing code that was never meant to end up in production:
Usually, we don't pick on game code, as it's frequently bad because of the time constraints under which it's developed and because the concerns are more around "making a fun, performant game," and not "writing good reusable code".
But there are some egregious exceptions, like what happened to Patrick. He was handed some C# game code, and told, "Good luck!"
My favorite bar in Pittsburgh is a bit of a dive. Like any good dive, the bathroom is covered in the incoherent scrawl of thousands of drunks. It's a mix of jokes, political flamewars, and just absolute nonsense. My favorite part about it, though, is that it just makes me think about the long history of latrinalia. For as long as there have been humans, we've been scribbling on whatever surface was at hand, and a lot of those scribbles have been made while we answer nature's call.
Programmers have their own form of latrinalia: code comments. They're frequently vulgar, they're sometimes comprehensible only to the person who wrote them, and we all like to pretend that they're more meaningful than they are.