C Style -- naming
author | Gareth Rees |
copyright | See Copyright and License. |
date | 2014-10-07 |
index terms | pair: C language; naming guide pair: C language naming; guide |
revision | //info.ravenbrook.com/project/mps/master/design/guide.impl.c.naming.txt#8 |
status | incomplete guide |
tag | guide.impl.c.naming |
Introduction
.scope: This document describes the conventions for naming in C source code that's internal in the MPS. See design.mps.interface-c for the corresponding conventions for the public interface.
.readership: This document is intended for anyone working on or with the C source code.
Capitalization
.capital.macro: Statement-like macros have names consisting of uppercase words separated by underscores, for example ARG_DEFINE_KEY.
.capital.constant: Constants have names consisting of a type (named according to .capital.program or .capital.other), concatenated with an identifier in uppercase with underscores, for example BufferFramePOP_PENDING.
.capital.program: Other names with program scope consist of concatenated title-case words, for example BufferFramePush.
.capital.other: Other names (including function parameters, names with block scope, and names with file scope) consist of concatenated words, the first of which is lowercase and the remainder are uppercase. For example, poolReturn.
Prefixes
.prefix.program: Any name with program scope must start with the name of the module to which it belongs. For example, names belonging to the buffer module must start with buffer or Buffer or BUFFER. Justification: the C language lacks a namespace facility so the only way to avoid name clashes is for each name to be globally unique.
.prefix.file: Any name with file scope should start with the name of the module to which it belongs. Justification: makes it easy to tell which module a function belongs to; makes it easy to set breakpoints in the debugger.
Suffixes
.suffix.struct: The type of a structure must be the same as the structure tag, and must consist of the type of the pointer to the structure concatenated with Struct. For example, ArenaStruct.
.suffix.union: The type of a union must be the same as the union tag, and must consist of the type of the pointer to the union concatenated with Union. For example, PageUnion.
.suffix.class: The type of a class (see design.mps.protocol) must end with Class. For example, ArenaClass.
.suffix.method: The type of a method in a class must end with Method. For example, PoolFixMethod.
.suffix.visitor: The type of a visitor function must end with Visitor. For example, TreeVisitor.
.suffix.function: The type of other functions must end with Function. For example, TreeKeyFunction.
Copyright and License
Copyright © 2002–2020 Ravenbrook Limited.
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
- Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
- Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.