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.
It's bad news when you inherit a legacy PHP CMS. It's worse news when you see that the vast majority of the files were last changed in 2002 (of course there's no source control).
That is the unfortunate position that Elda found herself in.
Alexandar works with a veteran software architect. It's important to note here that a veteran is someone who has had experience. It certainly doesn't mean that they learned anything from that experience.
This veteran was given a task to write a C# method to populate a user's news feed. The goal was to find the five most recent news articles and add them to the list. Now, this is a large scale CMS, so those articles need to be fetched from ElasticSearch.
Years ago, Aleshia W started a job in a VB.Net shop. There's a lot I could say about those kinds of environments, but I'd really just be padding out the article, so let's just get right to the code- which pads out a Year string.
Jun 21Protected Function YearPadText(ByVal val As String) As String
Dim valLen As Integer
valLen = val.Len
Select Case valLen
Case 1
val = val + " "
Case 2
val = val + " "
Case 3
val = val + " "
Case 4
val = val + " "
Case 5
val = val + " "
Case 6
val = val + " "
Case 7
val = val + " "
Case 8
val = val + " "
Case 9
val = val + " "
Case 10
val = val + " "
Case 11
val = val + " "
Case 12
val = val + " "
Case 13
val = val + " "
Case 14
val = val + " "
End Select
Return val
End Function
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:
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:
let i = 1;
while(cust.orders[i]) {
//do stuff with cust.orders[i]
i++;
}
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:
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.
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: