21 lines
1.3 KiB
Plaintext
21 lines
1.3 KiB
Plaintext
=== on 8 Oct 2014, 07:20:32 Nicolas Peru wrote:
|
|
\[~ann.campbell.2]Why non-private ?
|
|
|
|
=== on 8 Oct 2014, 12:16:15 Ann Campbell wrote:
|
|
\[~nicolas.peru] we already have a separate rule about private fields: RSPEC-1068, and because the advice is different. If they're private and not used, they're dead code. If they're not private and _apparently_ unused, they might still be accessed directly by classes that just aren't currently 'visible'.
|
|
|
|
=== on 10 Oct 2014, 14:15:18 Freddy Mallet wrote:
|
|
@Ann :
|
|
|
|
* I would use the label "pitfall"
|
|
* Moreover for me there is no intersection between this rule and rule RSPEC-1068. In case of RSPEC-1068 we're looking for unused fields whereas here we're looking for fields that ARE really used but never updated and so which should be declared as 'final'
|
|
* I would decrease the remediation cost to 2 min and associate this rule to the Maintainability > Understandability characteristic
|
|
* This rule would be limited at first to private fields but I would not mention this limitation
|
|
|
|
=== on 15 May 2015, 09:53:17 Elena Vilchik wrote:
|
|
\[~ann.campbell.2] I want to expand the scope of this rule for Swift "Fields *and variables* that are never updated should be constant". WDYT can I do it in subtask for this rule?
|
|
|
|
=== on 15 May 2015, 11:52:30 Ann Campbell wrote:
|
|
Fine with me [~elena.vilchik]
|
|
|