Fixes that were left out on a previous PR

Add Coding guidelines and other small fixes

.github/pull_request_template.md

@@ -3,6 +3,7 @@ This code review checklist is intended to serve as a starting point for the auth
 # Author
 <!-- NOTE: Do not modify these when initially opening the pull request.  This is a checklist template that you tick off AFTER the pull request is created. -->
 - [ ] Self-review: Did you review your own code in GitHub's web interface? Code often looks different when reviewing the diff in a browser, making it easier to spot potential bugs.
+- [ ] Does the code abide by the [Coding Guidelines](../blob/main/docs/CODING_GUIDELINES.md)?
 - [ ] Automated tests: Did you add appropriate automated tests for any code changes?
 - [ ] Code coverage: Did you check the code coverage report for the automated tests?  While we are not looking for perfect coverage, the tool can point out potential cases that have been missed.
 - [ ] Documentation: Did you update Docs as appropiate? (E.g [README.md](../blob/main/README.md), etc.)

CODE_REVIEW_GUIDELINES.md

@@ -16,7 +16,7 @@
 
 # Testing:
 
-- For non-minor PRs (up to the code reviewers and PR creator if this is needed), we require authors to perform a thorough self-review and self-test of the resulting code base, including use cases that might not be visible affected by the introduced changes. Reviewers are not expected to run the changes locally, but are definitely encouraged to do so at their best judgement. 
+- For non-minor PRs (up to the code reviewers and PR creator if this is needed), we require authors to perform a thorough self-review and self-test of the resulting code base, including use cases that might not be visibly affected by the introduced changes. Reviewers are not expected to run the changes locally, but are definitely encouraged to do so at their best judgement. 
 - When introducing modifications that affect the UI, screenshots might be provided in a BEFORE/AFTER fashion to speed up UI/UX requirement validation. 
 - Are there new tests that check all of the requirements? If it's a bugfix does it include new tests testing the bug triggering condition? (Do they fail before the fix and pass after the fix?)
 - Do tests include edge cases, error conditions, and "negative case" tests to ensure the software is robust? Example: a function for verifying transaction signatures should include a bunch of tests for invalid signature cases.
@@ -32,6 +32,7 @@
 In summary, here's a checklist that summarizes what reviewers should be looking for when doing a Code Review [1]
 
 - The code is well-designed.
+- The code abides by the [Coding Guidelines](../blob/main/docs/CODING_GUIDELINES.md)?
 - The functionality is good for the users of the code.
 - Any UI changes are sensible and look good.
 - Any parallel programming is done safely.

SWIFTLINT.md

@@ -121,14 +121,6 @@ You can work around this by extracting the `Button`'s action into a separate met
 
 In these cases, you're permitted to disable this rule **for the declaration of a SwiftUI view** only. The rule name is `multiple_closures_with_trailing_closure`.
 
-### Open-source files
-
-Occasionally, you'll find it necessary to include an unmodified open-source file in the sample project. It's a virtual certainty that these files won't comply with our style guide. Our practice has always been to leave these files in their original state. In this situation, you should disable SwiftLint for the entire file:
-
-```
-// swiftlint:disable all
-```
-
 ## Other notes
 
 While SwiftLint goes a long way towards making your source code compliant with our style guide, it doesn't cover everything. For example, it won't catch or force you to correct the formatting for multi-condition `guard` statements. If you find yourself butting heads with SwiftLint, or have improvement suggestions, please file an Issue and send a PR request with your suggestions.

docs/CODING_GUIDELINES.md

@@ -0,0 +1,29 @@
+# Coding Guidelines
+
+Your contributions are very welcome, however we'd like you to please follow our coding guidelines. We've created them to be able to have a base structure that enable our maintainer to evaluate and review all contributions equally.
+
+Some rules are being enforced by SwiftLint. Please look at [SwiftLint guidelines](../blob/master/SWIFTLINT.md) for more information.
+
+# Creating new files
+When creating new files, please use the provided templates when applicable. You can find them in the [xctemplates folder](../blob/master/xctemplates).
+
+# Type definition structure
+
+When defining new type or modificating an existing one, please follow the convention below:
+
+````
+Type
+-nested types
+-static properties
+-constants
+-variables
+-computed properties
+-init methods
+-instance methods
+
+# extension for static functions (optional)
+# private extension for private functions (optional)
+# extension for Type conformances to individual protocols (not optional)
+
+(# denotes the usage of a mandatory pragma mark)
+````