Login  Register

Coding Practice Guidelines

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

Coding Practice Guidelines

Gilbert Peffer
42 posts
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
| More
Print post
Permalink

RE: Coding Practice Guidelines

Gilbert Peffer
42 posts
>
> 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
| More
Print post
Permalink

Re: Coding Practice Guidelines

Luigi Ballabio-3
34 posts
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
| More
Print post
Permalink

RE: Coding Practice Guidelines

Gilbert Peffer
42 posts
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
>