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 webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
