Forums
Last week, we took a look at a hash array anti-pattern in JSON. This week, we get to see a Python version of that idea, with extra bonus quirks, from an anonymous submitter.
In this specific case, the code needed to handle CSV files. The order of the columns absolutely matters, and thus the developer needed to make sure that they always handled columns in the correct order. This led to code like this:
Music fan Erina leads off this week with a double contraction! "Who knew Tom Waits was such a gravelly-voiced Relational Database poet?" she Mused. "You'd've thought that SQL modes was more of an indy garage esthetic." You might've, Erina, but I wouldn't've.
Validating email addresses according to the actual email specification is more complicated than you usually think. Most homebrew validation tends to just get something that's relatively close, because hitting all the rules requires some fancy regex work. And honestly, for most applications, "pretty close to correct" is probably fine. If you actually care about collecting valid email addresses, you'll need to actually send mail to the address and have the user confirm receipt to "prove" that the email address is real, valid, and actually accessible.
Still, some "close enough" solutions are better than others. Jon found this C# code:
Validation highlights the evolution of a programmer as they gain experience. A novice programmer, when given a validation problem, will tend to treat the string like an array or use substrings and attempt to verify that the input is the correct format. A more experienced programmer is going to break out the regexes. A very experienced programmer is going to just find a library or built-in method that does it, because there are better ways to use your time.
Andrea provides a rare example of a developer on the cusp between regexes and built-in methods.
There's a lot of room for disagreement in technology, but there's one universal, unchangeable truth: Oracle is the worst. But a second truth is that there's nothing so bad a programmer can't make it worse.
Someone at Ben's company needed to take data from a database and write it to a file. That file needed to have some specific formatting. So they used the best possible tool for the job: a PL/SQL stored procedure.
When Arbuzo joined a new team, they helpfully provided him some sample code to show him how to interact with their JSON API. It was all pretty standard-looking stuff. If, for example, they fetched a Customer object, it would have some fields about the customer, and an array containing links to orders that customer had made. One of the samples helpfully showed iterating across the orders array:
Jun 21
let i = 1;
while(cust.orders[i]) {
//do stuff with cust.orders[i]
i++;
}
This week's opening Error'd submission required a bit of translation for
the monoglots among us, but it was worth the work. Not speaking even
een beetje of Dutch, I was forced to use Google's own translation
service to see what it was that had so worried our friend
Sebas. And it's a doozy.
"...seek help - Child abuse images are illegal" warns
Google's AI, inferring lewd Low Countries Linux links.
For his part, Sebas takes it in stride,
"Just hoping I'm not flagged now."
I'm afraid to ask
what the Goog makes of tcl.
Pete has had some terrible luck with the lead programmers he's worked with. He's had a few which are… well, they don't take feedback well. Like his current team lead, who absolutely doesn't let any of the other developers review or comment on his code. "Don't ask me questions, you should know this already," is a common refrain. Speaking of questions:
String q1 = form.getQ1()!=null?request.getParameter("question_" + form.getQ1().getId()):null;
String q2 = form.getQ2()!=null?request.getParameter("question_" + form.getQ2().getId()):null;
String q3 = form.getQ3()!=null?request.getParameter("question_" + form.getQ3().getId()):null;
String q4 = form.getQ4()!=null?request.getParameter("question_" + form.getQ4().getId()):null;
String q5 = form.getQ5()!=null?request.getParameter("question_" + form.getQ5().getId()):null;
String q6 = form.getQ6()!=null?request.getParameter("question_" + form.getQ6().getId()):null;
String q7 = form.getQ7()!=null?request.getParameter("question_" + form.getQ7().getId()):null;
String q8 = form.getQ8()!=null?request.getParameter("question_" + form.getQ8().getId()):null;
String q9 = form.getQ9()!=null?request.getParameter("question_" + form.getQ9().getId()):null;
String q10 = form.getQ10()!=null?request.getParameter("question_" + form.getQ10().getId()):null;
String q11 = form.getQ11()!=null?request.getParameter("question_" + form.getQ11().getId()):null;
String q12 = form.getQ12()!=null?request.getParameter("question_" + form.getQ12().getId()):null;
String q13 = form.getQ13()!=null?request.getParameter("question_" + form.getQ13().getId()):null;
String q14 = form.getQ14()!=null?request.getParameter("question_" + form.getQ14().getId()):null;
String q15 = form.getQ15()!=null?request.getParameter("question_" + form.getQ15().getId()):null;
Jan's company has an application which needs to handle an Excel spreadsheet, because as I'm fond of pointing out, users love spreadsheets.
The JavaScript code which handles parsing the spreadsheet contains… some choices. These choices caused it to fail on any spreadsheet with more than twenty six columns, and it's not hard to see why.
One of the arguments against comments in code is that they create a need to have two things updated: the code and the documentation have to be kept in sync. Inevitably, they'll drift apart.
David works with a junior developer who came onto the team with strong opinions about, well, everything. One of those strong opinions is that every single line needs to have comments. Each and every one.
Folks who first learned to type on typewriters tend to prefer putting two spaces after a period. Most of the rest of us prefer just one. And this may have caused a performance problem.
Rob's application had a quick search feature to track down customer claims. One day, the quick search was running quickly and efficiently. A user could type in a claim number, hit enter, and a moment later their screen would show the claim. Suddenly, it slowed down. It wasn't just the gradual decline of growing data or stale statistics or bad indexes. It was a code change, and it didn't take long to find the problem:
In the wake of yet another extraordinary ransomware attack, most businesses are finally beginning to implement the sorts of security measures they knew all along they should put in place. "Someday soon, when we get the time." Some writers have been calling it "unprecedented" but you and I know just how precedented it really is.
Loyal reader Aubrey leads off with an insider report, writing "Corporate IT recently migrated the entire company to a new antivirus program, and it seems to have flagged *its own update* as likely malware." That's what we call fastidious.
One of the "legacy" PHP applications needed a few bugfixes. "Legacy" in this case, means "written by a developer who doesn't work here anymore", so mostly everyone tried to dodge getting those bugfixes assigned to them. Joe was taking a three day weekend at the time, so a helpful co-worker assigned the tickets to him.
The code wasn't an absolute disaster, but it suffered from being written by a "smart" programmer. Since they were so smart, they couldn't just do things using the basic language constructs, they had to find clever ways to abuse them.
Arguably, the biggest problem with SQL as a query language is that we usually execute SQL statements from inside of some other programming language. It tempts us into finding quick hacks to generate dynamic SQL statements, and if we do it the quick way, we find ourselves doing a lot of string concatenation. That way lies SQL injection vulnerabilities.
Constructing SQL statements by stringing together text is always a bad idea, even if you're still using query parameters. There's a reason why most modern database wrappers provide some sort of builder pattern to safely construct dynamic queries. Even so, everyone wants to find their own… special way to accomplish this.
The story of the week in software development is Github's Copilot, which promises to throw machine learning at autocomplete for a "smarter" experience.
Notably, one of their examples highlights its ability to store currency values in a float. Or to generate nonsense. Or outputting GPLed code that was used in its training set.
It's a holiday weekend in the US, so we turn back to 2009, and explore the Crystal Citadel. Don't worry, there's a flow chart. -- Remy
It was the mid-1990's and business was booming at the company that Terry worked at. It was booming so much that the existing process of entering an order — faxing in an order form torn out of an outdated-as-soon-as-it-was-printed catalog — was delaying things enough that it was costing the company some serious dough in missed sales. Needing a way to re-engineer the process without hiring an army of support staff, management decided on an innovative plan that would enable customers to place orders electronically without needing to contact customer service.
With resources being tight (even the help desk was fielding order inquiries), management decided to farm out the work to an outside IT firm. Now, important work like this wasn't going to be farmed out to the boss's nephew who was a whiz at programming in Word and Excel. Instead they were going with a big name, "we named our building after ourselves" company. Yes it would be expensive, but the money that could be saved by receiving orders this new way would allow the program to more than pay for itself in short order.
Last week we lightly brushed on the novel conspiracy theory that perhaps the HBO hullabaloo had been intentionally inspired by their social media team, and suggested you might join them. Apparently the media managers at Subway had been hungering for publicity as well.
TDWTF sandwich specialist Carlos buttered us up, saying "I'm sure you've received a ton of these already [ed: we hadn't], but what's one more?"
Good logging is an invaluable tool for debugging and diagnosing your applications. No logging makes that job harder, but not as hard as bad logging. Logging that doesn't log useful information, that doesn't help highlight the flow of the application, etc.
Volker was trying to track down a bug that was only raising its head in production, but the log files were spammed with nothing more than "echo". Millions and millions of log lines that were just that. A quick CTRL+F through the code later, and the offending method was found: