Timeline for Inverting an IF statement
Current License: CC BY-SA 3.0
20 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 29, 2017 at 11:44 | vote | accept | Barry Franklin | ||
| Jul 27, 2017 at 19:39 | comment | added | radarbob | "popular delusion that break, continue and multiple return are not structured." - It's sort like gun control, an all or nothing knee jerk reaction because there will always be some incompetents who will shoot themselves and others (poor maintenance programmer) in the foot. | |
| Jul 26, 2017 at 15:52 | comment | added | JimmyJames | Let us continue this discussion in chat. | |
| Jul 26, 2017 at 13:57 | comment | added | psmears |
@JimmyJames: A program within the definition of structured programming; in modern terms that roughly corresponds to statements within a method body. It's hardly "stacking the deck" - this stuff comes from a time before "methods" as understood today were at all common! And it is still highly relevant even within a method; basically any sort of return or similar in the middle of a method body forces you to understand the entire control flow just in order to check a resource obtained at the start always gets released before the end.
|
|
| Jul 26, 2017 at 13:42 | comment | added | JimmyJames | @psmears I think you have to define what a program is here. If K1 is a function/method and K2 is a method. It doesn't matter if they return early or have a single return at the end: the condition holds. If you are talking about munging the bodies of two methods together, I see what you mean but I think it's a bit of stacking the deck. The requirement that methods always return to the same point of the program is a key language construct in structured languages. Methods are not simple holders for blocks code. | |
| Jul 26, 2017 at 13:31 | comment | added | JimmyJames | @psmears Thanks. I couldn't even see that until you pointed it out. | |
| Jul 26, 2017 at 13:30 | comment | added | psmears | @JimmyJames: I think your original comment has a typo ("there of" should be "there is") which is probably what is confusing people :) | |
| Jul 26, 2017 at 13:30 | comment | added | JimmyJames | @Ewan In the case there is a single guard condition, the change in the number of blocks is small (although the change in the number of brackets isn't). When you have more than one, though, the code is much simpler with guard conditions. | |
| Jul 26, 2017 at 13:29 | comment | added | psmears |
@JimmyJames: There's no "delusion" - it's a simple fact that break etc aren't structured, within the original meaning of "structured programming" as conceived by Dijkstra et al. Whether that makes them "bad" is a different question, of course - but one of the key ideas of SP is that, if you have any piece of code K1 that, run in an initial state A, will achieve state B, and another piece of code K2 that, given state B will achieve state C, then the program K1;K2 (ie running K1 then K2) in state A will always achieve state C. Thow in a break/goto etc in and that no longer applies.
|
|
| Jul 26, 2017 at 13:27 | comment | added | JimmyJames | @PJTraill Clearly there is a measure of preference here. Both are valid ways to do things. My experience is that when I refactor code with guard conditions, I often find that there are bugs and or dead code that was very hard to see in the nested version. This is true for both code I wrote as nested and code written by others. | |
| Jul 26, 2017 at 13:22 | comment | added | JimmyJames | @corsiKa That's unfortunate. If you don't mind elaborating on what was problematic about it, I'm always looking to improve my communication skills. | |
| Jul 26, 2017 at 11:16 | comment | added | Ewan | I think there are exactly the same number of blocks for either version of the same code. after all if you have an else or following code you also want it in the early return version | |
| Jul 26, 2017 at 11:08 | comment | added | Matthieu M. |
@Ewan: I think break/continue/return have a real advantage over an else block. With early get outs, there are 2 blocks: the get-out block and the stay there block; with else there are 3 blocks: if, else, and whatever comes after (which is used whatever the branch taken). I prefer having less blocks.
|
|
| Jul 26, 2017 at 10:56 | comment | added | PJTraill |
@JimmyJames: For me it is not that break, continue and multiple return are not structured but that the structure is made visible by the brackets and/or nesting, which I find far easier to see than keywords, even with syntax highlighting.
|
|
| Jul 25, 2017 at 21:45 | comment | added | corsiKa | @JimmyJames I had to read your comment five times before I could determine your position on multiple returns. | |
| Jul 25, 2017 at 19:44 | comment | added | Ewan | nothing is the complexity and meaning of the x which is important | |
| Jul 25, 2017 at 19:41 | comment | added | Collin | @Ewan: What's the difference between 'this cant be x or it would have exited the loop at the top' and 'this can't be x or it wouldn't have entered this block'? | |
| Jul 25, 2017 at 15:13 | comment | added | Ewan | the trouble is break etc are still control flow you have to keep in your head 'this cant be x or it would have exited the loop at the top' might not need further thought if its a null check which would throw an exception anyway. But its not so good when its more nuanced 'only run half this code for this status on thursdays' | |
| Jul 25, 2017 at 13:45 | comment | added | JimmyJames |
I love to see the tide of developer opinion going this way. There's so much nesting in code simply because there of an extraordinary popular delusion that break, continue and multiple return are not structured.
|
|
| Jul 25, 2017 at 11:55 | history | answered | Andy | CC BY-SA 3.0 |