Derrick Pallas

Jan 2007

Paid by the Line

by in CodeSOD on

Frank is a contractor. His company has been brought in to refactor some back-end web services that were all developed by a single person, "Nicholas," over the course of a couple of years.

From the front lines,

Having looked at it, we've decided that a complete rewrite is the only solution. Here's just one example of what can only be called "paid by the line" programming.


Reinventing the Web

by in CodeSOD on

Our friend David had some time on his hands and a great idea for a web app: that's the recipe for success. Wanting to concentrate on the PHP back-end, he brought in a friend to develop the AJAX front-end.

Unfortunately, things started to get thorny when it came to connecting the two. The browser-side demo looked great but all the forms were submitting data through GET instead of POST. This was a major problem for the application, so David got a shovel and dug into the "AJAX".


Well, Open it Anyway

by in CodeSOD on

Lemma #1: Email is important. Corollary #1: It is therefore bad when email stops working. Conclusion: That's why one of the project managers was frantic.

That's who went and got Anne when she came into work. Going down the standard checklist: the server was up, sendmail was alive, but curiously /var (of /var/spool/mail fame) was 100% full. A quick perusal of that directory revealed a multi-gigabyte message sitting in /var/spool/clientmqueue; but why was it there?


But It Worked in the Demo

by in CodeSOD on

We've all been there: all of your test cases worked the night before but when it comes time to run the demo you realize you missed something. In college, I had to write Sub Hunter in assembly and those pesky submarines kept launching missiles after I depth charged them back to hell. The TA didn't notice either. It wasn't until later that I learned about the magic of peer review. Not that fewer bugs sneak across the unit test border, you just feel better because someone else missed the problem too.

Luckily for Christian's friends, he's on patrol. When one of his friends ended up on a randomly assigned project team, Christian took a look at some of the code. Apparently "Karl", the person in charge of the authentication module, wasn't too good at taking criticism as long as the unit test passed.


Catch and Release

by in CodeSOD on

One thing that is quite clear is that many of the people that write in are called Don. The corollary is that if you want to see less bad code, change your name. What isn't clear (to me, from the submission) is what Don's company does.

Whatever they do, they send out a lot of template-based email. Even better, it's all environmentally friendly: they have a catch and release program. In case you'd like to start a similar program, here's some exceptional sample code written in C#.


Configuration Made Easy

by in CodeSOD on

While Dan doesn't work for them, he has had occasion to see their source code. Who are they? Only the biggest and best in all of Europe when it comes to document management!

But having thousands of customers using your .Net product isn't enough. No, their biggest asset is customization. Not just for the high-rollers, when a customer --- any customer --- asks for even the slightest change, they listen. And how do they do it? Let's take a look!


Breaking Out of the Box

by in CodeSOD on

