C.9. Functions

C.9.1. Function Prototypes

All application functions and private functions in the libraries should be declared static. Public functions in the library should not include this keyword.

All functions must be prototyped using the full ANSI C style and indented for clarity. For example:

/*
** Prototype definitions
*/

void        ajListPushAppend (AjPList list, AjPListNode* tail);
AjPList     ajListNewListref (const AjPList list);
void        ajListExit       (void);
AjBool      ajListPeekFirst  (const AjPList thys, void** x);
void        ajListFree       (AjPList *list);

C.9.2. Implicit Declarations

Examples of these would be:

extern fubar(int x);
main(int argc, char **argv)

Do not use them. Always specify what a function should return. This is better:

extern int fubar(int x);
int main(int argc, char **argv)

C.9.3. Function and Parameter Names

Application function names should be:

  • Prepended with the application name (lower case) followed by an underscore: applicationname_FunctionName

  • Meaningful

  • As short as possible

  • Given in "Sentence Case" where the name has more than one word

  • Use alphabetic characters only (other than the single underscore)

For example:

static void   abiview_TextDisplay(AjPGraph graphs, ajint nstart, ajint nstop,
                                  const AjPStr nseq, float tmax, float scale);

static ajint  abiview_getResColour(char B);

Library function and function parameter names follow all but the first of the above conventions, additionally:

  • All AJAX public (external) functions should begin with aj.

  • All NUCLEUS public (external) functions should begin with emb

For example:

AjBool  ajStrAssignSubS(AjPStr* Pstr, const AjPStr str,
                        ajint pos1, ajint pos2);

double  embIepPhFromHconc (double H);

When functions are added to the existing AJAX and NUCLEUS library files, and the changes are to be incorporated into the distribution, the function and parameter names must adhere to rules (Appendix D, Code Documentation Standards) that are defined in the header file and marked up in the code with the tag @namXrule. .

C.9.4. Function Layout

The recommended order for the layout of code in functions is as follows:

  • Variable declarations

  • Calls to constructor functions

  • Body of function

  • Calls to destructor functions and return

Always explicitly state a return at the end of every function, even for void functions.

For example:

/* @func ajStrAssignK *********************************************************
**
** Copy a single character to a string.
**
** @param [w] Pstr [AjPStr*] Target string.
** @param [r] chr [char] Source text.
** @return [AjBool] ajTrue if string was reallocated
** @@
******************************************************************************/

AjBool ajStrAssignK(AjPStr* Pstr, char chr)
{
    AjBool ret = ajFalse;
    AjPStr thys;

    if(!*Pstr)
      *Pstr=ajStrNewRes(2);

    thys = *Pstr;

    if(thys->Use != 1 || thys->Res <= 1)
    {
      ret  = ajStrSetRes(Pstr, 2);
      thys = *Pstr;
    }

    thys->Ptr[0] = chr;
    thys->Ptr[1] = '\0';
    thys->Len = 1;

    return ret;
}

C.9.5. Function Documentation

All public (external) functions must be documented in a standard way (Appendix D, Code Documentation Standards). Separate objects by suitable whitespace (4 newlines).