From 6e90c9a83367af11bcf075f13fea9b444219b528 Mon Sep 17 00:00:00 2001
From: Dorota Czaplejewicz <dorota.czaplejewicz@puri.sm>
Date: Thu, 31 Oct 2019 11:44:17 +0000
Subject: [PATCH 1/2] hacking: Clarify dev env and testing

---
 HACKING.md | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/HACKING.md b/HACKING.md
index 0d736fde..c663c135 100644
--- a/HACKING.md
+++ b/HACKING.md
@@ -3,6 +3,25 @@ Hacking
 
 This document describes the standards for modifying and maintaining the *squeekboard* project.
 
+Development environment
+-----------------------
+
+*Squeekboard* is regularly built and tested on [the develpment environment](https://developer.puri.sm/Librem5/Development_Environment.html).
+
+Recent Fedora releases are likely to be tested as well.
+
+### Dependencies
+
+On a Debian based system run
+
+```sh
+sudo apt-get -y install build-essential
+sudo apt-get -y build-dep .
+```
+
+For an explicit list of dependencies check the `Build-Depends` entry in the
+[debian/control][] file.
+
 Testing
 -------
 
@@ -28,8 +47,12 @@ $ busctl call --user sm.puri.OSK0 /sm/puri/OSK0 sm.puri.OSK0 SetVisible b false
 
 Testing layouts:
 
+Layouts can be selected using the GNOME Settings application.
+
 ```
+# define all available layouts
 $ gsettings set org.gnome.desktop.input-sources sources "[('xkb', 'us'), ('xkb', 'ua')]"
+# choose the active layout
 $ gsettings set org.gnome.desktop.input-sources current 1
 ```
 

From e71e843efff22f127f7c89759ecf145029abaee1 Mon Sep 17 00:00:00 2001
From: Dorota Czaplejewicz <dorota.czaplejewicz@puri.sm>
Date: Thu, 31 Oct 2019 11:52:52 +0000
Subject: [PATCH 2/2] hacking: Define big no-nos in code style

---
 HACKING.md | 49 +++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 49 insertions(+)

diff --git a/HACKING.md b/HACKING.md
index c663c135..0adc1464 100644
--- a/HACKING.md
+++ b/HACKING.md
@@ -56,6 +56,55 @@ $ gsettings set org.gnome.desktop.input-sources sources "[('xkb', 'us'), ('xkb',
 $ gsettings set org.gnome.desktop.input-sources current 1
 ```
 
+Coding
+------
+
+Code submitted should roughly match the style of surrounding code. Things that will *not* be accepted are ones that often lead to errors:
+
+- skipping brackets `{}` after every `if()`, `else`, and similar
+
+Bad example:
+
+```
+if (foo)
+  bar();
+```
+
+Good example:
+
+```
+if (foo) {
+  bar();
+}
+```
+
+- mixing tabs and spaces in the same block of code (or config)
+
+Strongly encouraged:
+
+- don't make lines too long. If it's longer than ~80 characters, it's probably unreadable already, and the code needs to be clarified;
+- put operators in the beginning of a continuation line
+
+Bad example:
+
+```
+foobar = verylongexpression +
+    anotherverylongexpression + 
+    yetanotherexpression;
+```
+
+Good example:
+
+```
+foobar = verylongexpression
+    + anotherverylongexpression
+    + yetanotherexpression;
+```
+
+- use `///` for documentation comments in front of definitions and `/*! ... */` for documentation comments in the beginning of modules (see [Rust doc-comments](https://doc.rust-lang.org/reference/comments.html#doc-comments))
+
+If in doubt, check [PEP8](https://github.com/rust-dev-tools/fmt-rfcs/blob/master/guide/guide.md), the [kernel coding style](https://www.kernel.org/doc/html/v4.10/process/coding-style.html), or the [Rust style guide](https://github.com/rust-dev-tools/fmt-rfcs/blob/master/guide/guide.md).
+
 Maintenance
 -----------