(no title)
worstspotgain | 1 year ago
If:
1. You know where the 'creases' of orthogonality are. You've carved the turkey 1000 times and you never get it wrong anymore.
2. As a result, there is hardly any difference in complexity between code that is and isn't easy to extend.
Then write code that is easy to extend, not delete.
The question is whether your impression of the above is true. It won't be for most junior developers, and for many senior ones. If orthogonality isn't something you preoccupy yourself with, it probably won't be.
In my experience, the most telling heuristic is rewriting propensity. I'm talking about rewriting while writing, not about refactoring later. Unless something is obvious, you won't get the right design on the first write. You certainly won't get the correct extensible design. If you're instructed to write it just once, then by all means make it easy to delete.
blitzar|1 year ago
If you think you are good enough to qualify you almost certainly don't qualify. If you do qualify then chances are you probably don't think you do.
kraftman|1 year ago
worstspotgain|1 year ago
However, it's algebraically orthogonal. It has advantages in some cases, for instance if you later add code for a 6th-order polynomial and need to use its zeroes for something else.
We know that it could be better in some cases. Is it a good bet to predict that it will be better overall? The problem domain can fracture across a thousand orthogonal "creases" like this one. The relevant skill is in making the right bets.
Here's an example that's not orthogonal. Let's say we think the 6 coefficient might be more likely to change in the future:
This version is most likely just adding complexity. A single function is almost always a better bet.