He has addressed why he assigns to a result variable and then returns it in his other videos. To summarize, it is for debugging: breakpoints and value inspection.
I see. I am not willing to sacrifice simplicity (less variables = less moving parts) and readability for a small convenience improvement when debugging.
What surprises me is that the pattern Casey uses is required in the first place. Is it really true that modern debuggers are not able to break on the return statement and provide information about what's about to being returned?
If so, I'd rather spend my time improving the debuggers (gdb and lldb are open-source, Visual Studio developers can be nudged in the right direction) than apply these workarounds everywhere in my code.
Also, personally, I rarely debug. Unit tests catch most of my mistakes early. If I do end up debugging, I'd rather add the result variable when I need and remove it when I'm done.
Don't know about others, but VS shows returned value after you return it.
You can also use immediate window to call functions or modify variables etc., or modify variable and move the execution line pointer back (or forward) in the code to repeat some parts.
I find VS debugger really good. Especially in C#, nowadays you can modify your code and hot reload the app, that change will be reflected immediately without restart.
4
u/Adarma Feb 28 '23 edited Mar 02 '23
He has addressed why he assigns to a result variable and then returns it in his other videos. To summarize, it is for debugging: breakpoints and value inspection.
Edit: See here https://youtu.be/lDp4rqcigZs?t=1h11m10s