Code Syntax

Code must be linted by SwiftLint, and must must pass the swiftlint command with no violations.

This is the list of rules that we ignore. You can add these to the .swiftlint.yml file of your project.

disabled_rules:
  - force_cast
  - force_try
  - line_length
  - todo
  - trailing_whitespace
  - statement_position
  - type_name
  - valid_docs
  - variable_name_min_length

#####Notes

• You can preview linter errors in Xcode by adding this script to your project build phases.

• Github comments regarding bad-formed syntax in your pull requests will be automatically generated by hound.ci tool.

• Your pull request will not be approved until you fix all those comments, if there are.

• Reviewers should not care about syntax; there is the aforementioned automatic process for that.

Motivation

• Convention
  • Defining and sticking with a style guide helps reduce the amount of decisions that developers needs to make when writing code, helping to keep their focus on logic, not semantics and formatting.
• Consistency
  • When every line of code is written in the same style, the whole codebase becomes easier to read, understand and de-bug. It also helps prevent areas of the codebase from being “owned” by one person's unique style vs. the team.
• Professionalism
  • A clean codebase is a reflection of a cohesive team. It gives the impression of a team working well together towards a common goal, rather than individual developers working independently.