Difference between revisions of "Code style"
Jump to navigation
Jump to search
Line 23: | Line 23: | ||
This is less important. Currently through the code base there are: |
This is less important. Currently through the code base there are: |
||
* Sergio's style; e.g. [https://svn.code.sf.net/p/apertium/svn/trunk/lttoolbox/lttoolbox/fst_processor.cc fst_processor.cc] |
|||
* Sergio's style |
|||
* m5w's style; e.g. [https://svn.code.sf.net/p/apertium/svn/trunk/apertium/apertium/basic_stream_tagger_trainer.cc basic_stream_tagger_trainer.cc] |
|||
* m5w's style |
|||
* felipe's style; e.g. [https://svn.code.sf.net/p/apertium/svn/trunk/apertium/apertium/apertium_tagger.cc apertium_tagger.cc] |
|||
* felipe's style |
|||
Most code is Sergio's style. See [[Emacs_C_style_for_Apertium_hacking]] for an older attempt at formalising it. |
|||
Most code is Segio's style. |
|||
Wiki TODO: Document this below. |
Wiki TODO: Document this below. |
Revision as of 07:44, 26 May 2016
Contents
C++
Which features/libraries to prefer/Semantics
New code should prefer modern C++ using C++03. Here, modern C++ is defined in opposition to "C with classes" style. (Note, there is quite a bit of existing code which would probably qualify as "C with classes".) In practice, for our purposes, This means:
Do
- Use const and references where possible
- Prefer C++ casts over C casts
- Prefer the C++ stdlib over the C standard library
- Prefer usage of smart pointers over manual memory management when stack/global allocation don't do the trick.
- Prefer containers over home made data structures.
Don't
- Use void*
- Use sprintf
- If the pointer lifetime is the same as the object it refers to. Don't use a raw pointer.
Formatting/Syntax
This is less important. Currently through the code base there are:
- Sergio's style; e.g. fst_processor.cc
- m5w's style; e.g. basic_stream_tagger_trainer.cc
- felipe's style; e.g. apertium_tagger.cc
Most code is Sergio's style. See Emacs_C_style_for_Apertium_hacking for an older attempt at formalising it.
Wiki TODO: Document this below.
Possible project TODO: Run clang-format
m5w
- loosely following the Clang standards for naming and such
- strictly for indenting -- clang-format
- default to Clang naming style, unless I'm talking about some kind of STL class or STL imitation
- example of imitation is the serialiser class for pairs which are named as such: first_Type, second_Type so we can do can do pair.first and .second
- keep the STL format for the part of the name that's STL
- but if it's followed by something not STL, then I finish out with an underscore and then go to CamelCase
- another divergence is with variables that don't have a whole lot of information e.g. something being passed to a serialiser: they get bland names such as Stream and SerialisedType
- since those are already used as type names -- just add a trailing underscore
Names
...
Whitespace
...
Python
PEP-8?