forked from kodecocodes/swift-style-guide
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
First update to the swift guideline 🚀 (#1)
- Loading branch information
Showing
6 changed files
with
317 additions
and
273 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,105 @@ | ||
disabled_rules: | ||
- closure_parameter_position | ||
- todo | ||
- unused_optional_binding | ||
- type_name | ||
- identifier_name | ||
opt_in_rules: | ||
- closure_spacing | ||
- closure_end_indentation | ||
- collection_alignment | ||
- convenience_type | ||
- discouraged_optional_boolean | ||
- empty_count | ||
- empty_string | ||
- fallthrough | ||
- fatal_error_message | ||
- file_types_order | ||
- first_where | ||
- force_unwrapping | ||
- identical_operands | ||
- implicit_return | ||
- implicitly_unwrapped_optional | ||
- joined_default_parameter | ||
- last_where | ||
- literal_expression_end_indentation | ||
- lower_acl_than_parent | ||
- multiline_arguments | ||
- multiline_literal_brackets | ||
- multiline_parameters | ||
- nslocalizedstring_key | ||
- weak_delegate | ||
- nimble_operator | ||
- object_literal | ||
- operator_usage_whitespace | ||
- overridden_super_call | ||
- override_in_extension | ||
- private_action | ||
- private_outlet | ||
- redundant_nil_coalescing | ||
- redundant_type_annotation | ||
- sorted_first_last | ||
- sorted_imports | ||
- toggle_bool | ||
- trailing_closure | ||
- type_contents_order | ||
- unavailable_function | ||
- unneeded_parentheses_in_closure_argument | ||
- unused_import | ||
- unused_private_declaration | ||
- vertical_parameter_alignment_on_call | ||
- yoda_condition | ||
|
||
force_unwrapping: error | ||
force_try: warning | ||
|
||
colon: | ||
flexible_right_spacing: false | ||
apply_to_dictionaries: true | ||
|
||
closure_body_length: | ||
warning: 300 | ||
error: 400 | ||
|
||
function_body_length: | ||
error: 200 | ||
|
||
type_body_length: | ||
warning: 300 | ||
error: 400 | ||
|
||
cyclomatic_complexity: | ||
warning: 100 | ||
error: 200 | ||
ignores_case_statements: false | ||
|
||
file_length: | ||
warning: 400 | ||
error: 1000 | ||
|
||
number_separator: | ||
minimum_length: 0 | ||
|
||
implicitly_unwrapped_optional: | ||
mode: allExceptIBOutlets | ||
|
||
function_parameter_count: | ||
warning: 8 | ||
error: 10 | ||
|
||
line_length: | ||
warning: 121 | ||
error: 200 | ||
ignores_urls: true | ||
ignores_function_declarations: false | ||
ignores_comments: false | ||
|
||
large_tuple: | ||
warning: 8 | ||
error: 10 | ||
|
||
excluded: | ||
- Carthage | ||
- Pods | ||
- .build | ||
reporter: "xcode" |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,39 +1,3 @@ | ||
# Contributing to the YouClap style guide. | ||
|
||
|
||
# Contributing to the Official raywenderlich.com Swift Style Guide. | ||
|
||
This style guide is a living document that evolves with the Swift language. It is different from others you may see, because the focus is centered on readability for print and the web. We created this style guide to keep the code in our books, tutorials, and starter kits nice and consistent — even though we have many different authors working on the books. | ||
|
||
We appreciate and encourage contributions from the community that improve this document and hence the quality of tutorials we produce. This document outlines the process for making contributions to the guide. | ||
|
||
**Note:** You are responsible for adding your name to the list of contributors should you desire. | ||
|
||
## Fixing Typos | ||
|
||
Uncontroversial, non-additive changes such as misspellings, grammar or compiler errors can be fixed by simply issuing a pull request to master. The maintainer will merge the pull request or, if it is deemed "controversial" request the contributor open an issue so that other members of the community can participate in the discussion. | ||
|
||
## Style Changes | ||
|
||
Authors at RayWenderlich.com are expected to follow all of the rules in this style guide unless special circumstances apply. Because of this, it is important that updates happen at predictable times. Be aware in advance that there may be a significant delay (many months) before a suggestion is ratified on the master branch. | ||
### Step 1: Open an Issue | ||
|
||
Open an issue on github and describe the change you would like to see or rule that you would like to have added. You can even propose the exact change in github markdown which can be pasted into the guide. | ||
### Step 2: Wait for Community Feedback | ||
|
||
Wait for feedback on the issue. Even if the feedback is negative, don't close the issue too quickly. Often times the discussion itself can be useful and give way to something even better. Style guides are very subjective and it is important to always be respectful. We expect participants to follow the same community guidelines as the Swift project itself outlined at [contributor-covenant.org](http://contributor-covenant.org) | ||
### Step 3: Wait for Maintainer Go Ahead | ||
|
||
The maintainer will decide if a change is go or no go. This decision is not necessarily based on the feedback of the community, but will often play a role. If you believe that the maintainer is mistaken, you can appeal the decision by just asking them. At this point the maintainer will poll the RayWenderlich team leads for a final decision with RayWenderlich acting as tie breaker if required. Apologies in advance if your style suggestion isn't accepted. You are always welcome, however, to make your own style guide for your organization or community! | ||
### Step 4: Create a Pull Request on the Update branch | ||
|
||
Given the go ahead from the maintainer, create a pull request on the update branch in the repo. There should be one of these. If it is not clear what it is, ask the maintainer. The current update branch is `update.` | ||
### Step 5: Branch Merged | ||
|
||
At this point your involvement is complete. The maintainer will merge your PR to the update branch. | ||
### Step 6: Update Branch Reviewed | ||
|
||
The RayWenderlich.com team has a chance to look at the final updated document before it is merged to master. If an objection is raised, as with the appeal process, teams leads will deliberate on the final decision. | ||
|
||
### Step 7: Update Branch Merged to Master | ||
|
||
Hurray! | ||
⚠️ under development... 🚧 |
Oops, something went wrong.