The Documentation/kernel-doc-nano-HOWTO.txt says that functions
should be documented as so:
/**
* foobar() - short function description of foobar
I notice there are a number of places that ommit the () off the
foobar, for example:
include/linux/skbuff.h, line 461:
/**
* skb_get - reference buffer
* @skb: buffer to reference
where skb_get does not have ()s.
As a note, it seems the default debian emacs does not colour the
function name unless it ends ().
Also, is there any policy on tabs vs a single space for indenting
these comments?
--
Ben ([email protected], http://www.fluff.org/)
'a smiley only costs 4 bytes'
Ben Dooks wrote:
> The Documentation/kernel-doc-nano-HOWTO.txt says that functions
> should be documented as so:
That's an example. There is no "should" with that example.
> /**
> * foobar() - short function description of foobar
>
> I notice there are a number of places that ommit the () off the
> foobar, for example:
>
> include/linux/skbuff.h, line 461:
>
> /**
> * skb_get - reference buffer
> * @skb: buffer to reference
>
> where skb_get does not have ()s.
That's perfectly fine. The "formal" syntax is given later in that file:
The format of the block comment is like this:
/**
* function_name(:)? (- short description)?
(* @parameterx(space)*: (description of parameter x)?)*
(* a blank line)?
* (Description:)? (Description of function)?
* (section header: (section description)? )*
(*)?*/
and those parentheses are (confusing) grouping characters, not literals. :(
> As a note, it seems the default debian emacs does not colour the
> function name unless it ends ().
File a bug with debian?
> Also, is there any policy on tabs vs a single space for indenting
> these comments?
Nope. I prefer a single space, but some people seem to prefer tab(s).
~Randy