4 ms·

> they alter the code to take a parameter, and then add logic to conditionally do the right thing based on the value of that parameter But that's a textbook ex

> they alter the code to take a parameter, and then add logic to conditionally do the right thing based on the value of that parameter But that's a textbook example of bad code, competent coders don't do this. Update: for example see Thinking Forth chapter "Factoring Techniques", around the tip "Don’t pass control flags downward.". Page 174 in the onscreen PDF downloadable from sourceforge. And there is no need for duplication. The bigger function can be split into several parts so that instead of one call with flag everyone calls needed set of smaller functions.

dragonwriter 6y ago
Competent coders do suboptimal things all the time, especially when there is delivery pressure; competent doesn't mean infallible or perfect. There's also not a clear boundary between what is a single appropriate abstraction and two (or N) distinct but superficially related concepts.
zbentley 6y ago
> that's a textbook example of bad code, competent coders don't do this. That's reductive and dismissive. There's a ton of subtlety in even defining the terms for that "best practice". What counts as a control flag versus a necessary choice that must be made by callers? Are you still passing control flags if you combine them into a settings object? What if you use a builder pattern to configure flags before invoking the business logic--is that better/worse/the same? What if you capture settings inside a closure and pass that around as a callback? How far "downward" is too far? How far is not far enough (e.g. all callers are inlining every decision point)? The answer to all of those is, of course, "it depends on a lot of things". And that's before you even get into the reality (which a sibling comment pointed out) that even if we grant that this is inherently bad code, that doesn't imply anything about the competence of the coder--some folks aren't put in positions where they can do a good job. Unrelated aside: Thinking Forth is an excellent book! Easy to jump into/out of in a "bite size" way, applicable to all sorts of programming, not just Forth programming.

dragonwriter 6y ago

Competent coders do suboptimal things all the time, especially when there is delivery pressure; competent doesn't mean infallible or perfect. There's also not a clear boundary between what is a single appropriate abstraction and two (or N) distinct but superficially related concepts.

zbentley 6y ago

> that's a textbook example of bad code, competent coders don't do this. That's reductive and dismissive. There's a ton of subtlety in even defining the terms for that "best practice". What counts as a control flag versus a necessary choice that must be made by callers? Are you still passing control flags if you combine them into a settings object? What if you use a builder pattern to configure flags before invoking the business logic--is that better/worse/the same? What if you capture settings inside a closure and pass that around as a callback? How far "downward" is too far? How far is not far enough (e.g. all callers are inlining every decision point)? The answer to all of those is, of course, "it depends on a lot of things". And that's before you even get into the reality (which a sibling comment pointed out) that even if we grant that this is inherently bad code, that doesn't imply anything about the competence of the coder--some folks aren't put in positions where they can do a good job. Unrelated aside: Thinking Forth is an excellent book! Easy to jump into/out of in a "bite size" way, applicable to all sorts of programming, not just Forth programming.