Today, we've got a triple-header of stuff that's probably too short to post on its own. The theme, briefly: loops. (Because who doesn't love loops? I know I do!)

Where Mike works, they reward people for thinking outside of the box. He didn't find this code (a coworker did) but he did give it a gold star for breaking the mold.


Round and Round

by in CodeSOD on

One of our agents has a problem. For years, floating-point math has been too complicated. Remember the good old days? You used to be able to type var=INT(var+0.5) without black-box functions getting in the way. These glory days are long past.

In fact, the reason the IEEE was created was to make floating-point math miserable, especially when it comes to rounding. It is in this new world that Smith works, attempting to round to an arbitrary number of digits. However, when he puts 39.995 into his function, it returns 39.99 instead of 40.00. Other inputs produce the expected output, e.g. 11.995 produces 12.00. Can you solve the mystery?


Time to Deprecate

by in CodeSOD on

It's time to get rid of C. The language itself is over 35 years old and the standard library is insanely complex. There's even a header file called complex.h, if you need proof. The "stdlib" has even infected pure languages, like Perl.

James' coworker realizes this and is fighting back! As part of his protest against the functions in time.h he's found new and interesting ways to manipulate time in Perl.


RubyOnRegexp

by in CodeSOD on

I should preface this by saying that I like Ruby: it allows you to express both powerfully and tersely. But to be trite, with great power... well, you know the rest. As for RubyOnRails: I haven't gotten around to using it but a lot of people have and like it very much. Being Open Source, there are supposed to be a lot of people watching. Fabian is one of those people.

He sends us the following single like of source code, broken into multiple lines for your viewing pleasure. Watch, in amazement, as we dissect a RegexpInRuby.


If At First You Don't Succeed

by in CodeSOD on

While working with someone else's "utility class," David decided to have a little fun and turn on compiler warnings. It turns out that the compiler is actually sort of good at catching weird abuses in Java.

 

As he put it,
I turned on some additional compiler warnings, including one to warn about undocumented empty blocks, and it complained about the catch block below. Catching and swallowing exceptions is all too common on this project (as are the completely useless javadoc comments that don't actually document anything), but this is the first time I've seen someone...
Actually, why don't I just show you?

String Optimizations in Java

by in CodeSOD on

In many languages, Strings are not just the "arrays of characters" that our Introduction to Programming professor told us about. More often than not, they're immutable and sometimes magical: you can't really combine them, you can only conjure new ones. Since creating a new object is usually costly, it's not optimal to use a java.lang.String if you're going to do lots of concatenations.

Someone Oscar works with realized this. As he puts it, "You cannot accuse this developer of being oblivious to the performance advantage of using StringBuffer."


Validating Nothing

by in CodeSOD on

At Fischer's company, they work with a lot of consultants. Many of these consultants, not worth their salt, are sent down the river when their contracts end. Once in a blue moon, however, a shining example of what it means to be a developer comes down the pipe. These mighty few are given offers to become real employees.

As he puts it,

Normally, you'd think this could be a positive thing whereby we could listen to all the consultant's battle stories and learn from other people's mistakes without making them ourselves. Well apparently we're going to be learning from our own mistake for many years. Here's some fresh code from by our newly hired, full-time staff member.

Little Black Book

by in CodeSOD on

It wasn't that Graham's company lost an employee, it's that they gained a consultant. As an employee, this person excelled at many things, naming functions not the least of these.

As Graham recalls: he was a funny guy - had a real thing about women's names, and always used them for function calls whenever possible. Here's an example which ... stuck in my mind because of that sole bug report comment(!) in the middle.


Making Time for UNIX

by in CodeSOD on

David works for a company that writes applications that care about when things happen. Needing a bit more time to work on other things in-house, they outsourced some module development to China.

In his own words,

They helped us to develop some modules, and my boss asked me to review one of them. It seemed to be working fine, so I decided to look into source codes. I shouldn't have do it.


Finding Random Rows

by in CodeSOD on

We all make rookie mistakes, especially as rookies. In an act of humility, DJ sent us some PHP she wrote at the tender age of 19.

From the submission,

I recently ran across some code I wrote on my first project for a new company I'd just started working for. Part of the site required I show some content picked at random from a database. Since I'd only been doing PHP for about 6 months I was blissfully unaware of the array_rand function so I wrote this instead.

Fun with Maths

by in CodeSOD on

Ward is not a lucky man. When the two main (read: only) developers of a flash application were fired, he was called in to clean up their mess. As he puts it,

A couple of months ago, I was asked to do a small update (5 hours work) to an application made by those 2 people (they made it together, so its even worse!). This application is for a government agency, and they already paid in advance for updates. I was told just to replace the database with updated material, compile an installer and ship it.

That sounded easy enough, but after 150 hours, 20k lines of code, a a visit from one of the ex-developers, he was still finding jewels like


Three's a Crowd

by in CodeSOD on

Key and value, yin and yang, me y me compadre: all pairs. Most coders have had times when one return value is just not enough. Some sugary languages allow you to create and return arrays on the fly; others are not so helpful, forcing developers to allocate structs or return arrays of pointers.

In C++, it's easy enough to use the template std::pair and necessary for many STL templates. Maciek's company uses Java, but they wanted in on the fun and decided to write their own class.