solved with the removal of the word const from the legacy code
May I point out that this sounds very much like the C++ equivalent of "the data might change and we wouldn't want the validation to fail"?
Unless, of course, the person who wrote the code in the first place just left random "const" modifiers lying around for no reason whatsoever. In which case obviously taking them out would indeed be the fix.
Also note that for bonus points, sometimes you can leave the "const" in, but add one or two tactical uses of "mutable". If you're lucky, the resulting code will be utterly incomprehensible and unmaintainable.
double pointers
If in doubt, refactor these to be references to pointers.
iterators
Iterators rock, especially if someone cleverly invalidates them by modifying the underlying collection while you're trying to iterate. Remember: for full marks you must use the overloaded difference_type operator-(Iterator &) of random access iterators at every opportunity, preferably more than once in a single expression, in contexts where it isn't immediately obvious whether the thing you're subtracting is an integer or an iterator. Unwary maintenance programmers will always initially assume that it's an integer, and the rest of the code won't make any sense at all.
For example, for iterators k, l and integers i, j, m, declared at least a screen ago, but ideally globals in a header somewhere, do:
i = ++k-(l-j)-m--;
If you're really lucky, the maintenance coder will get the operator precedence and associativity wrong, too. They might even notice that it doesn't matter how tightly the initial ++ binds, and be lulled into assuming the same is true of the final --. Tricks like k = l+++++i are popular too, but are a bit last millennium.
private functions
Where possible, declare all your internal crap in the public header file, so that other programmers can see it, and think "oh, ffs, if that was public I'd be finished in 5 minutes".
May I point out that this sounds very much like the C++ equivalent of "the data might change and we wouldn't want the validation to fail"?
Unless, of course, the person who wrote the code in the first place just left random "const" modifiers lying around for no reason whatsoever. In which case obviously taking them out would indeed be the fix.
Also note that for bonus points, sometimes you can leave the "const" in, but add one or two tactical uses of "mutable". If you're lucky, the resulting code will be utterly incomprehensible and unmaintainable.
double pointers
If in doubt, refactor these to be references to pointers.
iterators
Iterators rock, especially if someone cleverly invalidates them by modifying the underlying collection while you're trying to iterate. Remember: for full marks you must use the overloaded difference_type operator-(Iterator &) of random access iterators at every opportunity, preferably more than once in a single expression, in contexts where it isn't immediately obvious whether the thing you're subtracting is an integer or an iterator. Unwary maintenance programmers will always initially assume that it's an integer, and the rest of the code won't make any sense at all.
For example, for iterators k, l and integers i, j, m, declared at least a screen ago, but ideally globals in a header somewhere, do:
i = ++k-(l-j)-m--;
If you're really lucky, the maintenance coder will get the operator precedence and associativity wrong, too. They might even notice that it doesn't matter how tightly the initial ++ binds, and be lulled into assuming the same is true of the final --. Tricks like k = l+++++i are popular too, but are a bit last millennium.
private functions
Where possible, declare all your internal crap in the public header file, so that other programmers can see it, and think "oh, ffs, if that was public I'd be finished in 5 minutes".
Reply
Leave a comment