Addressed some PR comments

This commit is contained in:
Tomi De Lucca
2019-08-04 15:25:30 -03:00
parent 443be1715f
commit 89ede940d3
5 changed files with 85 additions and 4 deletions

View File

@ -11,11 +11,12 @@ folder: pmd/rules
{% include callout.html content="Rules which enforce generally accepted best practices." %}
* [ProhibitedInterfaceBuilder](pmd_rules_swift_bestpractices.html#prohibitedinterfacebuilder): Creating views using Interface Builder should be avoided.
* [ProhibitedInterfaceBuilder](pmd_rules_swift_bestpractices.html#prohibitedinterfacebuilder): Creating views using Interface Builder should be avoided. Defining views by code allow...
## Error Prone
{% include callout.html content="Rules to detect constructs that are either broken, extremely confusing or prone to runtime errors." %}
* [ForceTry](pmd_rules_swift_errorprone.html#forcetry): Force tries should be avoided.
* [ForceCast](pmd_rules_swift_errorprone.html#forcecast): Force casts should be avoided. This may lead to a crash if it's not used carefully. Fo...
* [ForceTry](pmd_rules_swift_errorprone.html#forcetry): Force tries should be avoided. If the code being wrapped happens to raise and exception, our appl...

View File

@ -16,9 +16,24 @@ language: Swift
**Priority:** Medium High (2)
Creating views using Interface Builder should be avoided.
Defining views by code allows the compiler to detect issues that otherwise will be runtime errors.
It's difficult to review the auto-generated code and allow concurrent modifications of those files.
Consider building views programmatically.
**This rule is defined by the following Java class:** [net.sourceforge.pmd.lang.swift.rule.bestpractices.ProhibitedInterfaceBuilderRule](https://github.com/pmd/pmd/blob/master/pmd-swift/src/main/java/net/sourceforge/pmd/lang/swift/rule/bestpractices/ProhibitedInterfaceBuilderRule.java)
**Example(s):**
``` swift
{%raw%}class ViewController: UIViewController {
@IBOutlet var label: UILabel! // violation, referencing a IBOutlet
}
class ViewController: UIViewController {
var label: UILabel!
}{%endraw%}
```
**Use this rule by referencing it:**
``` xml
<rule ref="category/swift/bestpractices.xml/ProhibitedInterfaceBuilder" />

View File

@ -5,23 +5,60 @@ permalink: pmd_rules_swift_errorprone.html
folder: pmd/rules/swift
sidebaractiveurl: /pmd_rules_swift.html
editmepath: ../pmd-swift/src/main/resources/category/swift/errorprone.xml
keywords: Error Prone, ForceTry
keywords: Error Prone, ForceCast, ForceTry
language: Swift
---
<!-- DO NOT EDIT THIS FILE. This file is generated from file ../pmd-swift/src/main/resources/category/swift/errorprone.xml. -->
## ForceCast
**Since:** PMD 7.0
**Priority:** Medium (3)
Force casts should be avoided. This may lead to a crash if it's not used carefully.
For example assuming a JSON property has a given type, or your reused Cell has a certain contract.
Consider using conditional casting and handling the resulting optional.
**This rule is defined by the following XPath expression:**
``` xpath
//TypeCastingOperatorContext[starts-with(@Text,'as!')]
```
**Example(s):**
``` swift
{%raw%}NSNumber() as! Int // violation, force casting
NSNumber() as? Int // no violation{%endraw%}
```
**Use this rule by referencing it:**
``` xml
<rule ref="category/swift/errorprone.xml/ForceCast" />
```
## ForceTry
**Since:** PMD 7.0
**Priority:** Medium (3)
Force tries should be avoided.
Force tries should be avoided. If the code being wrapped happens to raise and exception, our application will crash.
Consider using a conditional try and handling the resulting optional, or wrapping the try statement in a do-catch block.
**This rule is defined by the following XPath expression:**
``` xpath
//TryOperatorContext[@Text='try!']
```
**Example(s):**
``` swift
{%raw%}let x = try! someThrowingFunction() // violation, force trying
let x = try? someThrowingFunction() // no violation{%endraw%}
```
**Use this rule by referencing it:**
``` xml
<rule ref="category/swift/errorprone.xml/ForceTry" />

View File

@ -18,7 +18,19 @@ Rules which enforce generally accepted best practices.
Creating views using Interface Builder should be avoided.
Defining views by code allows the compiler to detect issues that otherwise will be runtime errors.
It's difficult to review the auto-generated code and allow concurrent modifications of those files.
Consider building views programmatically.
</description>
<priority>2</priority>
<example>
<![CDATA[
class ViewController: UIViewController {
@IBOutlet var label: UILabel! // violation, referencing a IBOutlet
}
class ViewController: UIViewController {
var label: UILabel!
}
]]>
</example>
</rule>
</ruleset>

View File

@ -18,6 +18,7 @@
<description>
Force casts should be avoided. This may lead to a crash if it's not used carefully.
For example assuming a JSON property has a given type, or your reused Cell has a certain contract.
Consider using conditional casting and handling the resulting optional.
</description>
<priority>3</priority>
<properties>
@ -30,6 +31,13 @@
</property>
<property name="version" value="2.0"/>
</properties>
<example>
<![CDATA[
NSNumber() as! Int // violation, force casting
NSNumber() as? Int // no violation
]]>
</example>
</rule>
<rule name="ForceTry"
@ -40,6 +48,7 @@
externalInfoUrl="http://pmd.github.io/pmd/pmd_rules_swift_errorprone.html#forcetry">
<description>
Force tries should be avoided. If the code being wrapped happens to raise and exception, our application will crash.
Consider using a conditional try and handling the resulting optional, or wrapping the try statement in a do-catch block.
</description>
<priority>3</priority>
<properties>
@ -52,5 +61,12 @@
</property>
<property name="version" value="2.0"/>
</properties>
<example>
<![CDATA[
let x = try! someThrowingFunction() // violation, force trying
let x = try? someThrowingFunction() // no violation
]]>
</example>
</rule>
</ruleset>