Coding Practice Guidelines

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Coding Practice Guidelines

Gilbert Peffer
Hi everybody,

Beside the coding style guidelines, Jacob Dreyer from Geotechnical Software
Services has started writing C++ coding practice guidelines. You can find
them in http://geosoft.no/cpp.html.

His comment was that these guidlines are not yet finished and suggested that
one could finish this in a joint effort. The guidelines are mostly based on
Meyers.

What are your thoughts on this?

Thanks in advance

Gilbert



Reply | Threaded
Open this post in threaded view
|

RE: Coding Practice Guidelines

Gilbert Peffer
>
> It's ok with me. I assume you would be in charge of the thing, right? :)
>

My previous boss always managed, and never worked ;-) Yes, I will do the
typing ...



> Bye,
>          Luigi
>



Reply | Threaded
Open this post in threaded view
|

Re: Coding Practice Guidelines

Luigi Ballabio-3
In reply to this post by Gilbert Peffer
At 12:39 PM 1/24/01 +0100, Gilbert Peffer wrote:
>Beside the coding style guidelines, Jacob Dreyer from Geotechnical Software
>Services has started writing C++ coding practice guidelines. You can find
>them in http://geosoft.no/cpp.html.
>
>His comment was that these guidlines are not yet finished and suggested that
>one could finish this in a joint effort. The guidelines are mostly based on
>Meyers.
>
>What are your thoughts on this?

I had a look at the thing and I agree with the recommendations - I actually
use them already, which wasn't true for the previous batch :)

The only thing I would correct is the "must" in

28. A public member function must never return a non-const reference or
pointer to member data

which doesn't take into account members like Array::operator[](int).
While the above might violate encapsulation as argued,
a[4] = 3.5
is _much_ clearer than
a.setElement(4,3.5)
or whatever other name you give it.

Bye,
         Luigi



Reply | Threaded
Open this post in threaded view
|

RE: Coding Practice Guidelines

Gilbert Peffer
Hi Luigi,
Since the guidelines are not comlpete, what are your thoughts on the idea to
complete them together with the guys in Norway?
Gilbert

> -----Mensaje original-----
> De: [hidden email]
> [mailto:[hidden email]]En nombre de Luigi
> Ballabio
> Enviado el: 24 January 2001 15:43
> Para: QuantLib Users
> Asunto: Re: [Quantlib-users] Coding Practice Guidelines
>
>
> At 12:39 PM 1/24/01 +0100, Gilbert Peffer wrote:
> >Beside the coding style guidelines, Jacob Dreyer from
> Geotechnical Software
> >Services has started writing C++ coding practice guidelines. You can find
> >them in http://geosoft.no/cpp.html.
> >
> >His comment was that these guidlines are not yet finished and
> suggested that
> >one could finish this in a joint effort. The guidelines are
> mostly based on
> >Meyers.
> >
> >What are your thoughts on this?
>
> I had a look at the thing and I agree with the recommendations -
> I actually
> use them already, which wasn't true for the previous batch :)
>
> The only thing I would correct is the "must" in
>
> 28. A public member function must never return a non-const reference or
> pointer to member data
>
> which doesn't take into account members like Array::operator[](int).
> While the above might violate encapsulation as argued,
> a[4] = 3.5
> is _much_ clearer than
> a.setElement(4,3.5)
> or whatever other name you give it.
>
> Bye,
>          Luigi
>
>
> _______________________________________________
> Quantlib-users mailing list
> [hidden email]
> http://lists.sourceforge.net/lists/listinfo/quantlib-users
>