Forums
Bad date handling code is like litter: offensive, annoying, but omnipresent. Nobody is specifically responsible for it, nobody wants to clean it up, and we end up ignoring it.
Murtaza K offers up a particularly malodorous example, though, that's worthy of note. It's got everything: string mangling, assumptions that ignore locale, bad ternaries, and it's completely unnecessary.
Those of us that had the luxury of learning to program in C or other non-auto-gc'd langauges, learned early on the habit of writing the allocation and deallocation of a block of memory at the same time, and only then filling in the code in between afterward. This prevented those nasty I-forgot-to-free-it memory leaks.
Of course, that doesn't guarantee that memory can't ever leak; it just eliminates the more obvious sources of leakage.
"So I can keep my current language setting or switch to Pakistani English. THERE IS NO IN-BETWEEN," Robert K. writes.
When looking for representative lines, ternaries are almost easy mode. While there’s nothing wrong with a good ternary expression, they have a bad reputation because they can quickly drift out towards “utterly unreadable”.
Or, sometimes, they can drift towards “incredibly stupid”. This anonymous submission is a pretty brazen example of the latter:
Alex F is suffering from a disease. No, it’s not disfiguring, it’s not fatal. It’s something much worse than that.
It’s MUMPS.
When the big banks and brokerages on Wall Street first got the idea that UNIX systems could replace mainframes, one of them decided to take the plunge - Big Bang style. They had hundreds of programmers cranking out as much of the mainframe functionality as they could. Copy-paste was all the rage; anything to save time. It could be fixed later.
Senior management decreed that the plan was to get all the software as ready as it could be by the deadline, then turn off and remove the mainframe terminals on Friday night, swap in the pre-configured UNIX boxes over the weekend, and turn it all on for Monday morning. Everyone was to be there 24 hours a day from Friday forward, for as long as it took. Air mattresses, munchies, etc. were brought in for when people would inevitably need to crash.
A project is planned. Gantt charts are drawn up. Timelines are set. They're tight up against the critical path, because including any slack time in the project plan is like planning for failure. PMs have meetings. Timelines slip. Something must be done, and the PMs form a nugget of a plan.
That nugget squeezes out of their meeting, and rolls downhill until it lands on some poor developer's desk.
Jakub writes, "I'm not sure restarting will make IE 'normal', but yeah, I guess it's worth a shot."
Lucio Crusca is a consultant with a nice little portfolio of customers he works with. One of those customers was also a consultancy, and their end customer had a problem. The end customer's only in-house developer, Tyrell, was leaving. He’d worked there for 8 years, and nobody else knew anything about his job, his code, or really what exactly he’d been doing for 8 years.
They had two weeks to do a knowledge transfer before Tyrell was out the door. There was no chance of on-boarding someone in that time, so they wanted a consultant who could essentially act as a walking, talking USB drive, simply holding all of Tyrell’s knowledge until they could have a full-time developer.
If there’s one big problem with XML, it’s arguably that XML is overspecified. That’s not all bad- it means that every behavior, every option, every approach is documented, schematized, and defined. That might result in something like SOAP, which creates huge, bloated payloads, involves multiple layers of wrapping tags, integrates with discovery schemas, has additional federation and in-built security mechanisms, each of which are themselves defined in XML. And let’s not even start on XSLT and XQuery.
It also means that if you have a common task, like embedding arbitrary content in a safe fashion, there’s a well-specified and well-documented way to do it. If you did want to embed arbitrary content in a safe fashion, you could use the <![CDATA [Here is some arbitrary content]]> directive. It’s not a pretty way of doing it, but it means you don’t have to escape anything but ]]>, which is only a problem in certain esoteric programming languages with rude names.
There are merits and disadvantages to including any sort of programming challenge in your interview process. The argument for something like a FizzBuzz challenge is that a surprising number of programmers can’t actually do that, and it weeds out the worst candidates and the liars.
Gareth was interviewing someone who purported to be a senior developer with loads of Java experience. As a standard part of their interview process, they do a little TDD based exercise: “here’s a test, here’s how to run it, now write some code which passes the test.”
An anonymous reader had something to share.
"I came across this code in a 13,000 line file called Constants.cs."
"I think I'll order the big-busted truck," writes Alicia.
The Joel Test is about to turn 18 this year. Folks have attempted to “update” it, but even after graduating high school, the test remains a good starting point for identifying a “good” team.
Mike was impressed to discover a PHP script which manages to fail a number of points on the Joel Test in only 8 lines.
There are certain languages which are still in use, are still changing and maturing, and yet are also frozen in time. Fortran is a perfect example- over the past 40–60 years, huge piles of code, mostly for scientific and engineering applications, was written. It may be hard to believe, but modern Fortran supports object-oriented programming and has a focus on concurrency.
Most of the people using Fortran, it seems, learned it in the 70s. And no matter what happens to the language, they still write code like it’s the 70s. Fortran’s own seeming immortality has imbued its users with necromantic energy, turning them into undying, and unchanging Liches.
Jul 18
