Programmers should not comment out code as it bloats programs and reduces readability.
-Unused code should be deleted and can be retrieved from source control history if required.
+Commented-out code distracts the focus from the actual executed code. It creates a noise that increases maintenance code. And because it is never +executed, it quickly becomes out of date and invalid.
+Commented-out code should be deleted and can be retrieved from source control history if required.
diff --git a/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/NonEmptyCaseWithoutBreak.html b/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/NonEmptyCaseWithoutBreak.html index e6d0c2f5..ffde3577 100644 --- a/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/NonEmptyCaseWithoutBreak.html +++ b/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/NonEmptyCaseWithoutBreak.html @@ -48,6 +48,6 @@Merging collapsible if statements increases the code’s readability.
Nested code - blocks of code inside blocks of code - is eventually necessary, but increases complexity. This is why keeping the code as flat as +possible, by avoiding unnecessary nesting, is considered a good practice.
+Merging if statements when possible will decrease the nesting of the code and improve its readability.
Code like
if (condition1) {
- if (condition2) { // NonCompliant
+ if (condition2) { // Noncompliant
...
}
}
-Is more readable as
if (condition1 && condition2) {
...
diff --git a/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1066.json b/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1066.json
index f6857be3..732a6ea9 100644
--- a/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1066.json
+++ b/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1066.json
@@ -1,5 +1,5 @@
{
- "title": "Collapsible \"if\" statements should be merged",
+ "title": "Mergeable \"if\" statements should be combined",
"type": "CODE_SMELL",
"code": {
"impacts": {
diff --git a/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1068.html b/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1068.html
index a50f6ed9..aecba307 100644
--- a/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1068.html
+++ b/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1068.html
@@ -1,19 +1,10 @@
Why is this an issue?
-If a private field is declared but not used in the program, it can be considered dead code and should therefore be removed. This will
-improve maintainability because developers will not wonder what the variable is used for.
-Noncompliant code example
-
-public class MyClass {
- private var foo:int = 4; //foo is unused
-
- public function compute(a:int):int{
- return a * 4;
- }
-}
-
-Compliant solution
+If a private field is declared but not used locally, its limited visibility makes it dead code.
+This is either a sign that some logic is missing or that the code should be cleaned.
+Cleaning out dead code decreases the size of the maintained codebase, making it easier to understand and preventing bugs from being introduced.
public class MyClass {
+ private var foo:int = 4; // Noncompliant: foo is unused and should be removed
public function compute(a:int):int{
return a * 4;
diff --git a/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S107.html b/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S107.html
index f7ae5242..031b131e 100644
--- a/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S107.html
+++ b/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S107.html
@@ -1,5 +1,5 @@
Why is this an issue?
-Functions with a long parameter list are difficult to use, as maintainers must figure out the role of each parameter and keep track of their
+
Functions with a long parameter list are difficult to use because maintainers must figure out the role of each parameter and keep track of their
position.
function setCoordinates(var x1, var y1, var z1, var x2, var y2, var z2) { // Noncompliant
diff --git a/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1116.html b/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1116.html
index 3f2abd20..34829829 100644
--- a/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1116.html
+++ b/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1116.html
@@ -1,9 +1,7 @@
Why is this an issue?
-Empty statements, i.e. ;, are usually introduced by mistake, for example because:
-;;. Empty statements represented by a semicolon ; are statements that do not perform any operation. They are often the result of a typo or
+a misunderstanding of the language syntax. It is a good practice to remove empty statements since they don’t add value and lead to confusion and
+errors.
function doSomething():void {
diff --git a/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1117.html b/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1117.html
index 2dff5850..be8574c2 100644
--- a/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1117.html
+++ b/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1117.html
@@ -1,13 +1,23 @@
Why is this an issue?
-Overriding or shadowing a variable declared in an outer scope can strongly impact the readability, and therefore the maintainability, of a piece of
-code. Further, it could lead maintainers to introduce bugs because they think they’re using one variable but are really using another.
+Shadowing occurs when a local variable has the same name as a variable or a field in an outer scope.
+This can lead to three main problems:
+To avoid these problems, rename the shadowing, shadowed, or both identifiers to accurately represent their purpose with unique and meaningful +names.
+This rule focuses on variables in methods that shadow a field.
+
class Foo {
public var myField:int;
public function doSomething():String {
- var myField:int = 0; /* Noncompliant */
- ...
+ var myField:int = 0; // Noncompliant
+ //...
}
}
diff --git a/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1117.json b/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1117.json
index f25aa897..11887dd5 100644
--- a/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1117.json
+++ b/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1117.json
@@ -1,5 +1,4 @@
{
- "title": "Local variables should not shadow class fields",
"type": "CODE_SMELL",
"code": {
"impacts": {
@@ -20,5 +19,6 @@
"ruleSpecification": "RSPEC-1117",
"sqKey": "S1117",
"scope": "All",
- "quickfix": "unknown"
+ "quickfix": "unknown",
+ "title": "Local variables should not shadow class fields"
}
diff --git a/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1125.html b/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1125.html
index e530943a..d06a9af1 100644
--- a/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1125.html
+++ b/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1125.html
@@ -1,7 +1,14 @@
Redundant Boolean literals should be removed from expressions to improve readability.
-+A boolean literal can be represented in two different ways:
+trueorfalse. They can be combined with logical operators +(!, &&, ||, ==, !=) to produce logical expressions that represent truth values. However, comparing a boolean literal to a +variable or expression that evaluates to a boolean value is unnecessary and can make the code harder to read and understand. The more complex a +boolean expression is, the harder it will be for developers to understand its meaning and expected behavior, and it will favour the introduction of +new bugs.How to fix it
+Remove redundant boolean literals from expressions to improve readability and make the code more maintainable.
+Code examples
+Noncompliant code example
+if (booleanMethod() == true) { /* ... */ } if (booleanMethod() == false) { /* ... */ } if (booleanMethod() || false) { /* ... */ } @@ -14,8 +21,8 @@-Noncompliant code example
booleanVariable = booleanMethod() ? exp : true; booleanVariable = booleanMethod() ? exp : false;Compliant solution
-+Compliant solution
+if (booleanMethod()) { /* ... */ } if (!booleanMethod()) { /* ... */ } if (booleanMethod()) { /* ... */ } diff --git a/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1144.html b/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1144.html index dd147b72..ac2a18c9 100644 --- a/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1144.html +++ b/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1144.html @@ -1,25 +1,27 @@ +This rule raises an issue when a private function is never referenced in the code.
Why is this an issue?
-Private functions that are never executed are dead code: unnecessary, inoperative code that should be removed. Cleaning out dead code decreases the -size of the maintained codebase, making it easier to understand the program and preventing bugs from being introduced.
-Noncompliant code example
-+A function that is never called is dead code, and should be removed. Cleaning out dead code decreases the size of the maintained codebase, making +it easier to understand the program and preventing bugs from being introduced.
+This rule detects functions that are never referenced from inside a translation unit, and cannot be referenced from the outside.
+Code examples
+Noncompliant code example
+public class Foo { - private function Foo(){} //Compliant, private empty constructor intentionally used to prevent any direct instantiation of a class. - public static function doSomething():void + public static function doSomething(): void // Compliant - public function { var foo:Foo = new Foo(); ... } - private function unusedPrivateFunction():void {...} + + private function unusedPrivateFunction(): void {...} // Noncompliant }-Compliant solution
-+Compliant solution
+public class Foo { - private function Foo(){} //Compliant, private empty constructor intentionally used to prevent any direct instantiation of a class. - public static function doSomething():void + public static function doSomething(): void // Compliant - public function { var foo:Foo = new Foo(); ... diff --git a/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1144.json b/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1144.json index 41e06ecc..6c901275 100644 --- a/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1144.json +++ b/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1144.json @@ -10,7 +10,7 @@ "status": "ready", "remediation": { "func": "Constant\/Issue", - "constantCost": "5min" + "constantCost": "2min" }, "tags": [ "unused" diff --git a/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1145.html b/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1145.html index 33ba3a98..10fcf894 100644 --- a/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1145.html +++ b/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1145.html @@ -25,8 +25,8 @@Compliant solution
Resources
Constants should be named consistently to communicate intent and improve maintainability. Rename your constants to follow your project’s naming +convention to address this issue.
Shared coding conventions allow teams to collaborate efficiently. This rule checks that all constant names match a provided regular expression.
-With the default regular expression ^[A-Z][A-Z0-9]*(_[A-Z0-9]+)*$:
+Constants are variables whose value does not change during the runtime of a program after initialization. Oftentimes, constants are used in +multiple locations across different subroutines.
+It is important that the names of constants follow a consistent and easily recognizable pattern. This way, readers immediately understand that the +referenced value does not change, which simplifies debugging.
+This rule checks that all constant names match a given regular expression.
+What is the potential impact?
+Ignoring the naming convention for constants makes the code less readable since constants and variables are harder to tell apart. Code that is hard +to understand is also difficult to maintain between different team members.
+How to fix it
+First, familiarize yourself with the particular naming convention of the project in question. Then, update the name of the constant to match the +convention, as well as all usages of the name. For many IDEs, you can use built-in renaming and refactoring features to update all usages of a +constant at once.
+Code examples
+Noncompliant code example
+The following example assumes that constant names should match the default regular expression
+^[A-Z][A-Z0-9]*(_[A-Z0-9]+)*$:public static const first:String = "first";-Compliant solution
-+Compliant solution
+public static const FIRST:String = "first";diff --git a/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S116.html b/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S116.html index 530fc6e0..bc75bb56 100644 --- a/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S116.html +++ b/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S116.html @@ -1,17 +1,23 @@Why is this an issue?
-Sharing some naming conventions is a key point to make it possible for a team to efficiently collaborate. This rule allows to check that field -names match a provided regular expression.
-Noncompliant code example
-With the default regular expression
-^[_a-z][a-zA-Z0-9]*$:+A naming convention in software development is a set of guidelines for naming code elements like variables, functions, and classes.
+The goal of a naming convention is to make the code more readable and understandable, which makes it easier to maintain and debug. It also ensures +consistency in the code, especially when multiple developers are working on the same project.
+This rule checks that field names match a provided regular expression.
+Using the regular expression
+^[_a-z][a-zA-Z0-9]*$, the noncompliant code below:class MyClass { public var my_field:int; }-Compliant solution
-+Should be replaced with:
+public class MyClass { public var myField:int; }+Resources
+Documentation
+
Local variables and function parameters should be named consistently to communicate intent and improve maintainability. Rename your local variable +or function parameter to follow your project’s naming convention to address this issue.
Shared naming conventions allow teams to collaborate effectively. This rule raises an issue when a local variable or function parameter name does -not match the provided regular expression.
-A naming convention in software development is a set of guidelines for naming code elements like variables, functions, and classes.
Local
+variables and function parameters hold the meaning of the written code. Their names should be meaningful and follow a consistent and easily
+recognizable pattern.
Adhering to a consistent naming convention helps to make the code more readable and understandable, which makes it easier to
+maintain and debug. It also ensures consistency in the code, especially when multiple developers are working on the same project.
This rule checks that local variable and function parameter names match a provided regular expression.
+Inconsistent naming of local variables and function parameters can lead to several issues in your code:
+In summary, not adhering to a naming convention for local variables and function parameters can lead to confusion, errors, and inefficiencies, +making the code harder to read, understand, and maintain.
+First, familiarize yourself with the particular naming convention of the project in question. Then, update the name to match the convention, as +well as all usages of the name. For many IDEs, you can use built-in renaming and refactoring features to update all usages at once.
+With the default regular expression ^[_a-z][a-zA-Z0-9]*$:
+public function doSomething(my_param:int):void { var LOCAL:int; ... }-Compliant solution
-+Compliant solution
+public function doSomething(myParam):void { var local; ... }+Resources
+Documentation
+
Unused parameters are misleading. Whatever the value passed to such parameters is, the behavior will be the same.
-
-function doSomething(a:int, b:int):void // "b" is unused
-{
- compute(a);
-}
-
-
-function doSomething(a:int):void
-{
- compute(a);
-}
-
+A typical code smell known as unused function parameters refers to parameters declared in a function but not used anywhere within the function’s +body. While this might seem harmless at first glance, it can lead to confusion and potential errors in your code. Disregarding the values passed to +such parameters, the function’s behavior will be the same, but the programmer’s intention won’t be clearly expressed anymore. Therefore, removing +function parameters that are not being utilized is considered best practice.
The following cases are ignored
+The rule ignores the following cases:
throw statement (i.e. where the intention is
- apparently to simulate an abstract class). throw statement (i.e. where the intention is to
+ simulate an abstract class).
override function doSomething(a:int):void { // ignored
@@ -51,4 +40,22 @@ Exceptions
trace("click");
}
+Having unused function parameters in your code can lead to confusion and misunderstanding of a developer’s intention. They reduce code readability +and introduce the potential for errors. To avoid these problems, developers should remove unused parameters from function declarations.
+
+function doSomething(a:int, b:int):void // "b" is unused
+{
+ compute(a);
+}
+
+
+function doSomething(a:int):void
+{
+ compute(a);
+}
+
diff --git a/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1176.html b/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1176.html
index 2007fe3a..4c8135b7 100644
--- a/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1176.html
+++ b/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1176.html
@@ -1,17 +1,54 @@
+A good API documentation is a key factor in the usability and success of a software API. It ensures that developers can effectively use, maintain, +and collaborate on the API.
Try to imagine using the standard Flex API without ASDoc. It would be a nightmare, because ASDoc is the only way to understand of the contract of -the API.
-Documenting an API with ASDoc increases the productivity of the developers use it.
-Undocumented APIs pose significant challenges in software development for several reasons:
+It is recommended to document the API using ASDoc to clarify what is the contract of the API. This is especially important for +public APIs, as they are used by other developers.
+Classes or class elements with an ASDoc @private comment are ignored by this rule.
+/**
+ * @private // This class and all its elements are ignored
+ */
+public class MyClass { // Compliant
+
+ public var myLabel:String; // Compliant
+}
+
+public class AnotherClass { // Noncompliant; class not @private and not documented
+
+ /**
+ * @private
+ */
+ public var name:String; // Compliant
+}
+
+Add the missing ASDoc for the public classes, methods, properties and metadata.
+
public class MyClass {
public var myLabel:String;
- public function myMethod(param1:String):Boolean {...}
+ public function myMethod(param1:String):Boolean {
+ // ...
+ }
}
-+Compliant solution
+/** * my doc */ @@ -26,26 +63,17 @@-Compliant solution
* @param param1 my doc * @return my doc */ - public function myMethod(param1:String):Boolean {...} -} -Exceptions
-Classes or class elements with an ASDoc
-@privatecomment are ignored by this rule.-/** - * @private // This class and all its elements are ignored - */ -public class MyClass { // Compliant - - public var myLabel:String; // Compliant -} - -public class AnotherClass { // Noncompliant; class not @private and not documented - - /** - * @private - */ - public var name:String; // Compliant + public function myMethod(param1:String):Boolean { + // ... + } }+Resources
+Articles & blog posts
+
There are several reasons for a method not to have a method body:
+An empty function is generally considered bad practice and can lead to confusion, readability, and maintenance issues. Empty functions bring no +functionality and are misleading to others as they might think the function implementation fulfills a specific and identified requirement.
+There are several reasons for a function not to have a body:
NotSupportedException should be thrown.
-public override function doSomething():void {
+How to fix it
+Code examples
+Noncompliant code example
+
+public function shouldNotBeEmpty():void { // Noncompliant - method is empty
}
-public function doSomethingElse():void {
+public function notImplemented():void { // Noncompliant - method is empty
+}
+
+public override function emptyOnPurpose():void { // Noncompliant - method is empty
}
-Compliant solution
-
-public override function doSomething():void {
- throw new IllegalOperationError("doSomething cannot be performed because ...");
+Compliant solution
+
+public function shouldNotBeEmpty():void {
+ doSomething();
+}
+
+public function notImplemented():void {
+ throw new Error("notImplemented() cannot be performed because ...");
}
-public function doSomethingElse():void {
- //This method is empty because ...
+public override function emptyOnPurpose():void {
+ // comment explaining why the method is empty
}
diff --git a/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1186.json b/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1186.json
index 42c07f99..ab7982da 100644
--- a/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1186.json
+++ b/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1186.json
@@ -19,5 +19,5 @@
"ruleSpecification": "RSPEC-1186",
"sqKey": "S1186",
"scope": "All",
- "quickfix": "unknown"
+ "quickfix": "infeasible"
}
diff --git a/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S120.html b/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S120.html
index 09358dab..9e5999e0 100644
--- a/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S120.html
+++ b/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S120.html
@@ -1,14 +1,18 @@
Why is this an issue?
-Shared coding conventions allow teams to collaborate efficiently. This rule checks that all package names match a provided regular expression.
-Noncompliant code example
+Shared naming conventions improve readability and allow teams to collaborate efficiently. This rule checks that all package names match a provided
+regular expression.
+How to fix it
+Rename packages with the expected naming convention
+Code examples
+Noncompliant code example
With the default regular expression ^[a-z]+(\.[a-z][a-z0-9]*)*$:
-
+
package org.Example { // Noncompliant
...
}
-Compliant solution
-
+Compliant solution
+
package org.example {
...
}
diff --git a/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1312.json b/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1312.json
index f54144f7..0dfb3be7 100644
--- a/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1312.json
+++ b/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1312.json
@@ -13,7 +13,8 @@
"constantCost": "5min"
},
"tags": [
- "convention"
+ "convention",
+ "logging"
],
"defaultSeverity": "Minor",
"ruleSpecification": "RSPEC-1312",
diff --git a/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1314.json b/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1314.json
index 66bbaf09..d7557e6e 100644
--- a/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1314.json
+++ b/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1314.json
@@ -3,7 +3,7 @@
"type": "CODE_SMELL",
"code": {
"impacts": {
- "MAINTAINABILITY": "HIGH"
+ "MAINTAINABILITY": "BLOCKER"
},
"attribute": "CLEAR"
},
diff --git a/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S134.html b/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S134.html
index 3f0a5013..64a67ff3 100644
--- a/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S134.html
+++ b/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S134.html
@@ -1,9 +1,13 @@
Why is this an issue?
-Nested if, for, while, do while and switch statements is a key ingredient for
-making what’s known as "Spaghetti code".
-Such code is hard to read, refactor and therefore maintain.
-Noncompliant code example
-With the default threshold of 3:
+Nested control flow statements if, for, while, do while and switch are often key
+ingredients in creating what’s known as "Spaghetti code". This code smell can make your program difficult to understand and maintain.
+When numerous control structures are placed inside one another, the code becomes a tangled, complex web. This significantly reduces the code’s
+readability and maintainability, and it also complicates the testing process.
+How to fix it
+Code examples
+The following example demonstrates the behavior of the rule with the default threshold of 3 levels of nesting and one of the potential ways to fix
+the code smell by introducing guard clauses:
+Noncompliant code example
if (condition1) { // Compliant - depth = 1
/* ... */
@@ -21,4 +25,9 @@ Noncompliant code example
}
}
+Resources
+
If a local variable is declared but not used, it is dead code and should be removed. Doing so will improve maintainability because developers will -not wonder what the variable is used for.
-+An unused local variable is a variable that has been declared but is not used anywhere in the block of code where it is defined. It is dead code, +contributing to unnecessary complexity and leading to confusion when reading the code. Therefore, it should be removed from your code to maintain +clarity and efficiency.
+What is the potential impact?
+Having unused local variables in your code can lead to several issues:
+
In summary, unused local variables can make your code less readable, more confusing, and harder to maintain, and they can potentially lead to bugs +or inefficient memory use. Therefore, it is best to remove them.
+The fix for this issue is straightforward. Once you ensure the unused variable is not part of an incomplete implementation leading to bugs, you +just need to remove it.
+
public function numberOfMinutes(hours:int):int
{
- var seconds:int = 0; // seconds is never used
+ var seconds:int = 0; // Noncompliant - seconds is unused
return hours * 60;
}
-+Compliant solution
+public function numberOfMinutes(hours:int):int { return hours * 60; diff --git a/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1820.json b/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1820.json index b66e71c6..7ca46b8b 100644 --- a/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1820.json +++ b/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1820.json @@ -19,5 +19,5 @@ "ruleSpecification": "RSPEC-1820", "sqKey": "S1820", "scope": "Main", - "quickfix": "unknown" + "quickfix": "infeasible" } diff --git a/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1871.html b/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1871.html index f8c6d786..9c849f15 100644 --- a/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1871.html +++ b/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1871.html @@ -1,7 +1,25 @@Why is this an issue?
+When the same code is duplicated in two or more separate branches of a conditional, it can make the code harder to understand, maintain, and can +potentially introduce bugs if one instance of the code is changed but others are not.
Having two
casesin aswitchstatement or two branches in anifchain with the same implementation is at best duplicate code, and at worst a coding error.+if (a >= 0 && a < 10) { + doFirstThing(); + doTheThing(); +} +else if (a >= 10 && a < 20) { + doTheOtherThing(); +} +else if (a >= 20 && a < 50) { + doFirstThing(); + doTheThing(); // Noncompliant; duplicates first condition +} +else { + doTheRest(); +} ++switch (i) { case 1: doFirstThing(); @@ -18,27 +36,11 @@-Why is this an issue?
doTheRest(); }-if (a >= 0 && a < 10) { - doFirstThing(); - doTheThing(); -} -else if (a >= 10 && a < 20) { - doTheOtherThing(); -} -else if (a >= 20 && a < 50) { - doFirstThing(); - doTheThing(); // Noncompliant; duplicates first condition -} -else { - doTheRest(); -} -If the same logic is truly needed for both instances, then:
if chain they should be combined
+
if ((a >= 0 && a < 10) || (a >= 20 && a < 50)) { // Compliant
doFirstThing();
doTheThing();
@@ -51,9 +53,9 @@ Why is this an issue?
}
switch, one should fall through to the other. switch, one should fall through to the other
+
switch (i) {
case 1:
case 3: // Compliant
@@ -74,7 +76,7 @@ Exceptions
switch statement that contains a single line of code with or without a following break.
if (a == 1) {
- doSomething(); //no issue, usually this is done on purpose to increase the readability
+ doSomething(); // Compliant, usually this is done on purpose to increase the readability
} else if (a == 2) {
doSomethingElse();
} else {
diff --git a/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1871.json b/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1871.json
index 94130e8b..cf1a5247 100644
--- a/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1871.json
+++ b/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1871.json
@@ -20,5 +20,5 @@
"ruleSpecification": "RSPEC-1871",
"sqKey": "S1871",
"scope": "Main",
- "quickfix": "unknown"
+ "quickfix": "infeasible"
}
diff --git a/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1951.html b/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1951.html
index 59df2c6b..4005119b 100644
--- a/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1951.html
+++ b/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S1951.html
@@ -13,8 +13,8 @@ Compliant solution
Resources
Either there is a copy-paste error that needs fixing or an unnecessary switch or if chain that needs removing.
Either there is a copy-paste error that needs fixing or an unnecessary switch or if chain that should be removed.
This rule does not apply to if chains without else, nor to switch without a default clause.
diff --git a/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S4507.html b/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S4507.html index 456d4a09..6c6de1c3 100644 --- a/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S4507.html +++ b/flex-checks/src/main/resources/org/sonar/l10n/flex/rules/flex/S4507.html @@ -23,10 +23,10 @@Sensitive Code Example