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.
When Mickey's colleague was tasked with changing <br>s into newlines, he wanted to cover all the bases. Since <br />, <Br />, <bR />, etc. are all valid HTML, he clearly had his work cut out for him.
Damn case-sensitive string comparison, he must've thought. This could be so much easier! Oh well, I guess there's only one way to do it... brute force, baby!
While spelunking through a cavernous J2EE application, Matt stumbled across this method, buried in a base Client Object class...
Nathan was going through some of his company's fairly buggy JavaScript calendar code, and saw this perfectly described function.
Sep 07
function DoNothing()
{
}
At Albert M.'s job, he was recently tasked with implementing a C++ module to calculate the earth's magnetic field at any point. While I'm sure most of you have that formula memorized, Albert was feeling a bit rusty and consulted the Internet to help him find the code. He was in luck. The National Geophysical Data Center had exactly what he needed, and provided two different versions: one written in Fortran and the other in C.
From all appearances, the C version was generated using f2c, which is a fairly ancient Fortran-to-C converter. Albert figured he'd just start with the C code and modify it as needed. But after staring at it for a few seconds, he decided the wisest course was to brush up on Fortran and pretend he never saw the C code. First, here's the original Fortran code:
As an e-commerce site selling specialized goods, Steve's company uses a third-party service that provides a Flash-based image viewer to display extra-large product images and allow visitors to zoom, pan, and so forth. Occasionally, the product images would get out-of-synch, so Steve was tasked with writing a script to ensure that images on the vendor's server matched images on the in-house server.
Determining which images were on the vendor's server was fairly easy; it just involved a HTTP Request with a product number in the querystring. The service responds with a comma-delimited list of image paths, like so:
I thought that, when James Anderson announced the invention of nullity (i.e. Φ, or 0/0), we had finally gotten past the whole "impossibility" of dividing by zero. I don't know about you, but after installing the latest service pack including the "nullity patch," my programs happily hum along when they divide by zero. So why then did Mike C.'s predecessor bother with a DivisionWithZero method ... and why did he do it like this...
Apparently not satisfied with relying on Oracle's built in SUBSTR function, Connor's predecessor decided to write his own. Well, sort of...
Function SUBString(inputStr IN VARCHAR2,
startPos IN NUMBER,
endPos IN NUMBER
) RETURN VARCHAR2 IS
result VARCHAR2(100);
BEGIN
result := null;
SELECT SUBSTR(inputStr,startPos,endPos) INTO result FROM dual;
RETURN result;
END;
When Rus sent in his résumé for a systems administrator position, he made the mistake of including "PHP" as a bullet point. It's not that he doesn't know PHP - it's that he does, and is often stuck with trying to debug problems that the PHP developers blame on "the system."
Recently, he was tasked with diagnosing a problem where files uploaded to the site ending up at zero bytes in size. It had been thwarting the PHP developer for nearly three weeks. Due to the distributed nature of the site, uploading a file involved posting the file to one page, programmatically urlencoding the file, and then posting to a different page. Not trusting that it was a problem with "the system," Rus looked at the previous working code in the commit history ...
Thomas P was working on some code a while back where the original developer had devised a "clever" way of encoding errors.
Errors were encoded into a single integer rather than using a Boolean for each error that occurred. A nice way to overcomplicate things, but fine.
User-friendly data-validation is important. Rarely is a simple, red asterisk next to a form field enough to indicate what’s wrong with the input. Is it a required field? Is it too high? Is it not allowed? Generally, it’s a good idea to indicate what’s wrong with the form and how to fix it. For example, a good message for a poorly formatted currency field might be “must be formatted like currency (e.g. $9999.99).”
On the other hand, it can be easy to go too far. Take this snippet of validation code that Dai uncovered, for example. Even the most obtuse of users don’t need to be told “You must have a minus sign in the 1st position or immediately after a $ sign.”
They say the road to hell is paved with good intentions. Who they are and why they're so surly is beyond me, but I have to admit they're kind of right.
Take one of Sam's colleagues, for example. He had a well-intentioned tendency to provide helpful documentation via code comments, but... well...