Change comment style to use @foo rather than FOO

... when referring to a function's parameter or a struct/union's
member.

The idea of using FOO comes from the GNU coding standards:

    The comment on a function is much clearer if you use the argument
    names to speak about the argument values.  The variable name
    itself should be lower case, but write it in upper case when you
    are speaking about the value rather than the variable itself.
    Thus, "the inode number NODE_NUM" rather than "an inode".

Upcasing names is problematic for a case-sensitive language like C,
because it can create ambiguity.  Moreover, it's too much shouting for
my taste.

GTK-Doc's convention to prefix the identifier with @ makes references
to variables stand out nicely.  The rest of the GTK-Doc conventions
make no sense for us, however.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
This commit is contained in:
Markus Armbruster 2015-06-14 10:33:43 +02:00
parent 5cff5022a9
commit 9f25de3dce
77 changed files with 633 additions and 633 deletions

View file

@ -233,8 +233,8 @@ def_support(coord x, coord y, natid victim, natid actee)
}
/*
* Perform support missions in X,Y against VICTIM for ACTEE.
* MISSION is either MI_OSUPPORT or MI_DSUPPORT.
* Perform support missions in @x,@y against @victim for @actee.
* @mission is either MI_OSUPPORT or MI_DSUPPORT.
* Return total damage.
*/
static int
@ -747,7 +747,7 @@ mission_name(int mission)
}
/*
* Maximum distance GP can perform its mission.
* Maximum distance @gp can perform its mission.
* Note: this has nothing to do with the radius of the op-area.
* oprange() governs where the unit *can* strike, the op-area governs
* where the player wants it to strike.
@ -773,7 +773,7 @@ oprange(struct empobj *gp)
}
/*
* Does GP's mission op area cover X,Y?
* Does @gp's mission op area cover @x,@y?
*/
int
in_oparea(struct empobj *gp, coord x, coord y)