CONTRIBUTING: Syntax highlight, protobuf

.github/CONTRIBUTING.md

@@ -19,25 +19,25 @@ Simple functions, such as getters, may be written inline in the header file,
 but other functions should be written in the source file.
 
 Keep library includes and project includes grouped together. So this is okay:
+```c++
+// Good:
+#include <QList>
+#include <QString>
+#include "card.h"
+#include "deck.h"
 
-    // Good:
-    #include <QList>
-    #include <QString>
-    #include "card.h"
-    #include "deck.h"
-
-    // Good:
-    #include "card.h"
-    #include "deck.h"
-    #include <QList>
-    #include <QString>
-
-    // Bad:
-    #include <QList>
-    #include "card.h"
-    #include <QString>
-    #include "deck.h"
+// Good:
+#include "card.h"
+#include "deck.h"
+#include <QList>
+#include <QString>
 
+// Bad:
+#include <QList>
+#include "card.h"
+#include <QString>
+#include "deck.h"
+```
 ### Naming ###
 
 Use `UpperCamelCase` for classes, structs, enums, etc. and `lowerCamelCase` for
@@ -48,22 +48,22 @@ underscores, etc.
 
 For arguments to constructors which have the same names as member variables,
 prefix those arguments with underscores:
-
-    MyClass::MyClass(int _myData)
-        : myData(_myData)
-    {}
-
+```c++
+MyClass::MyClass(int _myData)
+    : myData(_myData)
+{}
+```
 Pointers and references should be denoted with the `*` or `&` going with the
 variable name:
+```c++
+// Good:
+Foo *foo1 = new Foo;
+Foo &foo2 = *foo1;
 
-    // Good:
-    Foo *foo1 = new Foo;
-    Foo &foo2 = *foo1;
-
-    // Bad:
-    Bar* bar1 = new Bar;
-    Bar& bar2 = *bar1;
-
+// Bad:
+Bar* bar1 = new Bar;
+Bar& bar2 = *bar1;
+```
 Use `nullptr` instead of `NULL` (or `0`) for null pointers.
 If you find any usage of the old keywords, we encourage you to fix it.
 
@@ -71,18 +71,18 @@ If you find any usage of the old keywords, we encourage you to fix it.
 
 Use K&R-style braces. Braces for function implementations go on their own
 lines, but they go on the same line everywhere else:
-
-    int main()
-    {
-        if (someCondition) {
-            doSomething();
-        } else {
-            while (someOtherCondition) {
-                doSomethingElse();
-            }
+```c++
+int main()
+{
+    if (someCondition) {
+        doSomething();
+    } else {
+        while (someOtherCondition) {
+            doSomethingElse();
         }
     }
-
+}
+```
 Braces can be omitted for single-statement if's and the like, as long as it is
 still legible.
 
@@ -100,25 +100,25 @@ Lines should be 80 characters or less, as a soft limit.
 
 New code should be written using references over pointers and stack allocation
 over heap allocation wherever possible.
+```c++
+// Good: uses stack allocation and references
+void showCard(const Card &card);
+int main()
+{
+    Card card;
+    showCard(card);
+}
 
-    // Good: uses stack allocation and references
-    void showCard(const Card &card);
-    int main()
-    {
-        Card card;
-        showCard(card);
-    }
-
-    // Bad: relies on manual memory management and doesn't give us much
-    // null-safety.
-    void showCard(const Card *card);
-    int main()
-    {
-        Card *card = new Card;
-        showCard(card);
-        delete card;
-    }
-
+// Bad: relies on manual memory management and doesn't give us much
+// null-safety.
+void showCard(const Card *card);
+int main()
+{
+    Card *card = new Card;
+    showCard(card);
+    delete card;
+}
+```
 (Remember to pass by `const` reference wherever possible, to avoid accidentally
 mutating objects.)
 
@@ -136,6 +136,11 @@ Everytime the schema gets modified, some other steps are due:
  
 The migration file should include the sql statements needed to migrate the database schema and data from the previous to the new version, and an additional statement that updates `cockatrice_schema_version` to the correct value.
 
+### Protocol buffer ###
+
+Cockatrice and Servatrice exchange data using binary messages. The syntax of these messages is defined in the `proto` files in the `common/pb` folder. These files defines the way data contained in each message is serialized using Google's [protocol buffer](https://developers.google.com/protocol-buffers/).
+Any change to the `proto` file should be taken with caution and tested intensively before being merged, becaus a change to the protocol could make new clients incompatible to the old server and viceversa.
+
 ### Translations: introduction ###
 
 Basic workflow for translations:
@@ -168,27 +173,27 @@ the new strings and add them to the english translation files.
 
 To update the english translation files, re-run cmake enabling the appropriate
 parameter and then run make:
-
-    cd cockatrice/build
-    cmake .. -DUPDATE_TRANSLATIONS=ON
-    make
-
+```sh
+cd cockatrice/build
+cmake .. -DUPDATE_TRANSLATIONS=ON
+make
+```
 If the parameter has been enabled correctly, when running "make" you should see
 a line similar to this one (the numbers may vary):
-
-    [ 76%] Generating ../../cockatrice/translations/cockatrice_en.ts
-    Updating '../../cockatrice/translations/cockatrice_en.ts'...
-    Found 857 source text(s) (8 new and 849 already existing)
-
+```sh
+[ 76%] Generating ../../cockatrice/translations/cockatrice_en.ts
+Updating '../../cockatrice/translations/cockatrice_en.ts'...
+Found 857 source text(s) (8 new and 849 already existing)
+```
 You should then notice that the following files have uncommitted changes:
 
     cockatrice/translations/cockatrice_en.ts
     oracle/translations/oracle_en.ts
 
 It's now suggested to disable the parameter using:
-
-    cmake .. -DUPDATE_TRANSLATIONS=OFF
-
+```sh
+cmake .. -DUPDATE_TRANSLATIONS=OFF
+```
 Now you are ready to propose your change. Once your change gets merged, 
 Transifex will pick up the modified files automatically (checks every 24 hours)
 and update the interface where translators will be able to translate the new