revamp docs

README.md

@@ -6,26 +6,5 @@
 <img src="docs/images/pmp-logo-text.png" alt="logo" width="750px"/>
 
 The pmp-library is a modern C++ open-source library for digital geometry
-processing. It provides a set of geometric data structures frequently used
-in geometry processing tasks as well as implementations of canonical
-algorithms. It has been designed and implemented with a focus on ease of
-use and performance while maintaining high flexibility.
-
-## Quickstart
-
-Fetch the repository:
-
-    $ git clone --recursive https://github.com/pmp-library/pmp-library.git
-
-Configure and build:
-
-    $ cd pmp-library && mkdir build && cd build && cmake .. && make
-
-See the [installation guide](docs/installation.md) file for more
-detailed installation instructions.
-
-## License
-
-The pmp-library is provided under a flexible 3-clause
-BSD [license](./LICENSE.txt), thereby allowing for both open-source and
-commercial usage.
+processing. See the [home page](http://pmp-library.github.io/pmp-library/) for
+details.

docs/Doxyfile.in

@@ -425,7 +425,7 @@ CASE_SENSE_NAMES       = NO
 # will show members with their full class and namespace scopes in the
 # documentation. If set to YES the scope will be hidden.
 
-HIDE_SCOPE_NAMES       = NO
+HIDE_SCOPE_NAMES       = YES
 
 # If the SHOW_INCLUDE_FILES tag is set to YES (the default) then Doxygen
 # will put a list of the files that are included by a file in the documentation
@@ -878,7 +878,7 @@ HTML_FILE_EXTENSION    = .html
 # have to redo this when upgrading to a newer version of doxygen or when
 # changing the value of configuration settings such as GENERATE_TREEVIEW!
 
-HTML_HEADER            =
+HTML_HEADER            = ${CMAKE_CURRENT_SOURCE_DIR}/header.html
 
 # The HTML_FOOTER tag can be used to specify a personal HTML footer for
 # each generated HTML page. If it is left blank doxygen will generate a
@@ -912,7 +912,7 @@ HTML_EXTRA_STYLESHEET  = ${CMAKE_CURRENT_SOURCE_DIR}/style.css
 # files. In the HTML_STYLESHEET file, use the file name only. Also note that
 # the files will be copied as-is; there are no commands or markers available.
 
-HTML_EXTRA_FILES       =
+HTML_EXTRA_FILES       = ${CMAKE_CURRENT_SOURCE_DIR}/images/favicon.ico
 
 # The HTML_COLORSTYLE_HUE tag controls the color of the HTML output.
 # Doxygen will adjust the colors in the style sheet and background images

docs/codingstyle.md

@@ -0,0 +1,124 @@
+# Coding Style {#codingstyle}
+
+If you would like to contribute to the pmp-library please make sure your source
+code adheres to the following coding conventions. Please use
+the [clang-format](https://clang.llvm.org/docs/ClangFormat.html) tool and the
+corresponding `.clang-format` configuration file from the repository to properly
+format your code.
+
+## Naming
+
+### Types
+
+The names of user-defined types such as classes, structs and enums use
+`CamelCase` notation. The names of persons such as Cholesky or Delaunay are
+properly capitalized as well.
+
+~~~~{.cpp}
+    class PolyLine { ... };
+    enum RGBColors { red, green, blue };
+    class SparseCholeskySolver { ... };
+~~~~
+
+### Functions
+
+Function names are written using `camelCase` notation starting with a lowercase
+letter.
+
+~~~~{.cpp}
+    class ExampleClassName
+    {
+        double exampleFunctionName(void);
+    };
+~~~~
+
+### Variables
+
+Variables are named in `camelCase` notation. Class member variables are prefixed
+with `m_`.
+
+~~~~{.cpp}
+    int globalsConsideredHarmful;
+
+    class ExampleClass
+    {
+    protected:
+        double m_memberVariable;
+        static double m_staticVariable;
+    };
+~~~~
+
+### File Names
+
+File names follow the naming rules for user-defined types. Implementation files
+end with `.cpp` and header files end with `.h`.
+
+## Formatting
+
+### Blocks
+
+The expressions following an `if, else, while, do ... while` or `for` statement
+should always be enclosed in braces. The braces enclosing a block should be
+placed in the same column, on separate lines.
+
+~~~~{.cpp}
+    if (fooBar == baz)
+    {
+        std::cout << "hurz" << std::endl;
+    }
+    else
+    {
+        std::cout << "asdf" << std::endl;
+    }
+~~~~
+
+### Comments
+
+Use C++-style comments, i.e., `// My important comment.` Use `//!` for doxygen
+special comments.
+
+### Line Length
+
+Lines should not exceed more than 80 characters. There should only be one
+statement per line.
+
+### Indentation
+
+Use spaces instead of tabs. Indent the code by four spaces for each
+level of indentation. Avoid trailing whitespaces at the end of a
+line as well as on empty lines.
+
+## Miscellaneous
+
+This section describes some basic programming conventions developers should
+adhere to.
+
+- Use the <tt>\#pragma once</tt> compiler directive at the beginning of each
+  header file in order to protect against multiple inclusion.
+
+- Use the `pmp` namespace in order to avoid conflicts. In source files, do not
+  add an additional level of indentation due to the namespace:
+
+~~~~{.cpp}
+        namespace pmp {
+
+        class ExampleClass
+        {
+        ...
+        };
+
+        }
+~~~~
+
+- Use meaningful prefixes for `bool` variables or functions returning booleans,
+  e.g., `hasColors()` or `isDone`.
+- Consistently name dynamic properties, e.g., "v:scalar" for vertex scalars or
+  "f:normal" for face normals.
+- Consistently name iterators and circulators by their type
+- Use `std::size_t` where appropriate, e.g., storing values from STL functions
+  such as the `size()` member function of a `std::vector`
+- Localize variable scope and avoid declaring all variables at the beginning of
+  a function or code block.
+- In case you want to preserve the special formatting of a particular code block
+  such as a matrix intialization add the `// clang-format off` and
+  `// clang-format on` directives around this block.

docs/contributing.md

@@ -0,0 +1,52 @@
+# Contributing {#contributing}
+
+Contributions to the pmp-library are generally welcome. However, please keep in
+mind that we develop the library besides our daily jobs and therefore might not
+always find the time to quickly react to your requests and suggestions.
+
+## Reporting Issues
+
+In case you run into trouble using the pmp-libray, please check for
+existing [issues](https://github.com/pmp-library/pmp-library/issues). If your
+problem is not already reported file a new issue and also provide some piece of
+code and data to reproduce the behavior in question.
+
+## Contributing Code
+
+If you would like to contribute to the development of the pmp-library you should
+start by [forking](https://help.github.com/articles/fork-a-repo) and creating
+a [pull request](https://help.github.com/articles/creating-a-pull-request). Make
+sure that your code follows the [Coding Style](coding_style.html) guidelines. In
+case you want to contribute a new algorithm make sure the code is properly
+documented using doxygen and is accompanied by a unit test, see below.
+
+## Unit Testing
+
+The pmp-library has a suite of unit tests that aims at making sure everything
+works as expected. The unit tests are written
+using [Google Test](https://github.com/google/googletest) and run during
+continuous integration builds. See the also the `tests` sub-directory of the
+repository. You can locally run the test suite from your build directory by
+invoking the
+
+    $ make test
+
+target. To obtain more detailed test output we recommend to invoke the Google
+Test runner directly:
+
+    $ cd tests
+    $ ./gtest_runner
+
+
+## Code Coverage
+
+We track the overall code coverage rate of our unit tests
+using [gcov](https://gcc.gnu.org/onlinedocs/gcc/Gcov.html), which is part
+of [GCC](https://gcc.gnu.org/). To check the code coverage locally run
+
+    $ make coverage
+
+This will run the test suite and collect the coverage data. A HTML report of the
+results will be generated to `coverage/index.html`. We generally try to maintain
+a high coverage rate of above 90%. Any code that you would like to contribute
+should not decrease the coverage rate.

docs/footer.html

@@ -1,5 +1,4 @@
 <div id="footer">
-  <hr>
   <address>
       Copyright &copy; 2017 The pmp-library developers
   </address>