Difference between revisions of "Code style"

From Apertium
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

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:

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?