A Pattern of Errors
by in Error'd on 2020-05-29"Who would have thought that a newspaper hired an ex-TV technician to test their new CMS with an actual test pattern!" wrote Yves.
"Who would have thought that a newspaper hired an ex-TV technician to test their new CMS with an actual test pattern!" wrote Yves.
I have a philosophy on birthdays. The significant ones aren’t the numbers we usually choose- 18, 21, 40, whatever- it’s the ones where you need an extra bit. 2, 4, 8, and so on. By that standard, my next birthday landmark isn’t until 2044, and I’m a patient sort.
Christian inherited some legacy C# code which deals in birthdays. Specifically, it needs to be able to determine when your last birthday was. Now, you have to be a bit smarter than simply “lop off the year and insert this year,” since that could be a future birthday, but not that much smarter.
Testing for equality is hard. Equal references are certainly equal, but are equal values? What does it mean for two objects to “equal” each other? It’s especially hard in a language like JavaScript, which is “friendly” about type conversions.
In JavaScript land, you’re likely to favor a tool like “lodash”, which provides utility functions like isEqual
.
Remember Robert, the student who ruined his class curve back in the 1960s? Well, proving the old adage that the guy who graduates last from medical school is still a doctor, he managed to find another part-time job at a small hospital, earning just enough to pay his continued tuition.
It's a holiday in the US today, so we're reaching back into the archives while doing some quarantine grilling. This classic has a… special approach to handling enums. Original. --Remy
Ah yes, the enum
. It's a convenient way to give an integer a discrete domain of values, without having to worry about constants. But you see, therein lies the problem. What happens if you don't want to use an integer? Perhaps you'd like to use a string? Or a datetime? Or a char?
If that were the case, some might say just make a class that acts similarly, or then you clearly don't want an enum. But others, such as Dan Holmes' colleague, go a different route. They make sure they can fit chars into enums.
If nulls are a “billion dollar mistake”, then optional/nullable values are the $50 of material from the hardware store that you use to cover up that mistake. It hasn’t really fixed anything, but if you’re handy, you can avoid worrying too much about null references.
D. Dam Wichers found some “interesting” Java code that leverages optionals, and combines them with the other newish Java feature that everyone loves to misuse: streams.
Josh was writing some code to interact with an image sensor. “Fortunately” for Josh, a co-worker had already written a nice large pile of utility methods in C to make this “easy”.
So, when Josh wanted to know if the sensor was oriented in landscape or portrait (or horizontal/vertical), there was a handy method to retrieve that information:
It is my opinion that every developer should dabble in making their own scripting language at least once. Not to actually use, mind you, but to simply to learn how languages work. If you do find yourself building a system that needs to be extendable via scripts, don’t use your own language, but use a well understood and well-proven embeddable scripting language.
Which is why Neil spends a lot of time looking at Tcl. Tcl is far from a dead language, and its bundled in pretty much every Linux or Unix, including ones for embedded platforms, meaning it runs anywhere. It’s also a simple language, with its syntax described by a relatively simple collection of rules.
One of the advantages of a strongly typed language is that many kinds of errors can be caught at compile time. Without even running the code, you know you've made a mistake. This adds a layer of formality to your programs, which has the disadvantage of making it harder for a novice programmer to get started.
At least, that's my understanding of why every language that's designed to be "easy to use" defaults to being loosely typed. The result is that it's easy to get started, but then you inevitably end up asking yourself wat?
When I was still doing consulting, I had a client that wanted to create One App To Rule Them All: all of their business functions (and they had many) available in one single Angular application. They hoped each business unit would have their own module, but the whole thing could be tied together into one coherent experience by setting global stylesheets.
I am a professional, so I muted myself before I started laughing at them. I did give them some guidance, but also tried to set expectations. Ignore the technical challenges. The political challenges of getting every software team in the organization, the contracting teams they would bring in, the management teams that needed direction, all headed in the same direction were likely insurmountable.
More than twenty years ago, “BobC” wrote some code. This code was, at the time, relatively modern C++ code. One specific class controls a display, attached to a “Thingamobob” (technical factory term), and reporting on the state of a number of “Doohickeys”, which grows over time.
The code hasn’t been edited since BobC’s last change, but it had one little, tiny, insignificant problem. It would have seeming random crashes. They were rare, which was good, but “crashing software attached to factory equipment” isn’t good for anyone.
There are certain problem domains where we care more about the results and the output than the code itself. Gaming is the perfect example: game developers write "bad" code because clarity, readability, maintainability are often subordinate to schedules and the needs of a fun game. The same is true for scientific research: that incomprehensible blob of Fortran was somebody's PhD thesis, and it proved fundamental facts about the universe, so maybe don't judge it on how well written it is.
Sometimes, finance falls into similar place. Often, the software being developer has to implement obtuse business rules that accreted over decades of operation; sometimes it's trying to be a predictive model; sometimes a pointy-haired-boss got upset about how a dashboard looked and asked for the numbers to get fudged.
Before Evalia took a job at Initech, her predecessor, "JR" had to get fired first. That wasn't too much of a challenge, because JR claimed he was the "God of JavaScript". That was how he signed each of the tickets he handled in the ticket system.
JR was not, in fact, a god. Since then, Evalia has been trying to resuscitate the projects he had been working on. That's how she found this code.
There's bad date handling code. There's bad date formatting code. There's bad date handling code that abuses date formatting to stringify dates. There are cases where the developer clearly doesn't know the built-in date methods, and cases where they did, but clearly just didn't want to use them.
There's plenty of apocalypticly bad date handling options, but honestly, that gets a little boring after awhile. My personal favorite will always be the near misses. Code that almost, but not quite, "gets it".
Good idea: having QA developers who can build tooling to automate tests. Testing is tedious, testing needs to be executed repeatedly, and we're not just talking simple unit tests, but in an ideal world key functionality gets benchmarked against acceptance tests. API endpoints get routinely checked.
There's costs and benefits to this though. Each piece of automation is another piece of code that needs to be maintained. It needs to be modified as requirements change. It can have bugs.
While testing their application, Nicholas found some broken error messages. Specifically, they were the embarassing “printing out JavaScript values” types of errors, so obviously something was broken on the server side.
“Oh, that can’t be,” said his senior developer. “We have a module that turns all of the errors into friendly error messages. We use it everywhere, so that can’t be the problem.”
Let's say you have an audio file, or at least, something you suspect is an audio file. You want to parse through the file, checking the headers and importing the data. If the file is invalid, though, you want to raise an error. Let's further say that you're using a language like C++, which has structured exception handling.
Now, pretend you don't know how to actually use structured exception handling. How do you handle errors?