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.
We've all seen folks reinvent the wheel. Some folks reinvent booleans. Others don't know when to stop. Some treat time as though it were malleable. Still others have all sorts of trouble finding dates.
However, Nathan encountered some code where folks seemed even more determined than usual not to use the built-in features of the language.
Josh's team has an offshore group that "helps" with development tasks. Since they often provide code that doesn't do what it's supposed to do, they've started mandating unit test coverage. So, for the first round, they did do exactly what Josh's team asked - the offshore group provided 75% unit test coverage across all classes...and 0 assertions.
So, Josh's team explained what assertions were, and how they worked, and why they're important, and specifically that there needed to be more of them.
Ever since Nathan had been partnered with the Siberian application development team, he couldn't help wondering if they'd been sent there as punishment. He supposed the long winters got boring, and coming up with "clever" solutions was the only thing keeping the developers sane, so Nathan was used to cutting the far-flung team some slack. Usually.
One day a simple task crossed Nathan's desk: there were two systems on two servers, let's call them Aardvark and Barracuda, that had similar databases. Nathan was asked to compare the subscriber lists stored in each. Since the servers were isolated from each other, he couldn't join across them. Instead, he planned to pull a simple plaintext dump of each and diff them. On Aardvark, this was easy:
Dave was recently asked to write up documentation for a newly inherited system in preparation for a big rewrite. As is standard industry practice, the original developer no longer works for the company, leaving Dave high and dry if he runs into any problems.
What Dave found was an incredibly over-engineered codebase with patterns applied for their own sake and copious amounts of comments that failed to convey anything important about "why" the code did anything.
When teams of enterprise software developers are cloistered away from the real world for long enough, an attitude of monasticism prevails. The fragile and fleeting concerns of mortal time fall away, and the developer's mind awakens to the greater, eternal truths that wait unsullied in everlasting Empyrean majesty. Into such a team Cory came, and, under the rigorous guidance of Brother Architect, he learned that only adherence to the Database Schema Commandments could free his soul to bask in the light of the divine.
And, lo, the First Commandment was: Thou shalt name each table having a foreign-key relationship with another table such that the name of the table having the primary key is included in the related table's name.
Jan W. works in the Operations group for one of the biggest Internet access and hosting providers in Germany. As such, when you have to support as many customers as they do, there's a LOT of complex moving parts that go into keeping the environments up and running smoothly. So, to help distribute the workload, and to keep everyone sane, Operations' development needs are handled by a separate group.
Any new changes that are sent over arrive bundled up in a convenient Debian package so that QA can quickly bless everything before it's installed on any production machine.
When Peter was training one of ShellTech's new developers, he didn't think much of a question the greenhorn asked him.
"What happens if there's an error in a catch block?"
Guillaume's employer, BastilleCo, believed in an egalitarian workplace. Managers and executives sat at the same desks as other employees, and they often took lunch together. This made BastilleCo an excellent workplace, even in a progressive nation like France.
However, BastilleCo's defect was to treat its data like it treats its employees. There existed the typical messiness of bad legacy code -- single-letter variables, globally-scoped functions, and so on. But not only was there no executive/employee segregation, but there was no data segregation either. In fact, there was a single table, where everything in BastilleCo's flagship application was stored:
May 14
Stuart: Oooh Sheldon, I'm afraid you couldn't be more wrong.
Sheldon: More wrong? Wrong is an absolute state and not subject to gradation.
Stuart: Of course it is. It's a little wrong to say a tomato is a vegetable;
it's very wrong to say it's a suspension bridge.
-- BBT
Kristian works in a shop with a bunch of superstar developers who always seem to find interesting ways to solve what most folks might otherwise consider to be trivial design issues. One particularly brightly shining piece of engineering involved a home-grown enum table in their database. Apparently, true, false and perhaps even FILE_NOT_FOUND weren't enough for these developers. No, they needed something that could handle gradations of right and wrong; true and false. They needed something that could handle situations where something was really true or really false. Something that was a bit more than boolean...