Timeline for Is it wrong to use a boolean parameter to determine behavior?
Current License: CC BY-SA 3.0
15 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 1, 2019 at 17:37 | comment | added | Alex | @gherman then you'd have methods doThis and doThisAndThat. | |
| May 12, 2018 at 10:23 | history | wiki removed | Thomas Owens♦ | ||
| Mar 7, 2018 at 14:19 | comment | added | Gherman | What if doThat clearly makes no sense at all without doThis? | |
| Jan 17, 2018 at 9:30 | comment | added | Francis Cugler | Pardon the pun but the code-smell to me is sort of like this analogy... skinning a deer from head to tail or skinning a deer from tail to head. There is always more than 1 way to program a piece of code that will do the exact same thing and in both cases they can be viably correct, but both with their own flaws. One has to weigh the trade offs to find the middle ground and balance between the two, and no matter which preference style they prefer to use, they just need to stay consistent with it. | |
| Jan 11, 2018 at 13:21 | comment | added | anon | This may be true for if (flag) doThat();, however, in my experience it's more common to see if (flag) doThat(local_variable); so that pulling the doThat out requires you to expose what would otherwise be a private variable. This is not so clearly a good thing. | |
| Jul 28, 2017 at 13:07 | history | edited | Deduplicator | CC BY-SA 3.0 | added 31 characters in body |
| May 23, 2017 at 12:40 | history | edited | CommunityBot | replaced http://stackoverflow.com/ with https://stackoverflow.com/ | |
| Mar 5, 2013 at 23:30 | history | made wiki | Post Made Community Wiki by Eva | ||
| May 10, 2012 at 20:46 | comment | added | Alex | If calling two methods one after the other or one method alone can be considered redundant then it's also redundant how you write a try-catch block or maybe an if else. Does it mean you will write a function to abstract all of them? No! Be careful, creating one method that all it does is calling two other methods does not necessarily represent a good abstraction. | |
| May 10, 2012 at 20:19 | comment | added | Blrfl | @missingno: You'd still have the same problem of pushing redundant code out to callers to make the doOne() or doBoth() decision. Subroutines/functions/methods have arguments so their behavior can be varied. Using an enum for a truly Boolean condition sounds a lot like repeating yourself if the name of the argument already explains what it does. | |
| May 10, 2012 at 19:40 | comment | added | hugomg | @Blrfl: Yes, I think the more straightforward refactorings would be either creating a doOne and doBoth methods (for the false and true case, respectively) or using a separate enum type, as suggested by James Youngman | |
| May 10, 2012 at 16:33 | history | edited | Alex | CC BY-SA 3.0 | added 152 characters in body |
| May 10, 2012 at 13:46 | comment | added | Blrfl | There are lots of situations where if (flag) doThat() inside foo() is legitimate. Pushing the decision about invoking doThat() to every caller forces repetition that will have to be removed if you later find out for some methods, the flag behavior also needs to call doTheOther(). I'd much rather put dependencies between methods in the same class than have to go scour all of the callers later. | |
| May 10, 2012 at 11:00 | comment | added | Ray | Thanks for calling out the term "code smell"--I knew it smelled bad, but couldn't quite get at what the smell was. Your example is pretty much spot-on with what I'm looking at. | |
| May 10, 2012 at 1:53 | history | answered | Alex | CC BY-SA 3.0 |