Apache Axis2/C - Apache Axis2/C - Coding Conventions

##### Apache Axis2/C

- Apache Axis2/C Home
- Download Axis2/C
  - Releases
- Documentation
  - Installation Guide
  - Axis2/C manual
  - Axis2/C FAQ
- Get Involved
  - Mailing Lists & Issue Tracking
  - Checkout Source Code
- Developer Guidelines
  - Coding Convention
  - Versionning
- Project Information
  - Project Team
  - Source Code

## Axis2/C Coding Conventions

### Contents

- Naming Conventions
  - Variables
  - Functions
  - Structures and User defined Data Types
  - Macros
  - Enumerations
- Indentation and Formatting
- Comments
- Function Parameters and Return Value Conventions
- Include Directives

### 1. Naming Conventions

- Namespace validation is done using the `axis2_` prefix.
- Underscore should be used to separate individual words in identifiers.
- All identifiers should be meaningful and abbreviations must be avoided whenever possible.

### 1.1 Variables

- Use meaningful nouns.
- Make sure to use all lowercase letters for private and public variables.
- If it is a local variable or a member of a struct, there's no need to prefix it with `axis2_`
e.g.

    int count = 0;
    char *prefix = NULL;

### 1.2 Functions

- Function names should always start with the prefix `axis2_` except for members of a struct.
e.g.

    axis2_engine_t * axis2_engine_create(axutil_env_t *environment);

### 1.3 Structures and User Defined Data Types

- Note the _t suffix in the type name.
e.g.

    typedef struct axis2_endpoint_ref {
        axis2_char_t *address;
    } axis2_endpoint_ref_t;

### 1.4 Macros

- Macro names should be in all uppercase letters.
e.g.

    #define AXIS2_H
    #define AXIS2_ERROR_GET_MESSAGE(error) ((error)->ops->get_message(error))

### 1.5 Enumerations

e.g.

    typedef enum axis2_status_codes {
        AXIS2_FAILURE = 0,
        AXIS2_SUCCESS
    } axis2_status_codes_t;

### 2. Indentation and Formatting

Indentation rules are defined in terms of Artistic Style indent options:

astyle --style=ansi -b -p -s4 -M0 -c -U -S

In detail, these options mean,

- Use the ANSI style code layout

                  int foo()
                  {
                      if (is_bar)
                      {
                          bar();
                          return 1;
                      }
                      else
                          return 0;
                  }

- Use spaces around operators
- Use four spaces for indenting
- No spaces between the function name and parenthesis

                  if (is_foo(a, b))
                      bar(a, b);

There are some more formatting guidelines that could not be enforced by a formatting tool, but nevertheless should be followed.

- Checking pointer validity:

          if (foo)

  and NOT

          if (foo != NULL)

- Checking equality:

          if (foo == 7)

  and NOT

          if (7 == foo)

### 3. Comments

Doxygen style comments should be used to help auto generate API documentation. All structs and functions including parameters and return types should be documented.

### 4. Function Parameters and Return Value Conventions

Each function should be passed a pointer to an instance of the `axutil_env_t` struct as the first parameter. If the function is tightly bound to a struct, the second parameter is a pointer to an instance of that struct.

Functions returning pointers should return NULL in case of an error. The developer should make sure to set the relevant error code in the environment's error struct.

Functions that do not return pointer values should always return the `AXIS2_FAILURE` status code on error whenever possible, or return some other defined error value (in case of returning a struct perhaps). A relevant error code must also be set in the environment's error struct.

### 5. Include Directives

It is preferable to include header files in the following fashion:

    <standard header files>
    <other system headers>
    "local header files"