Merge pull request #29 from zcash/doc-fixes

Enhancements on the documentation

.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.)
@@ -16,7 +17,7 @@ This code review checklist is intended to serve as a starting point for the auth
 - [ ] Checklist review: Did you go through the code with the [Code Review Guidelines](../blob/main/CODE_REVIEW_GUIDELINES.md) checklist?
 - [ ] Ad hoc review: Did you perform an ad hoc review?  _In addition to a first pass using the code review guidelines, do a second pass using your best judgement and experience which may identify additional questions or comments. Research shows that code review is most effective when done in multiple passes, where reviewers look for different things through each pass._
 - [ ] Automated tests: Did you review the automated tests?
-- [ ] Manual tests: Did you review the manual tests?_You will find manual testing guidelines under our [manual testing section](../blob/mater/docs/testing/manual_testing)_
-- [ ] How is Code Coverage affected by this PR? _We encourage you to compare coverage befor and after your changes and when possible, leave it in a better place. [Learn More...](../blob/master/docs/testing/local_coverage.md)_
-- [ ] Documentation: Did you review Docs, [README.md](../blob/master/README.md), [LICENSE.md](../blob/master/LICENSE.md), and [Architecture.md](../blob/master/docs/Architecture.md) as appropriate?
+- [ ] Manual tests: Did you review the manual tests?_You will find manual testing guidelines under our [manual testing section](../blob/main/docs/testing/manual_testing)_
+- [ ] How is Code Coverage affected by this PR? _We encourage you to compare coverage before and after your changes and when possible, leave it in a better place. [Learn More...](../blob/main/docs/testing/local_coverage.md)_
+- [ ] Documentation: Did you review Docs, [README.md](../blob/main/README.md), [LICENSE.md](../blob/main/LICENSE.md), and [Architecture.md](../blob/main/docs/Architecture.md) as appropriate?
 - [ ] Run the app: Did you run the app and try the changes? While the CI server runs the app to look for build failures or crashes, humans running the app are more likely to notice unexpected log messages, UI inconsistencies, or bad output data.

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)
+````