Difference between revisions of "Code style"

From Apertium
Jump to navigation Jump to search
Line 19: Line 19:
 
* If the pointer lifetime is the same as the object it refers to. Don't use a raw pointer.
 
* If the pointer lifetime is the same as the object it refers to. Don't use a raw pointer.
   
=== I'd like to use $LIB eg Boost:Wurble ===
+
=== I'd like to use $LIB eg Boost:Wurble or remove ifdefs by using eg gnulib ===
   
 
No.
 
No.

Revision as of 07:28, 28 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.

I'd like to use $LIB eg Boost:Wurble or remove ifdefs by using eg gnulib

No.

Please?

No.

Why not?

It's going to make it impossible to build for language pair authors.

But if it's a dependency that's built in tree it's just a matter of getting the source there. It could be bootstrapped with a simple script or even (ick) vendorised into Subversion.

This doesn't make any difference. Please just implement whatever you need from scratch.

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

Python

PEP-8?