Timeline for Many nested session verification conditions
Current License: CC BY-SA 3.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 16, 2016 at 21:23 | comment | added | cFreed |
@RedLaser Yes, I feel the same. Your post was the occasion to step back from my current practice to meditate about it, and I actually think that it's probably good to consider it like a kind of ready-made "tool": always begin with switch(true) then put every case: you want, which may be of any complexity.
|
|
| Jan 16, 2016 at 21:01 | comment | added | RedLaser | Good point, I just felt that it would be better to reduce operations although it's not going to majorly impact performance so i guess it would be better to optimize for readability. | |
| Jan 16, 2016 at 20:59 | comment | added | cFreed | @RedLaser According to your remark I was to edit my answer, but I suddenly hesitate: while it's technically irreproachable, I feel it less obvious for readability. | |
| Jan 16, 2016 at 20:56 | comment | added | cFreed |
@RedLaser Good insight, you're right! I'm (too) used to employ this form with more complex cases, so I automatically initiate with false.
|
|
| Jan 16, 2016 at 20:52 | history | edited | cFreed | CC BY-SA 3.0 |
added 13 characters in body
|
| Jan 16, 2016 at 20:52 | comment | added | RedLaser | Just wondering, could you not use switch(false) and avoid using those negations on each case? | |
| Jan 16, 2016 at 20:41 | history | answered | cFreed | CC BY-SA 3.0 |