The project goal is to develop
a robust, stable LDAP suite. We have adopted various guidelines
to help meet this goal. This document details programming guidelines.
Developers should also read:
General Programming Guidelines
We have adopted a few basic style guidelines designed to facilitate
merges between different versions of OpenLDAP software. Without
these restrictions we would not be able to accept changes made
against the various versions of OpenLDAP Software (and other U-Mich
derived LDAP implementations).
- Correctness first!
It's easier to make a correct program run fast than
to make a quick program run correctly!
- Generalize solutions
- Move towards standards
- Incremental development
- Code is to be indented with tabs (not spaces) with a tab-width of 4.
- Line length should not exceed 80 characters.
- Adapt your style to match that of the block,
file, directory, or package that you are working in.
- Do not reindent, reformat, restyle or otherwise
improve the committed code.
Developers should review their diffs and
and eliminate any unnecessary changes before submitting
(or committing) them.
Language Specific Guidelines
OpenLDAP utilizes a number of different languages:
The majority of OpenLDAP software is
written in the C Programming Language. The code is
designed such that most modern C translators can be
used to build the software. In general, programmers are
allowed to use most Standard C constructs. However, we've
found that the following restrictions need to observed:
C source files (ie: source.c) should include the
portable.h header and do so first and foremost. The only
exception to this restrictions are contrib packages
which have independent build systems.
Failure to include this file first will result in improper
definitions and declarations.
Non-exposed header files can and should assume
portable.h has been included. portable.h
should never be included by any
Exposed Header Restrictions
OpenLDAP supports application development using non-Standard
C translators including:
This requires OpenLDAP Software exposed (ie: installed) header files
to be generic and very portable. Exposed headers should:
- K&R C Translators,
- C++ Translators,
- Objective C Translators, and
- Hybrid C Translators.
- include and use
- not include any system header, and
- not include any non-exposed ldap header, and
- be self-contained.
Note: portable.h is not exposed.
A number of scripts are written as Bourne Shell,
scripts. These include configuration scripts, test scripts,
The Bourne Shell is used for these scripts to gain portability
across a wide range of platforms. However, implementations of
sh(1) can vary widely.
As such, the programmer
should attempt to use only those features that are commonly
- shell functions,
- negated character classes, and
- other features not available in common Bourne (or
compatible) Shell implementations.