Re: Best practices in writing functions

[c.]

On 4 Sep 2013, at 11:18, Richard Kirk <address@hidden> wrote:

> Hi.
> 
> I have also wanted a guide for writing oct-file .cpp code.

well, let's start standardization from here, we usually prefer the extension 
.cc for C++ files in Octave (and we use .h rather than .hpp for headers)

> Most of my stuff is rushed up to fulfil a particular need, and so is unlikely 
> to be of use to anyone else. However, I would like to think I could write 
> something that could last and be used by anyone if I needed to.

We are working on a site where such code could be "dumped" just in case someone 
ever needs it at any later time:

  http://agora.octave.org/

It is not yet functional and I have no idea when or if it will ever be, though 
...

> Perhaps I am going about this the wrong way. There are many ways of writing 
> 'good code' and there are endless arguments about style.

indeed arguments about style are usually going nowhere, many things are just a 
matter of taste.
Using a consistent coding style, though, greatly improves readability and 
speeds up understanding the code, 
so we do have some general guidelines:

  
http://www.gnu.org/software/octave/doc/interpreter/General-Guidelines.html#General-Guidelines

does are actually an adapted version of the GNU coding style guidelines, which 
makes a lot of sense Octave being part of GNU.

> Perhaps we should have a Hall of Fame of Good Examples nominated from the 
> existing database. The actual functions in the examples is not important, 
> though something simple and easy to understand is better than something 
> complicated, advanced, or obscure. The main thing is to have a neat and solid 
> parsing of the inputs, and a helpful reaction to errors.

input parsing is mainly left to the function implementors but most type 
checking and related errors are handled reasonably well by the the *_value() 
methods of the class octave_value.

> I have no good suggestions, but maybe someone else has.

If it will be ever completed, Agora is expected to include the possibility to 
comment and vote on uploaded code snippets, that seems something similar to 
what you propose.

> Cheers.
> Richard Kirk

c.