Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Property-Variable Fixes #3

Merged
merged 4 commits into from
Aug 6, 2016
Merged

Property-Variable Fixes #3

merged 4 commits into from
Aug 6, 2016

Conversation

drumnkyle
Copy link
Contributor

No description provided.

@drumnkyle
Copy link
Contributor Author

@cezarywojcik take a look and see if you agree.

@@ -51,7 +51,7 @@ class SomeClass {
}
```

* **1.6** When writing a type for a property, a key for a dictionary, a function argument, a protocol conformance, or a superclass, don't add a space before the colon.
* **1.6** When writing a type for a property, contant or variable, a key for a dictionary, a function argument, a protocol conformance, or a superclass, don't add a space before the colon.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. spelling: contant -> constant
  2. I'd just write it as "... property, constant, variable, a key ..."

@@ -147,7 +147,7 @@ someFunctionWithABunchOfArguments(
})
```

* **1.12** Prefer using local properties or other mitigation techniques to avoid multi-line predicates where possible.
* **1.12** Prefer using local variables or constants or other mitigation techniques to avoid multi-line predicates where possible.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

super-minor: I'd put constant first ("constants or variables") or maybe even just "constants" here. shouldn't have to use variables for broken-up predicates I think.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point. I'll change it now.

@drumnkyle
Copy link
Contributor Author

@cezarywojcik Comment here when you are done reviewing, so I know.

@@ -379,7 +379,7 @@ for integer in [4, 8, 15, 16, 23, 42] {
}
```

* **3.1.3** Prefer not declaring types for properties or constants if they can be inferred anyway.
* **3.1.3** Prefer not declaring types for properties, constants, or variables if they can be inferred anyway.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As above, do you think we need to list properties here if we already mentioned both variables and constants? I think that the original distinction here was a somewhat misworded one between instance variables and "static constants", but variables + constants cover those.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For this one, I will agree and will leave it as constants and variables.

@cezarywojcik
Copy link
Member

@drumnkyle Let's also change the if myFirstProperty > (mySecondProperty + myThirdProperty) stuff since "property" in that context isn't super clear. Something like if myFirstValue > (mySecondValue + myThirdValue) && myFourthValue == .someEnumValue) similarly to the myValue change you had made would be good.

Also of note from the above: we have outdated syntax for .SomeEnumValue currently.

LGTM after that.

@drumnkyle drumnkyle merged commit 400cfcf into master Aug 6, 2016
@drumnkyle drumnkyle deleted the property-variable branch August 6, 2016 23:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants