Posted by
Ferdinando M. Ametrano-2 on
Dec 20, 2000; 4:08pm
URL: http://quantlib.414.s1.nabble.com/Programming-styles-Feedback-tp1634p1635.html
Hi all
Gilbert wrote:
> Please send me your suggestions so I can put a
> draft together
my 0.2$ on programming styles
92. Replace Doc++ with Doxygen
>>87. I prefer to stack the arguments
>>
>> runThisRoutine (int numNodes, // Number of nodes
>> int* connectivityList) { // Elements connectivites
>> blah blah
>> }
>>
>>so one can comment each of the arguments individually.
>We might be forced to follow the Doxygen requirements here, if we want
>such comments to be extracted and put into the documentation. The Doxygen
>comment block would look like:
>
> /*! \brief short description of the method
> \param numNodes number of nodes
> \param connectivityList elements connectivities
> \return description of the returned value
> */
I would follow Doxygen requirements. Then argument stacking is probably
redundant, but it doesn't hurt
> 90) We'll have to stick to /* ... */ when comments
> are to be extracted by Doxygen.
Doxygen rules.
> 17) ok for employee.setName(). However, employee.getName() seems a
> bit redundant to me - employee.name() is just as clear.
> Unfortunately this would conflict with 6) since name() is not a
> verb (well, not in this case).
I prefer the set/get symmetry. This do not conflict with 6 ;-)
>>38. ...TABs should be avoided.
>Actually I though that inserting real tab characters instead of spaces
>allowed people to set the indentation to the number they like without
>conflicting with others... am I missing something obvious here?
The 80 column limit cannot allow for different TABs.
I would join Luigi and Gilbert in the "4 spaces" club
I agree on all the following statement:
> 5) I'd prefer enumerations inside classes and static const class
> variables in mixed case starting with lower case.
> 24. I usually use <num>, but <no> is as good. One may as well permit both
>36. [...] we can move the body of the methods outside the class
>definition. Of course they will stay in the header file for them to be
>inlined. One forced exception are template methods of a non-template
>class, which VC++ won't compile unless they are declared inside the class.
> 49) I would make an exception for static const variables,
> for which I see no reason for access through a get() method.
> 70) I like better example 1 for classes and functions too.
> 73. I prefer the SUN recommendation, but this has no big impact
> anyway, I think
> 83) f (x) looks very strange to me with the space in the middle.
ciao -- Nando