Forums
Today's Code Snippet comes to us from S.G, who writes, "Over time all development teams inevitably gather their share of WTF code; at the very large project I am currently working on, they hand out "Van Gogh" awards for the best. I hope some of these candidates give you a laugh."
Today's code snippet come to us from Carl Cerecke. Carl is currently deep within the bowels of a large government application trying to complete a minor defect fix. This application is used throughout the country of New Zealand by the front line staff dealing with a sizeable percentage of the citizens. Carl knows a couple of these front line staff personally and they hate the software. Carl writes, "I work for the large international software house that has the support and maintenance contract on this impenetrable piece of enterprisey spaghetti code."
Carl continues, "here's a piece of code that has nothing to do with the defect I'm trying to fix. At least I don't think it does. It did, however, jump out at me while scrolling through the file as an exemplar examplar of the sort of code littered around the project. I had to use a pen and paper to work out exactly what conditions the setDirty(true) call was made. It was no real surprise that the if statements can be replaced entirely by a much more understandable one-liner."
Today's Code Snippet comes from Christopher Stolworthy. Christopher has a friend who is attending an upstanding college to get his Bachelors of Science in Computer Science. One day this friend called him up... "He wanted me to test out his new login system that he had written in C#, using SQL Server. I agreed and he sent me his app. I was playing around with it when I noticed something interesting. After typing in my username I would begin to type my password, if I mistyped a character ANYWHERE in the field the app immediately threw an error. "This is interesting" I thought to myself. So I dove into the code, after a few minutes I found the following. He couldn't see where the security issue was, until I used "Admin" as the username and started guessing his password."
This just absolutely amazes me.
RJ Writes, "When I first began working at the company in question, I was trying to get a handle on the flow of database queries during a fund transfer, so I enabled query logging, and stepped through an example transaction. (Platform, PHP/MySQL on Linux). For any who read this: DON'T PANIC - the system never saw real production use until after it was completely revamped in a proper DBMS.
Order of SQL Queries for "Dispatcher sending funds" transaction:
Today's Code Snippet comes from Rob O. Rob was working in a company (as a contractor) on different projects for almost a year before he was asked to sit in on a meeting with two vendors and two business analysts. Rob failed to notice during the discussion one of the third parties furiously writing notes every time they were asked about XML.
They had not gotten very far with the technical details of the project, but the business analysts knew what they wanted. Buzz-word compliance. The buzz-word: XML.
Today's Code Snippet of the day is legion. I ran across several snippets that don't necessarily stand on their own, but deserve to be gently* laughed at anyway. We start with a recursive error handler...
I.F. writes, "This might be interesting for discussion. Found in the wild on production system. management summary (in Java) of my investigation of a production bug. public boolean aMethod(Object anObject) {
try {
/*
* Some 50 lines of unreadable obfuscated code littered with
* return statements, throwing some exceptions and performing
* various exception prone operations like:
* - parsing
* - database access
* - calling other methods of similar signature (but not catching Exception)
*/
return true;
} catch (Exception e /*PANIC. NEVER DO THIS AT HOME*/) {
//call a method of similar signature
aMethod(anObject); //RECURSION in exception handler => BUG => PANIC
}
}Today's Code Snippet comes from two different people, Nate and Mike. I felt these were each too small to post by themselves(maybe we'll get to 200 comments?!), so I decided to give a little more. To try a little harder. To reach a little deeper. To, to... Never mind, here's the code.
Nate writes, "Having recently started a new programming job, I've quickly discovered what most of the day-to-day grind entails: Deciphering and cleaning poorly written Visual Basic code before actually being able to perform my assigned work. Our code base has plenty of the usual suspects: Variables with meaningless names like "AA" and "bbb", thousand-line functions (which approach VB's built-in limits), no-ops, unreachable code, gobs of copy-and-pasted code, and a few instances of this little construct (irrelevant code removed):"
Today's Code Snippet comes to us from Hank M. Hank writes, "It was my third week on the job, and that morning the custom compiler they wrote for their in-house language (steaming pile of WTFs) quit working." Standard debugging revealed that the executable didn't change, and reverting source control to when it worked, both source files and executable (just to make sure) didn't help.
Hank continues, "Fortunately the source code to the compiler was in source control, so I was able to run a debugger to find the problem. Here are the problem lines. Note that this is C++, not C, so std::string and helpers exist. See if you can guess why it didn't work."