Post by Chris Post by Andy Burns Post by Chris
Ideally, you get the user input, parse it to verify correct format and
only then, pass the year field to the conversion routine. Only a few
lines of added code needed to do it right.
Yes, but we're told this is 30 year old code, simpler times.
Simpler times perhaps, but such ambiguous looking code is a nightmare
for maintainers, having spent years trying to just that. Get the onpage
format and code structure right and it should flow like the lines of a
Phrases such as "It's in VAX C" or "It's K&R" is usually sufficient to
indicate derelict C code.
And that code is not ambiguous. It's dependent on the order of
evaluation; on the C operator precedence rules.
Would I write new code that way? No. But long ago, I also once wrote
***foo->bar and ilk. And I'm sorry that I wrote that C code.
Would I refactor that atoi() C code? Maybe. I'd certainly want to, but
that the code is still K&R C implies little or no management support
for that. And I'd want to know more context around the app and its
data, as home-grown parsers tend to be bug farms.
And have I blamed my tools? Absolutely. Having had my (bogus)
blame-the-tools claims rejected a few times in years past, now I use
the universal debugger printf, or the OpenVMS debugger, or occasionally
other tooling, and gather some evidence for the claims.
Aside: got a bug report about a permissions-related error in my code.
Dug into the app code, and found that a lower-level call in a
dependency was mis-coded, and the context where the lower-level code
went awry. Looked up the maintainer of the failing lower-level code,
and it was the bug submitter. Submitter was surprised to discover the
bug report reflected back and assigned to them—with troubleshooting and
a reproducer. Put differently, when the tools go sideways and I want
to blame those lower-level tools, gather or build a reproducer. That'll
then point to a flaw in my code or in the dependency, and it'll mean a
Pure Personal Opinion | HoffmanLabs LLC