octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: goto vs. return?


From: Rik
Subject: Re: goto vs. return?
Date: Mon, 25 Jan 2016 13:40:50 -0800

On 01/25/2016 11:46 AM, John W. Eaton wrote:
> On 01/23/2016 05:27 PM, Rik wrote:
>> According to the Appendix in the manual on Contributing to Octave,
>>
>> "Avoid comma expressions, labels and gotos, and explicit typecasts. If
>> you need
>> to typecast, use the modern C++ casting operators. In functions,
>> minimize the
>> number of return statements—use nested if statements if possible."
>>
>> Which do we dislike more: goto statements or return from the middle of a
>> function?
>>
>> I ask because I count 134 uses of goto in liboctave.  I think most of these
>> can be avoided now that the error_handler routine no longer returns.  The
>> others could probably be removed if we used return rather than goto in the
>> middle of a function.
>>
>> I personally dislike goto more than return and would remove it, but maybe
>> there is a consensus in the other direction.
>
> I'm not sure, but I think I typically chose goto when there might be some
> extra common processing to do before returning.

That's an appropriate use of goto and needs to stay.

I'm thinking of things like this from dMatrix.cc

-- Code --
operator >> (std::istream& is, Matrix& a)
{
  octave_idx_type nr = a.rows ();
  octave_idx_type nc = a.cols ();

  if (nr > 0 && nc > 0)
    {
      double tmp;
      for (octave_idx_type i = 0; i < nr; i++)
        for (octave_idx_type j = 0; j < nc; j++)
          {
            tmp = octave_read_value<double> (is);
            if (is)
              a.elem (i, j) = tmp;
            else
              goto done;
          }
    }

done:

  return is;
}
-- End Code --

It seems easy to clear the goto and just use "return is;" in the if/else.
 
>
> Unfortunately, I don't think any particular style can guarantee clarity.
>

Alas, too true.  No guarantees in life, but I still like to strive for clarity.

--Rik




reply via email to

[Prev in Thread] Current Thread [Next in Thread]