docs: add Code Style

Docs/CodeStyle.md

@@ -0,0 +1,53 @@
+# Yafc Code Style
+
+The Code Style describes the conventions that we use in the Yafc project.  
+For the ease of collective development, we ask you to follow the Code Style when contributing to Yafc.
+
+### General guidelines
+
+The main idea is to keep the code maintainable and readable.
+
+* Aim for not-complicated code without dirty hacks.
+* Please document the code. 
+* If you also can document the existing code, that is even better. The ease of understanding makes reading the code more enjoyable.
+
+### Commits
+* Please separate the change of behavior from the refactoring, into different commits. That helps to understand your commits easier.
+* Please make meaningful commit messages. We encourage you to use the prefixes from the [conventional commits](https://www.conventionalcommits.org/en/v1.0.0-beta.2/#summary). They help to browse the commits later.
+
+### Code
+* In the programmers' haven, there is always a free spot for those who write tests.
+* Please try to keep the lines shorter than 120 characters. It simplifies the review of the changes on popular monitors.
+* If you add a TODO, then please describe the details in the commit message, or ideally in a github issue. That increases the chances of the TODOs being addressed.
+
+#### Difference with C# conventions
+Our conventions differ from the [Microsoft C# conventions](https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals/coding-style/identifier-names)
+due to legacy serialization and personal preferences.  
+The most notable difference that is not controlled by [.editorconfig](/.editorconfig) is that class properties are named in camelCase.
+
+#### Blank lines
+Blank lines help to separate code into thematic chunks. 
+We suggest to leave blank lines around code blocks like methods and keywords.  
+For instance,
+```
+public int funcName() {
+    if() { // No blank line because there's nothing to separate from
+        for (;;) { // No empty line because there's not much to separate from
+            <more calls and assignments>
+        }
+
+        <more calls and assignments> // An empty line to clearly separate the code block from the rest of the code
+    }
+
+    <more calls and assignments> // An empty line to clearly separate the code block from the rest of the code
+}
+
+private void Foo() => Baz(); // An empty line between functions
+
+private void One(<a long description
+    that goes on for
+    several lines) {
+
+    <more calls and assignments> // An empty line to clearly separate the definition and the start of the function
+}
+```

Docs/ContributorsGuide.md

@@ -3,17 +3,10 @@
 Here are a couple of things to make your experience in the community more enjoyable. 
 
 ## Coding
-* Please use the same code style as the rest of the codebase. Visual Studio should pick up most of it from `.editorconfig`. You can autoformat the file with the sequence Ctrl+K, Ctrl+D.
-* Please prioritize maintainability. Aim for understandable code without dirty hacks.
-* Please separate the refactoring and the change of behavior into different commits, so it is easier to review the PR.
-* Please document the code. If you can also document the existing code, that would be awesome. More documentation helps others to understand the code faster and make the work on YAFC more enjoyable.
-* Feel free to put [prefixes](https://www.conventionalcommits.org/en/v1.0.0-beta.2/#summary) in the subjects of your commits. They might help to browse the commits later.
-* If you add a TODO, then please describe the details in the commit message or, ideally, in a github issue. That increases the chances of the TODOs being addressed.
-* Please keep the lines of code shorter than 120 characters -- it simplifies PR-reviews on popular monitors.
-* In the programmers' haven, there is always a free spot for those who write tests.
+* For the conventions that we use, please refer to the [Code Style](/Docs/CodeStyle.md).
+* In Visual Studio, you can check some of the rules by running Code Cleanup, or Format Document with "Ctrl+K, Ctrl+D".
 
 ## Pull Request
-* Please provide a short description of your change in the [changelog](https://github.com/have-fun-was-taken/yafc-ce/blob/master/changelog.txt).
-* Please provide context in the PR. For instance, if it solves an issue, then you can put a short description of the issue in it.
-* Make meaningful commit messages. The easier it is to understand your PR, the faster it will be merged.
-* It would be appreciated if you reorganize your commits before the merge -- separate and squash them into logical steps, so they are easier to review and understand. For instance, the fixes to the commits can be squashed into them. The reordering of the commits can be done with the interactive rebase: `git rebase -i head~n`, but please read beforehand on how to do it, so you don't accidentally delete your efforts. If you want to go godlike, feel free to read on `git commit --fixup=` and `git rebase -i --autosquash` ([example](https://stackoverflow.com/questions/3103589/how-can-i-easily-fixup-a-past-commit)). However, it can be the case that the reordering requires very tricky merges, so it's okay to leave them as-is in this case.
+* In the [changelog](https://github.com/have-fun-was-taken/yafc-ce/blob/master/changelog.txt), please provide a short description of your change.
+* In the PR, please provide a short description of the issue, and how your PR solves that issue.
+* It would be appreciated if you reorganize your commits before the merge -- separate and squash them into logical steps, so they are easier to review and understand. For instance, the fixes to the commits can be squashed into them. The reordering of the commits can be done with the interactive rebase: `git rebase -i head~n`, but please read beforehand on how to do it, so you don't accidentally delete your efforts. If you want to go godlike, feel free to read on `git commit --fixup=` and `git rebase -i --autosquash` ([example](https://stackoverflow.com/questions/3103589/how-can-i-easily-fixup-a-past-commit)). However, it can be the case that the reordering requires very tricky merges, so it's okay to leave the commits as-is in this case.