You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When trying to enforce the same code style amongst all team members one issue that often arises is the question, how multi-line literals should be styled. What I mean by multi-line literals is arrays and dictionaries, which are written very differently by every team member if no style is enforced. While one might opt to accept all styles so long as other style rules are not violated, this rule should enforce a clear style which is oriented by the community-accepted style for other multi-line bracket based code like classes and method calls. For those we already have clear conventions:
classSomeType{letx:Intlety:Intfunc sum()->Int{return x = y
}func viewDidLoad(){print("x: \(x)")print("x: \(x)")letsum=sum()letevenNums=[x, y].filter{ $0 %2==0}.map{ num in// some multi-line code// some multi-line code// some multi-line code}}}
While there's of course different styles, one standard widely accepted by the community is to either keep everything in one line including the brackets (like in [x, y].filter { $0 % 2 == 0 } or to put the opening bracket and closing bracket into their own line (like for the class body, the body of the function sum, the body of the function viewDidLoad and the body of the map call).
The same rationale can be applied to function parameters and function arguments as well to enforce a unified multiline style.
Example
The requested opt-in rule requires array and dictionary literals to be styled according to the same rules, to be consistent with other multi-line bracket structure style, for example:
This code is not bad per se, but it could lead to line-length problems when the name of the variable is relatively long. Also renaming the variable in one branch and changing the value of the first literal entry in another branch would lead to a merge conflict. To fix these problems and at the same time be consistent with other brackets, here's the style to be enforced by the new rule:
This fixes the line-length problem, prevents merge-conflicts when both the first literal object and the literal variable name are changed in different branches and is consistent with other bracket rules as it puts the opening and closing braces into their own line, just like usually done with { and }.
The text was updated successfully, but these errors were encountered:
Jeehut
changed the title
Multiline Literal Bracket Style consistent with other bracket conventions
Multiline Literal Bracket: consistent style with other bracket conventions
Jul 23, 2018
Jeehut
changed the title
Multiline Literal Bracket: consistent style with other bracket conventions
Multiline Brackets: consistent style with other bracket conventions
Jul 23, 2018
Rationale
When trying to enforce the same code style amongst all team members one issue that often arises is the question, how multi-line literals should be styled. What I mean by
multi-line literals
is arrays and dictionaries, which are written very differently by every team member if no style is enforced. While one might opt to accept all styles so long as other style rules are not violated, this rule should enforce a clear style which is oriented by the community-accepted style for other multi-line bracket based code like classes and method calls. For those we already have clear conventions:While there's of course different styles, one standard widely accepted by the community is to either keep everything in one line including the brackets (like in
[x, y].filter { $0 % 2 == 0 }
or to put the opening bracket and closing bracket into their own line (like for the class body, the body of the functionsum
, the body of the functionviewDidLoad
and the body of themap
call).The same rationale can be applied to function parameters and function arguments as well to enforce a unified multiline style.
Example
The requested opt-in rule requires array and dictionary literals to be styled according to the same rules, to be consistent with other multi-line bracket structure style, for example:
This code is not bad per se, but it could lead to line-length problems when the name of the variable is relatively long. Also renaming the variable in one branch and changing the value of the first literal entry in another branch would lead to a merge conflict. To fix these problems and at the same time be consistent with other brackets, here's the style to be enforced by the new rule:
This fixes the line-length problem, prevents merge-conflicts when both the first literal object and the literal variable name are changed in different branches and is consistent with other bracket rules as it puts the opening and closing braces into their own line, just like usually done with
{
and}
.The text was updated successfully, but these errors were encountered: