Open felix-schwarz opened 5 years ago
I like the CONTRIBUTING.md from the unofficial WWDC app for macOS https://wwdc.io
@pablocarmu @felix-schwarz what are the next steps here? Add it to the docs and close the issue? Any automated checks that we could add to CI?
This is a loose collection of code style rules that contributions to this project should follow:
SwiftLint
The rules laid down in
.swiftlint.yml
apply and code submitted to the project should not raise any SwiftLint warnings.Only exception: limited usage of TODOs are acceptable in cases
File Names
Files containing a definition of type, for example
MyType
shall be namedMyType.swift
. Files containing type extension shall be named as follows:<TypeName>+<ExtensionDescription>.swift
(for exampleUIView+Animations.swift
).Naming Conventions
Type names / protocol names shall use
PascalCase
, e.g.SomeClass
. Variables, constants and function names shall usecamelCase
, e.g.myVariable
.Variable names should be expressive so the code is easier to read. For example
tableViewController
should be used instead oftableVC
,tvc
orvc
.Constants
Constant declarations shall start with the keyword
let
. To declare a type related constant, usestatic let
.Private APIs
The use of private API is not allowed.
Granularity
The code should follow these granularity rules:
The goal of these rules is to keep the code from becoming too fragmented to easily comprehend. If f.ex. a method is the only caller of another method, which is the only user of a constant, anyone who wants to work on or understand the code would need to look in up to three different places and put the picture together. This should be avoided.
Modularity
Whenever possible, the implementation of a class should be as self-contained as possible. It's internal logic shouldn't be distributed across several classes unless there's a good reason for it.
Indentation
This project uses tabs so that different tab widths don't lead to inconsistent alignment of code throughout source files.
References to OCCore
Code in
ios-app
should avoidstrong
references to instances ofOCCore
for long-lived objects like views or view controllers. Instead, wherever possible, useweak
references.The lifecycle of
OCCore
should be solely managed byOCCoreManager
, which holds a strong reference until all requests for cores have been followed by a return. At that point, it releases its reference toOCCore
, expecting that it also frees all of its resources.Copyright / License
Every file should carry the standard copyright / license notice:
Git branching model and workflow
This project follows the standard OneFlow model.
References
Swift ORG API Design Guidelines Google's Swift Styleguide