init: introduce supertux with 0.6.3-4

CODINGSTYLE.md

@@ -0,0 +1,297 @@
+# SuperTux Coding Standards
+
+## Language
+
+C++14 is the main langauge used for this project. GCC, Clang and MSVC are supported.
+
+For better backward compatibilty with older compiler, namely gcc5,
+some C++14 features are restricted:
+
+* generic lambda functions are not allowed, e.g. `[](auto foo){}`
+* tuple constructors have to be explicit, e.g. `std::tuple<int, int>{5, 6}`, not `{5, 6}`
+
+## Repository Structure
+
+Properly separate between generic engine code and game specific code whenever
+feasible.
+
+Third party libraries are not allowed in `src/`, they go to `external/`.
+
+Third party libraries that are imported into `external/` as git
+submodule have to be forked and included into the SuperTux
+organisation on Github, not directly included from upstream.
+
+## File Formating
+
+Do not have spaces at the end of lines.
+
+Files should always end with `/* EOF */` and a newline or a similar
+marker approprimate for the given language. This marker can be left
+out for fileformats that have an end tag, e.g. `</html>`.
+
+Aim for one file per class, small helper classes in the same file are ok.
+
+## Includes
+
+The path in `#include` directives must not contain `..`.
+
+All paths for includes from SuperTux must be relative to the `src/`
+directory and use `#include "..."`.
+
+Use the `#include <>` syntax for libraries in `external/`, use `cmake`
+to set the include path properly.
+
+The order of includes shall be as follows, each of those subgroups
+shall be ordered alphabetically:
+
+* include of header file when in a .cpp file
+* include of the base class in a header file of a derived class
+* system includes
+* external includes
+* local includes
+
+Conditional includes should be indented.
+
+```c++
+#ifdef FOOBAR
+#  include "foobar.hpp"
+#endif
+```
+
+Include guards are of the form:
+
+```c++
+#ifndef HEADER_SUPERTUX_{PATH}_{FILE}_HPP
+#define HEADER_SUPERTUX_{PATH}_{FILE}_HPP
+```
+
+`tools/fix_include_guards.sh` is a little script that will help to fix
+include guards on file renames.
+
+## Variables
+
+Prefix member variable names with `m_`, global variables with `g_`, and static
+variables with `s_`. DynamicScopeRefs are prefixed with `d_`.
+
+## Classes
+
+Mark all classes as `final` unless they are specifically designed
+with polymorphism in mind.
+
+Mark all functions that override a virtual function in a base class with `override`.
+
+Write simple getters/setters inside a header file on a single line.
+
+Properly separate data members and member functions. Do not mix them in the same
+`public`/`protected`/`private` section.
+
+List virtual functions before non-virtual functions.
+
+The order of declarations in a class shall be as follows:
+
+```c++
+class Foo final
+{
+public:
+protected:
+private:
+   // type declarations, needs to come first as later stuff might depend on them
+
+public:
+protected:
+private:
+   // static stuff
+
+public:
+protected:
+private:
+   // constructors
+   // destructor
+
+public:
+protected:
+private:
+   // virtual member functions
+   // non-virtual member functions
+
+public:
+protected:
+private:
+   // member variables with an m_ prefix
+
+private:
+  // non-copyable footer
+  Foo(const Foo&) = delete;
+  Foo& operator=(const Foo&) = delete;
+};
+```
+
+## Pointers
+
+Do not use raw pointers and `new`/`delete`, use
+`std::unique_ptr<>`/`std::make_unique<>` instead.
+
+Only use `std::smart_ptr<>` when sharing of data is required, prefer
+`std::unique_ptr<>` when possible.
+
+Pass and return values as value, `&` or `const&`, only use `*` when
+the value is expected to be `nullptr`.
+
+Do not pass values as `const std::unique_ptr<T>&` or `const
+std::shared_ptr<T>&`, dereference the pointer and pass as `const&`.
+
+To check for nullptr, use an `if` statements with initializer when possible:
+
+```c++
+if (auto* ptr = get_ptr()) {
+  // code here
+}
+```
+
+## auto
+
+Don't use `auto` for basic types (`int`, `float`, `std::string`, ...)
+
+Only use `auto` when the exact type is unnecessary to know (e.g.
+iterators) or obvious from the context, (e.g. `auto foo =
+Foo::create()`)
+
+Capture pointers as `auto*`, not just `auto`.
+
+Ues `const auto&` for loops to avoid copies.
+
+## Namespaces
+
+Namespaces should be written in the form:
+
+```c++
+namespace my_namespace {
+...
+} // namespace my_namespace
+```
+
+With no newline before the `{`. Do not indent the content inside the
+namespace. The namespace itself should be all lowercase.
+
+## Compiler Warnings and Errors
+
+Compile with a maximum warning level and with `-Werror`. This can be accomplished with:
+
+```console
+cmake .. -DCMAKE_BUILD_TYPE=Release  -DWARNINGS=ON -DWERROR=ON
+```
+
+This requires, among other things:
+
+* use of `final` and `override` keywords
+
+* use of `static_cast` and `reinterpret_cast`, not old style C casts
+
+* all member variables have to be initialized in the constructor
+
+* all `int`/`float` conversion has to be explicit
+
+## Comments
+
+Avoid comments unless they explain something important and
+non-obvious. Document *why* the code does something, not *what* it
+does.
+
+Prefer to use good function and variable names to create
+self-documenting code.
+
+Use the `//` syntax for regular comments, even multiline, don't use `/* */`.
+
+For Doxygen (code documentation), use the `/** */` syntax, don't use
+`/**<` and other styles of comments.
+
+For translator information, use the `// l10n:` syntax.
+
+Don't do `*` prefix decorations in comments, keep things simple and
+compact:
+
+```c++
+/*
+ *  Don't do this
+ */
+```
+
+Instead:
+
+```c++
+// Do this
+```
+
+or:
+
+```c++
+/** Also ok when it's a Doxygen comment */
+```
+
+## Spaces
+
+Use a space after `if`/`while`/`switch`/`for`:
+
+`for (int i = 0; i < len; ++i) ...`
+
+`if (a > b) ...`
+
+`while (a > b) ...`
+
+`switch (myenum) ...`
+
+But don't use a space after a function name:
+
+`myfunc ()` // don't do this
+
+`myfunc()` // do this
+
+## Line breaks
+
+Write simple getters/setters inside a header file on a single line:
+
+```c++
+Vector get_pos() const { retun m_pos; }
+```
+
+Don't include more complex functions inside a header file, unless it's
+necessary (template, performance).
+
+Declare functions like:
+
+```c++
+ReturnType
+ClassName::function_name()
+{
+...
+}
+```
+
+We don't have any hard rules on linebreaks before `{` inside
+functions, but generally prefer the no-linebreak version when doing
+simple one-liners and the other one when doing more complex stuff:
+
+```c++
+if (foo) {
+  one_line_function_call()
+}
+```
+
+```c++
+if (foo)
+{
+  long();
+  complex();
+  series();
+  of();
+  calls();
+}
+```
+
+## Other Information
+
+More general info on good practices can be found in [Google's C++
+Style Guide](https://google.github.io/styleguide/cppguide.html) and in
+the [C++ Core Guidelines](http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines),
+note however that we do not strictly follow either of them and divert from
+them in some points, so just take them as general guidelines, not hard rules.

CONTRIBUTING.md

@@ -0,0 +1,64 @@
+# Contributing to SuperTux
+
+## Bug reports
+
+- GitHub Issues in English only. IRC support might be possible in other languages,
+  however English is generally preferred so everyone can understand what's happening.
+- Please check for duplicate issues on GitHub, as they're wasting the developers'
+  time.
+- Also try to check if your issue has been resolved in the development version.
+- Separate issues and feature requests. Don't put all in the same issue.
+- If you made a mistake in your bug report, please use GitHub's edit feature
+  to correct the wrong detail, instead of closing the old issue and opening a
+  new one.
+
+
+### Required information
+
+Please include the following details in your issue report so that we can investigate:
+
+- The SuperTux version you're using, as printed in the bottom left corner of the
+  menu or in `supertux2 -v`.
+- Details about your kernel, operating system and distribution, including name
+  and version details.
+- If possible, provide steps to reproduce your issue.
+- If available, it's a great help for the developers to include a backtrace from
+  gdb or a core dump. If you're on GNU/Linux and your distro is using systemd, it's
+  highly likely that a core dump is available using `coredumpctl(1)`.
+
+### Add-on related issues
+
+No support is provided for third-party add-ons (that doesn't include official
+add-ons or language packs). However, a pull request against the SuperTux/addons
+repository containing a fix is always welcome.
+
+### Translation issues
+
+Please use Transifex to fix or report translation related issues.
+
+## Pull requests
+
+- No duplicate pull requests, please.
+- Please test your code to see if it works correctly. If the pull request
+  is untested or work-in-progress, please mention that.
+- Pull requests importing translation updates from Transifex are, unless requested
+  by a contributor, not very welcome.
+- Commit messages should follow this style:
+  - First line: Short summary, up to 72 characters
+  - An empty line, separating message subject and body
+  - Detailed explanatory text for the change which can include multiple paragraphs,
+    or bullet points. Maximum of 72 characters per line.
+  - If the commit fixes an issue reported on GitHub, please add another empty
+    line, followed by a line containing `Closes #xyz`, where `#xyz` is the issue
+    to close. See <https://help.github.com/articles/closing-issues-via-commit-messages/>
+    for a more detailed description of this feature.
+  - If the commit doesn't include any changes that need CI testing (code or
+    build system changes should always be CI tested, other things not), yet another
+    empty line, followed by a line containing `[ci skip]`. This makes the CI
+    ignore that commit.
+- Please [squash](https://help.github.com/articles/about-git-rebase/) commits that belong together.
+  If you forget initially, it's okay to force push to your own fork to fix it.
+- No merge commits inside pull requests. Use `git-rebase` to keep your branch
+  up-to-date.
+- To make it easier for everyone, don't make a pull request pulling your fork's
+  `master` branch.