[9708] in Athena Bugs
Re: decmips 7.4G: Bug in tags.el
daemon@ATHENA.MIT.EDU (Mark W. Eichin)
Wed Jul 29 14:45:42 1992
Date: Wed, 29 Jul 92 14:44:51 EDT
From: "Mark W. Eichin" <eichin@cygnus.com>
To: "Reid M. Pinchback" <reidmp@Athena.MIT.EDU>
Cc: Marc Horowitz <marc@MIT.EDU>, bugs@Athena.MIT.EDU
In-Reply-To: [9703]
>> like "^tagname(" would only match functions that have *no* return type
>> information on the same line of the original source file. This would be
The FSF recommends that you put return type information on a
seperate line, in any case. (Not that it makes much difference to you,
I'm just pointing out that there is *intent* here, not just ignorance,
and that the complaint you have isn't much of a problem for the FSF.)
Appended to this message is the relevant section of the FSF
standards.texi, "GNU Coding Standards", from chapter "Formatting Your
Source Code."
_Mark_ <eichin@athena.mit.edu>
MIT Student Information Processing Board
>>>> It is also important for function definitions to start the name of the
>>>> function in column zero. This helps people to search for function
>>>> definitions, and may also help certain tools recognize them. Thus,
>>>> the proper format is this:
>>>>
>>>> @example
>>>> static char *
>>>> concat (s1, s2) /* Name starts in column zero here */
>>>> char *s1, *s2;
>>>> @{ /* Open brace in column zero here */
>>>> @dots{}
>>>> @}
>>>> @end example
>>>>
>>>> @noindent
>>>> or, if you want to use @sc{ANSI} C, format the definition like this:
>>>>
>>>> @example
>>>> static char *
>>>> concat (char *s1, char *s2)
>>>> @{
>>>> @dots{}
>>>> @}
>>>> @end example
