Timeline for Does "variables should live in the smallest scope as possible" include the case "variables should not exist if possible"?
Current License: CC BY-SA 4.0
12 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 25, 2019 at 18:20 | audit | First posts | |||
| Mar 26, 2019 at 9:11 | |||||
| Mar 13, 2019 at 8:03 | comment | added | Christian Hackl | @GabeSechan: I didn't say that every debugger can do it. My point is simply that a good debugger must be able to do it. Which means that Android Studio until recently just didn't have a good debugger. Re no costs: it can decrease clarity, and that is a cost. It can also increase clarity, of course. That depends. I maintain that it's not a question of debugging (unless you use a bad debugger). Note that depending on the programming language, turning an unnamed object into a named one can also change program semantics (C++ with destructors comes to mind). | |
| Mar 13, 2019 at 6:48 | comment | added | Gabe Sechan | After all- saving it in a local variable costs nothing, does not decrease clarity, is likely optimized out in actual executable code, and saves you time if you later need to reuse the result. Favoring the other way in all cases or refactoring away from a local variable is low to no gain and frequently a loss. | |
| Mar 13, 2019 at 6:46 | comment | added | Gabe Sechan | @ChristianHackl I can't think of only a few that do. I know until recently the AndroidStudio debugger didn't. and even now that it does, it allows limited introspection in any debugger- for example if you save it in a variable you can run a runtime expression on it. You can't do that on the return of a function call (without running the function again, which may have side effects). Obviously not every function call should/needs to be put in a variable, but its never wrong to do so, and for data you're likely to want to introspect it SHOULD be done. | |
| Mar 13, 2019 at 6:39 | comment | added | Christian Hackl | @GabeSechan: I cannot currently think of any debugger that doesn't let you do that. But for example, it's not a problem at all in Visual Studio when debugging C++ code, and that's a free, total mainstream tool. | |
| Mar 13, 2019 at 1:54 | comment | added | user64742 | @ChristianHackl and to build on that further even if the debugger doesn't let you do that by default because the debugger is horribly designed, you can just modify the local code on your machine to store the result and then check it out in the debugger. There's still no reason to store a value in a variable for just that purpose. | |
| Mar 12, 2019 at 18:08 | comment | added | Gabe Sechan | @ChristianHackl Very few debuggesr let you do that without setting up possibly complex watches that take time to add in (and if the functions have side effects may break everything). I'll take the with variables version for debugging any day of the week. | |
| Mar 12, 2019 at 13:45 | comment | added | Christian Hackl | @Joker_vD: A debugger worthy of its name should be able to let you do all of that anyway (view the results of a function call without storing it in a local variable + setting a breakpoint on function exit). | |
| Mar 12, 2019 at 13:24 | comment | added | Joker_vD |
On of the benefits of "extraneous" variables such as var result = getResult(...); return result; is that you can put a breakpoint on return and learn what exactly result is.
|
|
| Mar 12, 2019 at 8:14 | comment | added | Luaan | Of course, by the point a method gets so long that the number of locals is too large to be easily maintainable, you probably want to break it up anyway. | |
| Mar 12, 2019 at 7:28 | history | edited | JacquesB | CC BY-SA 4.0 |
added 429 characters in body
|
| Mar 12, 2019 at 7:20 | history | answered | JacquesB | CC BY-SA 4.0 |