+1
> On Jan 8, 2020, at 9:02 PM, Patricia Shanahan <p...@acm.org> wrote:
>
> On 1/8/2020 5:55 PM, Dave Fisher wrote:
>> Hi -
>> See inline
>> Sent from my iPhone
>>> On Jan 8, 2020, at 3:44 PM, Peter Kovacs <pe...@apache.org> wrote:
>>>
>>> Hello again,
>>>
>>> hope I do not annoy anyone, with my questions.
>>> I have looked deeper in the issue using OpenGrok.
>>>
>>> Now the Issue seems pretty clear.
>>> We have only the function signatures:
>>>
>>> file: atkwrapper.hxx
>>> 85 AtkObject * atk_object_wrapper_new(
>>> 86 const ::com::sun::star::uno::Reference<
>>> ::com::sun::star::accessibility::XAccessible >& rxAccessible,
>>> 87 AtkObject* parent = NULL );
>>>
>>> And we have the call for the Function just above this one
>>> (file:atkwrapper.cxx):
>>> AtkObject *
>>> atk_object_wrapper_ref( const uno::Reference< accessibility::XAccessible >
>>> &rxAccessible, bool create )
>>> {
>>> g_return_val_if_fail( rxAccessible.get() != NULL, NULL );
>>>
>>> AtkObject *obj = ooo_wrapper_registry_get(rxAccessible);
>>> if( obj )
>>> {
>>> g_object_ref( obj );
>>> return obj;
>>> }
>>>
>>> if( create )
>>> return atk_object_wrapper_new( rxAccessible );
>>>
>>> return NULL;
>>> }
>>>
>>> So this is a bit confusing.
>>>
>>> Anyone objects if I refactor the above code so we have only one return
>>> statement at the end of the function? I think it is annoying and you
>>> quickly miss the exitpoints of the function.
>> You are doing this to make a code quality tool quiet?
>> You will need to carefully understand how to add else clauses to the code.
>> If the functions is long it will be tedious. Bad clauses will create very
>> subtle bugs. I would want to build often ....
>> Such changes may also make these functions slightly slower.
>> If you do this then I think you’ll want someone to review the diff.
>
> For some functions, single return is natural and clear. For others, the code
> is simpler, more readable, and clearer with multiple returns. I think this
> may be a case where I would prefer multiple returns, but I would be
> interested in seeing what it looks like if refactored, and open to the
> possibility that it might be clearer.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> <mailto:dev-unsubscr...@openoffice.apache.org>
> For additional commands, e-mail: dev-h...@openoffice.apache.org
> <mailto:dev-h...@openoffice.apache.org>
