On Sun, Jul 13, 2008 at 07:40:16PM +0200, J.B.C.Engelen@...1578... wrote:

I have some discussion points on code cleanup topics:

2. isinf.h defines a lower-case macro. Can I add to the coding

standard that all #defines should be capitalized?

C.f. macros like putc and stderr. If callers don't need to know that it's a macro (most importantly, it evaluates each of its arguments exactly once, and the definition is wrapped in parens), then it's fine for the macro to be in lower-case -- and in fact is better, in order to draw extra attention to macros that need special care ("the boy who cried wolf").

In the case of isinf, one of the definitions (on Solaris) evaluates the argument twice in some executions, so it should either be changed to an inline function or indeed changed to an uppercase name. I'd have thought that the former would be better.

3. sigil spacing. Apparently most of Inkscape's code puts no space

between sigil (*/&) and the following variable name. The coding style document doesn't explicitly mention this, shall I add it? So: "int const * get_int(double &johan);"

Excerpt from http://www.inkscape.org/doc/coding_style.php :

# Space between a type name/qualifier and pointer/reference sigil # # - e.g. "char *" and "int &", versus "char*" and "int&" # # - Doing so promotes better understanding of C/C++'s parsing rules for cases # like int *a, b: the sigil applies only to a in that example, not to b. # # - It is sometimes argued that the sigil is part of the type, but even # primitive types may have space between their tokens (e.g. unsigned long).

It indeed does not explicitly say no space between sigil and following identifier [contrary to what I've privately said to Johan without checking -- sorry].

OTOH, the example code in the second point does have no space between the sigil and the identifier, and the rationale of the second point supports that (i.e. makes it clear that syntactically the sigil belongs to the identifier, and that in `int *a(), b()' the return type of b is int rather than int*).

On the third/first hand, the question is not properly addressed: there is no listing of counterarguments on this matter either in this document or the corresponding wiki page (linked to from the top of this page).

I've now added a section to the wiki discussing the question. Or rather, I've tried to add such a section, but the final "Save changes" isn't working... I'll try again later.

pjrm.