3 ms·
Way back in the 1990s I worked in a place where we had to use Ada and follow a strict style guide. The guide prohibited using raw numeric types (such as "unsign
by jks 4y ago
Way back in the 1990s I worked in a place where we had to use Ada and follow a strict style guide. The guide prohibited using raw numeric types (such as "unsigned int" or "double" in C-like languages) and required creating a new type (https://en.wikibooks.org/wiki/Ada_Programming/Type_System#Defining_new_types_and_subtypes https://en.wikibooks.org/wiki/Ada_Programming/Type_System#De...) for each different quantity, such as temperature or speed. Then you couldn't assign a speed value to a temperature variable, or compare them to each other or do arithmetic, unless you specifically define what the operators mean.
It felt like a lot of busywork, but it did prevent some classes of bugs.
- ThePadawan 4y agoIn the mid-2010s I worked at a company that switched from using raw ints to refer to database rows to using (in C# terms) "Id<FooTable>". Across the entire codebase, we discovered an entire class of bugs that only never cause any issues because all the important rows in all the important tables had Id 1 (e.g. Currency 1 was USD and Country 1 was USA) - so in a few places where the ints got mixed up, the correct row was still accidentally looked up in the wrong table).
- russianGuy83829 4y agohow did that work out in the end?
- ThePadawan 4y agoI mean, no problem ever occurred. Things just accidentally worked even though they shouldn't, and that isn't a bug. The introduction of the additional types everywhere did turn into massive headaches based around dependency management and versioning. So overall, I was personally disappointed in the results, but nevertheless happy to work with less "icky" feeling code.
- Waterluvian 4y agoOh wow. Was there a “stomach sank to the floor” sudden feeling upon discovery?
- ThePadawan 4y agoNot really. The whole thing was kept together with tape and silly string anyway, and I bet it still is now, more than 5 years on.
- macintux 4y agoSomething I learned long ago, but occasionally disregard to my peril: if you see something that looks like a bug, but the code/system still works, stop and figure out why it works. It's very easy to mentally shrug and move on, but more often than not it comes back to bite you; maybe it's a code path that's rarely triggered, e.g.
- Winsaucerer 4y agoI have the same policy for similar circumstances. Sometimes, something isn't working, and I make a change that fixes it, but I didn't expect that change to fix it. Almost always it's worth me investigating why it's now working, because it indicates a deeper problem that would come back to bite me.
- jandrewrogers 4y agoMany C++ code bases still do this pervasively, it is a common practice to improve robustness. I don't know what it is like in Ada but C++ metaprogramming makes this not too onerous.