Difference between revisions of "Code style"
(→Name style) |
(→Name style) |
||
Line 28: | Line 28: | ||
* Class members: m_fooBar | * Class members: m_fooBar | ||
* Static members: s_fooBar | * Static members: s_fooBar | ||
− | * Constants: FOO_BAR | + | * Constants (defines and <tt>static const</tt>): FOO_BAR |
Names should generally be chosen for what the thing represents. It shouldn't have type or qualifier information embedded in the name (the so-called [http://en.wikipedia.org/wiki/Hungarian_notation Systems Hungarian] notation). Just name it so its crystal clear what it is. | Names should generally be chosen for what the thing represents. It shouldn't have type or qualifier information embedded in the name (the so-called [http://en.wikipedia.org/wiki/Hungarian_notation Systems Hungarian] notation). Just name it so its crystal clear what it is. | ||
+ | |||
+ | (Exception: member variables have a <tt>m_</tt> or <tt>s_</tt> to disambiguate them from local names and to match C++ conventions). | ||
There's also a few abbreviated names that are commonly used throughout the codebase, eg <tt>Renderer *r</tt>, <tt>lua_State *l</tt>, etc. Try to prefer them where appropriate. | There's also a few abbreviated names that are commonly used throughout the codebase, eg <tt>Renderer *r</tt>, <tt>lua_State *l</tt>, etc. Try to prefer them where appropriate. |
Revision as of 09:17, 10 December 2013
This page describes some of the code style used in Pioneer. Its probably incomplete, but it should be correct. If you see something in the code that doesn't match what's described here, this guide takes precedence (and please submit a patch to fix it!)
Licensing
Engine and Lua code is GPL 3. Assets (include Lua-based data files like ship defs) are CC-BY-SA 3
Include these two lines at the top of each file (suitably commented):
Copyright © 2008-2013 Pioneer Developers. See AUTHORS.txt for details Licensed under the terms of the GPL v3. See licenses/GPL-3.txt
Copyright © 2008-2013 Pioneer Developers. See AUTHORS.txt for details Licensed under the terms of CC-BY-SA 3.0. See licenses/CC-BY-SA-3.0.txt
Tabs & spacing
- Hard tabs, 4-space aligned.
- Inner spaces after tabs to align arguments on multiple lines, etc
Constants
- Prefer static const over #define wherever possible
Name style
- Classes: FooBar
- Methods: FooBar
- Class members: m_fooBar
- Static members: s_fooBar
- Constants (defines and static const): FOO_BAR
Names should generally be chosen for what the thing represents. It shouldn't have type or qualifier information embedded in the name (the so-called Systems Hungarian notation). Just name it so its crystal clear what it is.
(Exception: member variables have a m_ or s_ to disambiguate them from local names and to match C++ conventions).
There's also a few abbreviated names that are commonly used throughout the codebase, eg Renderer *r, lua_State *l, etc. Try to prefer them where appropriate.
Include guards
Header include guards should be named for the filename of the header, capitalised, with slashes converted to underscores:
- Ship.h
#ifndef SHIP_H
- WorldView.h
#ifndef WORLDVIEW_H
- graphics/Renderer.h
#ifndef GRAPHICS_RENDERER_H
Enum types
Enums are effectively global constants, so should be in full caps. They're prefixed with the name of the enum.
Avoid assigning explicit integer values. Also avoid values that aren't actually valid for whatever the enum is (though *_MAX to mark the last valid value is usually acceptable). If these don't work, chances are what you're trying to do would be better served by multiple enums or even a whole class.
enum Thing { THING_FOO, THING_BAR, THING_BAZ, THING_MAX };