[fractal.wiki] Code style tips

[Alexandre Franke <afranke src gnome org>]

commit 1c22915d3e091ae50c969f90ae1682a0f6948100
Author: Alexandre Franke <alexandre franke gmail com>
Date:   Sun Jan 6 17:59:48 2019 +0000

    Code style tips

 Best-practices-for-Fractal-development.md | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)
---
diff --git a/Best-practices-for-Fractal-development.md b/Best-practices-for-Fractal-development.md
index c1cdf83..59fc270 100644
--- a/Best-practices-for-Fractal-development.md
+++ b/Best-practices-for-Fractal-development.md
@@ -8,4 +8,14 @@ Code **should not** be pushed directly to master. Changes **should** be submitte
 
 Trivial merge requests can be merged immediately. Anything non trivial needs to wait until either:
 * one reviewer has carefully checked the changes and approves them, and 48hrs have passed
-* two reviewers have carefully checked the changes and approve them
\ No newline at end of file
+* two reviewers have carefully checked the changes and approve them
+
+
+
+# Code style
+
+* Use a type constructor that returns an empty value instead of creating a new value from another empty 
value. For example, that means to write `String::new()` instead of `String::from("")`.
+* Use `.unwrap_or_default()` for `Option` and `Result` over `unwrap_or(neutral_value)`. It won't work if the 
contained type doesn't implement the Default trait.
+* Prefer to process the contained value in an Option or Result with combinators and unwrap at the end, 
unless it makes the code difficult to read because of doing it that way.
+* Don't be afraid to go beyond the simpler types or even create new ones. They give semantic meaning to 
values and thus let the compiler check for the correctness of the code at that level if used appropriately.
+