DigitalDuck wrote: ↑Thu Mar 01, 2018 7:56 am
Flatfingers wrote: ↑Thu Mar 01, 2018 12:41 am
I also intend to continue wrapping return values in parentheses:
return(value);
I don't do this for single variables or values, but if I'm returning anything more complex I always wrap it in parentheses. It doesn't feel right to do
return i * 2;
and I have no idea why.
Maybe it's just the voice of experience. "If it's a thing I can control, I must do so, rather than letting the compiler/interpreter writer do a thing I might not have anticipated."
Actually... this is not in any way a criticism, just a kind of odd observation, but -- this side-track into discussion of how to end functions reminds me of a couple other coding quirks that I persist in using:
1. I never return anything other than a single value. In nearly every case this means doing all my calculations and/or concatenations before the end of the function, and putting the final value to be returned into a variable then returning that variable.
If I still coded down to the metal or needed to save bytes (some of my first programming was done in 3.5K of RAM), I might not do this to avoid the cycles or memory needed for another variable. But it feels like those days are long past. So since then I've preferred to emphasize clarity. Returning a variable rather than an operation just feels a little safer, as though it forces me to be more specific about what I'm returning. That might be only a perception, though.
2. I never have more than one return() in a function. I will literally design the logic of my code such that there is never more than one return() in any code I write, and it is always the very last statement of the function.
This comes from being burned, originally in my own code but occasionally when having to work with the code of other people, by a stealth return() buried somewhere in the middle of a function. I hate wasting the time and focus needed to remember, "Oh, yeah, for this function, but not that one, I return half-way through."
By always structuring my logic so that there's always only one return(), and it's always the final statement, the high-level logical path for every function feels a little easier to keep straight in my head. In theory, this might result in some tortured logic, but in [mumblety-mumble] years of programming I can't think of any time when this happened. The worst that ever happens is that I have to declare a return code variable, and then instead of returning immediately put the appropriate return code into its variable holder, test it in the place where I would have returned, and as the "else" of that test fall through to the end of the function where the return() lives. It does add a variable that I have to be aware of, but the payoff is that I'm guaranteed there's only one place where the function returns to its caller.
Again, that there's any value in this might be just perception on my part, so I'm sort of nervously curious what some of the other (and better) coders here think of this quirk.
