I tried not to weigh in on this, but my view on the materials we should use to 
build the bike shed must be shared!

Generally it seems neat to be able to make the code slightly more tight and 
terse by merging the function call and the return into a single statement.

Other than not being accustomed to it, I have noticed three small things I 
don’t like about using “return” with a call to a void-returning function.

- You can’t use this idiom when you want to ignore the result of a function, 
only if the function actually returns void. Often functions are designed with 
ignorable and often ignored return values. For example, it’s common to call 
something that might fail and have a good reason to ignore whether it failed or 
not. The idiom we are discussing requires treating those functions differently 
from ones that return void. If you refactor so that a function now returns an 
ignorable return value you need to visit all the call sites using return and 
change them into the two line form.

- It works for return, but not for break. I’ve seen at least one case where 
someone filled a switch statement with return statements instead of break 
statements so they could use this more-terse form. Now if we want to add one 
line of code after that switch, we need to convert all those cases into 
multi-line statements with break.

- Unless it’s mandatory, it’s a case where two programmers can make different 
style choices. If both forms are acceptable, then it introduces a little bit of 
disorder into our code.

One thing I like about it is that since “pass along the return value from this 
inner function to this outer function” can be written this way, the code can 
then survive refactorings where both the inner and outer functions might gain 
or lose the return value.

— Darin
webkit-dev mailing list

Reply via email to