mirror of
https://github.com/EiffelSoftware/eiffel-org.git
synced 2025-12-07 23:32:42 +01:00
Added release 19.05.
git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@2152 abb3cda0-5349-4a8f-a601-0c33ac3a8c38
This commit is contained in:
jfiat
@@ -0,0 +1,23 @@
|
||||
[[Property:modification_date|Mon, 24 Dec 2018 07:44:49 GMT]]
|
||||
[[Property:publication_date|Mon, 24 Dec 2018 07:44:49 GMT]]
|
||||
[[Property:title|Code Analyzer: Interpreting Results]]
|
||||
[[Property:link_title|Interpreting Results]]
|
||||
[[Property:weight|-13]]
|
||||
[[Property:uuid|e4670791-7885-b9a0-6a1c-0d9611eb5f5d]]
|
||||
= Sorting and Filtering =
|
||||
|
||||
The list of rule violations can be sorted by any column by clicking on its header. Click it again to switch the sorting direction. You can hide and show errors, warnings, suggestions, and hints by clicking the corresponding toggle buttons in the middle of the toolbar. Typing in the text field on the right side of the panel toolbar filters the results. The filter takes into consideration the title, the ID, the affected class, and the description of the rule. It is a live filter that filters while you are typing. Press the button on the right of the text field to clear the filter and display again all violations.
|
||||
|
||||
[[Image:CA Simple Analysis|center|978px|The Results of code analysis as a list of rule violations (example)]]
|
||||
|
||||
= Navigating Through the Results =
|
||||
|
||||
In the list of rule violations, formatted elements like classes and features are clickable and draggable like anywhere else. In order to navigate to a specific rule violation just double-click the corresponding row. The corresponding class will be opened (if needed) and the cursor will jump to the exact location of the rule violation (some violations do not have an exact location because they refer to a whole class). You can also navigate through the results using the '''Go to next rule violation''' and '''Go to previous rule violation''' buttons on the right side of the panel toolbar.
|
||||
|
||||
= Fixing Rule Violations =
|
||||
|
||||
[[Image:CA Fixing Rule Violation|center|484px|Fixing a rule violation.]]
|
||||
|
||||
Some violations provide automatic fixing. Right-clicking the corresponding row in the tool panel opens a context menu where you can choose from one or more possible fixes. When you click on ''Fix: ...'' the source code will be adapted and the project will be recompiled.
|
||||
|
||||
|
||||
@@ -0,0 +1,53 @@
|
||||
[[Property:modification_date|Mon, 24 Dec 2018 07:52:18 GMT]]
|
||||
[[Property:publication_date|Mon, 24 Dec 2018 07:52:18 GMT]]
|
||||
[[Property:title|Code Analyzer: Customization]]
|
||||
[[Property:link_title|Customization]]
|
||||
[[Property:weight|-12]]
|
||||
[[Property:uuid|ed86093e-fed0-04b8-6fd4-b05d5de849fc]]
|
||||
= General Preferences =
|
||||
|
||||
The ''Preferences'' button in the toolbar opens a dialog containing all preferences for the Code Analyzer. There you can enable and disable all rules of a certain severity, you can choose colors for the results, and there are many preferences that control the behavior of individual rules.
|
||||
|
||||
[[Image:CA Preference Dialog|center|640px|Preferences]]
|
||||
|
||||
= Rule-specific Preferences =
|
||||
|
||||
The rule-specific preferences are located in the ''Rules'' subfolder. Two preferences can be found for every rule: ''Enabled/disabled'' and the ''severity score''. Some rules have additional integer or boolean preferences like thresholds.
|
||||
|
||||
[[Image:CA Rule Preferences|center|572px|Rule-specific Preferences]]
|
||||
|
||||
= Exporting and Importing Preference Profiles =
|
||||
|
||||
Using the buttons in the preferences dialog one can export these preferences to an XML file or import them. This can be used for creating profiles that stretch across multiple machines. Just set the desired preferences on one machine, export them to a file, distribute this file, and import it.
|
||||
|
||||
{{note| The Code Analyzer preferences are separate from the general EiffelStudio preferences. Pressing ''Restore Defaults'', ''Import ...'', or ''Export ...'' ''only'' affects preferences for the Code Analyzer.''}}
|
||||
|
||||
= Class Options =
|
||||
|
||||
There are cases in which you might want to customize the Code Analyzer for ''parts of your code'' only. The Code Analyzer provides a way to set options ''per class''. You can exclude a class from being checked by certain rules. Also you can declare a class to be a ''library'' or a ''non-library'' class. All class-wide options for the Code Analyzer are set in the ''note clause'' (after the <e>note</e> keyword).
|
||||
|
||||
== Library and Non-Library Classes ==
|
||||
|
||||
If the programmer uses the default values then a rule checks all classes. But a rule can be defined (hard-coded) not to check either ''library'' or ''non-library'' classes. How does the Code Analyzer now know which classes are ''library'' classes and which classes are ''non-library'' classes? This is defined by the user. If, for a certain class, the user does ''not'' define anything then the class will be analyzed in every case. Only if the user declares a class to be a ''library'' class then this class will not be checked by a rule that has disabled checking library classes. The same goes for classes that are declared as ''non-library''.
|
||||
|
||||
* To declare a class to be a ''library'' class add <e>ca_library : "true"</e> to the (top or bottom) indexing clause.
|
||||
* To declare a class to be a ''non-library'' class add <e>ca_library : "false"</e> to the (top or bottom) indexing clause.
|
||||
|
||||
<e>note
|
||||
ca_library: true
|
||||
class TEST
|
||||
end
|
||||
</e>
|
||||
|
||||
== Classes Ignored by Rules ==
|
||||
|
||||
You can declare a class to be ''ignored'' by certain rules, which is equivalent to saying that some rules shall be ''disabled'' for a class.
|
||||
|
||||
To let a class be ignored by certain rules, add the <e>ca_ignoredby</e> tag to the (top or bottom) note clause. Then put all the relevant ''rule IDs'' separated by commas in the content. It may look like this:
|
||||
|
||||
<e>note
|
||||
ca_ignoredby : "CA005, CA092"
|
||||
class TEST
|
||||
end</e>
|
||||
|
||||
|
||||
@@ -0,0 +1,17 @@
|
||||
[[Property:modification_date|Mon, 09 Jul 2018 07:47:11 GMT]]
|
||||
[[Property:publication_date|Mon, 09 Jul 2018 07:47:11 GMT]]
|
||||
[[Property:title|Getting Started]]
|
||||
[[Property:link_title|Getting Started]]
|
||||
[[Property:weight|-15]]
|
||||
[[Property:uuid|81ae12fd-f643-c5ba-825c-7750929f6978]]
|
||||
==Code Analyzer==
|
||||
After opening an existing project with EiffelStudio, go to Project->Analyze... to run the tool.
|
||||
|
||||
== A Simple Analysis ==
|
||||
|
||||
Select the menu item '''Analyze System Target'''. If needed, the system will be compiled now. A successful compilation is required for the Code Analyzer to run. After a successful compilation the analysis will start and will check all classes of your system. The status bar shows the progress by displaying the class currently being analyzed. As soon as the analysis is complete, results will show up in the error panel as a list of ''rule violations''.
|
||||
|
||||
The results of code analysis as a list of rule violations (example).
|
||||
[[Image:CA Simple Analysis|center|978px|Code Analyzer - Simple Analysis]]
|
||||
|
||||
A double-click on a row will update the EiffelStudio editor to go to the position in the code where the issue lies. You may expand the row to see more details.
|
||||
@@ -0,0 +1,37 @@
|
||||
[[Property:title|CA001 - Self Assignment]]
|
||||
[[Property:link_title|CA001]]
|
||||
[[Property:weight|0]]
|
||||
[[Property:uuid|d98b7fb8-37a1-05b3-a58f-baacefd5dce6]]
|
||||
__NOTOC__
|
||||
=Description=
|
||||
Assigning a variable to itself is a meaningless instruction due to a typing error. Most probably, one of the two variable names was misspelled. One example among many others: the programmer wanted to assign a local variable to a class attribute and used one of the variable names twice.
|
||||
:{| class="doctable"
|
||||
|-
|
||||
| '''Scope'''
|
||||
| Instruction
|
||||
|-
|
||||
| '''Status'''
|
||||
| Enabled
|
||||
|-
|
||||
| '''Severity'''
|
||||
| Warning
|
||||
|-
|
||||
| '''Applicability'''
|
||||
| All
|
||||
|-
|
||||
| '''Score'''
|
||||
| 70
|
||||
|}
|
||||
|
||||
|
||||
=Example of violation=
|
||||
<e>a := a
|
||||
</e>
|
||||
|
||||
=Recommendation=
|
||||
Replace left or right side with something else than the other element.
|
||||
|
||||
In the example, replace one of the '''<e>a</e>''' by something else.
|
||||
|
||||
{{SeeAlso| [[CA071 - Self-comparison]]}}
|
||||
|
||||
@@ -0,0 +1,37 @@
|
||||
[[Property:title|CA002 - Unused argument]]
|
||||
[[Property:link_title|CA002]]
|
||||
[[Property:weight|0]]
|
||||
[[Property:uuid|fc2cf9c2-76b5-5d2f-4d60-c8dfbc677427]]
|
||||
__NOTOC__
|
||||
=Description=
|
||||
A feature should only have arguments which are actually needed and used in the computation.
|
||||
:{| class="doctable"
|
||||
|-
|
||||
| '''Scope'''
|
||||
| Feature
|
||||
|-
|
||||
| '''Status'''
|
||||
| Disabled
|
||||
|-
|
||||
| '''Severity'''
|
||||
| Warning
|
||||
|-
|
||||
| '''Applicability'''
|
||||
| All
|
||||
|-
|
||||
| '''Score'''
|
||||
| 40
|
||||
|}
|
||||
|
||||
|
||||
=Example of violation=
|
||||
<e>square (x, y: INTEGER): INTEGER
|
||||
do
|
||||
Result := x * 2
|
||||
end</e>
|
||||
|
||||
=Recommendation=
|
||||
Remove argument and update callers.
|
||||
|
||||
In the example, remove the argument '''<e>y</e>''' from the argument list.
|
||||
|
||||
@@ -0,0 +1,33 @@
|
||||
[[Property:title|CA003 - Feature never called]]
|
||||
[[Property:link_title|CA003]]
|
||||
[[Property:weight|0]]
|
||||
[[Property:uuid|21e52517-beb3-9843-8c39-dd0c8e11e945]]
|
||||
__NOTOC__
|
||||
=Description=
|
||||
There is no use for a feature that is never called by any class (including the one where it is defined).
|
||||
:{| class="doctable"
|
||||
|-
|
||||
| '''Scope'''
|
||||
| System
|
||||
|-
|
||||
| '''Status'''
|
||||
| Disabled
|
||||
|-
|
||||
| '''Severity'''
|
||||
| Warning
|
||||
|-
|
||||
| '''Applicability'''
|
||||
| Non-library
|
||||
|-
|
||||
| '''Score'''
|
||||
| 40
|
||||
|}
|
||||
|
||||
|
||||
=Example of violation=
|
||||
A feature defined in the system but never called.
|
||||
|
||||
=Recommendation=
|
||||
Remove feature from the system.
|
||||
|
||||
|
||||
@@ -0,0 +1,55 @@
|
||||
[[Property:title|CA004 - Command-Query Separation]]
|
||||
[[Property:link_title|CA004]]
|
||||
[[Property:weight|0]]
|
||||
[[Property:uuid|7d58b7d3-e7e5-d3ec-83c8-84fca33bf638]]
|
||||
__NOTOC__
|
||||
=Description=
|
||||
A function should never change the state of an object. A function containing a procedure call, an assignment to an attribute, or creating an attribute is a strong indication that this principle is violated. This rule applies exactly in these three cases.
|
||||
|
||||
There are rather exceptional but sometimes useful class designs in which the externally visible state of an object (i. e. the values of exported queries) does not change even though the function contains a rule-violating instruction.
|
||||
|
||||
:{| class="doctable"
|
||||
|-
|
||||
| '''Scope'''
|
||||
| Class
|
||||
|-
|
||||
| '''Status'''
|
||||
| Enabled
|
||||
|-
|
||||
| '''Severity'''
|
||||
| Warning
|
||||
|-
|
||||
| '''Applicability'''
|
||||
| All
|
||||
|-
|
||||
| '''Score'''
|
||||
| 60
|
||||
|}
|
||||
|
||||
|
||||
=Example of violation=
|
||||
<eiffel>
|
||||
height: INTEGER
|
||||
-- Height in pixel of Current.
|
||||
|
||||
width: INTEGER
|
||||
-- Width in pixel of Current.
|
||||
do
|
||||
height := height + 10
|
||||
Result := 100 - height
|
||||
end</eiffel>
|
||||
|
||||
=Recommendation=
|
||||
Ensures that no query changes the state of the current object.
|
||||
|
||||
In the example, one could replace the routine `width` by an attribute and calling `update_width` before querying `width` where `update_width` would be:
|
||||
<eiffel>update_width
|
||||
-- Update `height' and `width' with ....
|
||||
do
|
||||
height := height + 10
|
||||
width := 100 - height
|
||||
end</eiffel>
|
||||
|
||||
Or you can remove the line `height := height + 10` from the body of `width`.
|
||||
|
||||
|
||||
@@ -0,0 +1,49 @@
|
||||
[[Property:title|CA005 - Useless object test local]]
|
||||
[[Property:link_title|CA005]]
|
||||
[[Property:weight|0]]
|
||||
[[Property:uuid|56a54ef0-48e8-b58f-ac2c-09074782b9f7]]
|
||||
__NOTOC__
|
||||
=Description=
|
||||
For local variables and feature arguments it is unnecessary to use an object test to check their attachment status.
|
||||
|
||||
:{| class="doctable"
|
||||
|-
|
||||
| '''Scope'''
|
||||
| feature
|
||||
|-
|
||||
| '''Status'''
|
||||
| Enabled
|
||||
|-
|
||||
| '''Severity'''
|
||||
| Suggestion
|
||||
|-
|
||||
| '''Applicability'''
|
||||
| All
|
||||
|-
|
||||
| '''Score'''
|
||||
| 40
|
||||
|}
|
||||
|
||||
|
||||
=Example of violation=
|
||||
<e>if attached a_local as another_local then
|
||||
another_local.do_something
|
||||
end
|
||||
</e>
|
||||
|
||||
=Recommendation=
|
||||
Remove the object test local, or replace the object test and use a comparison to <e>Void</e>.
|
||||
|
||||
In the example, it can simply be:
|
||||
<e>if attached a_local then
|
||||
a_local.do_something
|
||||
end
|
||||
</e>
|
||||
|
||||
or
|
||||
|
||||
<e>if a_local /= Void then
|
||||
a_local.do_something
|
||||
end
|
||||
</e>
|
||||
|
||||
@@ -0,0 +1,44 @@
|
||||
[[Property:title|CA006 - Object test typing not needed]]
|
||||
[[Property:link_title|CA006]]
|
||||
[[Property:weight|0]]
|
||||
[[Property:uuid|32d6e539-9565-14c2-31b1-5a947a6841f9]]
|
||||
__NOTOC__
|
||||
=Description=
|
||||
In an object test if the expression conforms to the specified type, that type is redundant.
|
||||
|
||||
:{| class="doctable"
|
||||
|-
|
||||
| '''Scope'''
|
||||
| feature
|
||||
|-
|
||||
| '''Status'''
|
||||
| Enabled
|
||||
|-
|
||||
| '''Severity'''
|
||||
| Suggestion
|
||||
|-
|
||||
| '''Applicability'''
|
||||
| All
|
||||
|-
|
||||
| '''Score'''
|
||||
| 40
|
||||
|}
|
||||
|
||||
|
||||
=Example of violation=
|
||||
<e>s: STRING_32
|
||||
...
|
||||
if attached {READABLE_STRING_GENERAL} s as l_s then
|
||||
l_s.do_something
|
||||
end
|
||||
</e>
|
||||
|
||||
=Recommendation=
|
||||
Remove the specified type in the object test.
|
||||
|
||||
In the example, it can simply be:
|
||||
<e>if attached s as l_sl then
|
||||
l_s.do_something
|
||||
end
|
||||
</e>
|
||||
|
||||
@@ -0,0 +1,59 @@
|
||||
[[Property:title|CA010 - High complexity of nested branches and loops]]
|
||||
[[Property:link_title|CA010]]
|
||||
[[Property:weight|0]]
|
||||
[[Property:uuid|8b9aeeae-19cb-c0ce-4de9-ba3b0bbd7dca]]
|
||||
__NOTOC__
|
||||
=Description=
|
||||
When the number of nested branches or loops increases, the source code is less readable. This warning is controlled by a complexity threshold preference.
|
||||
|
||||
:{| class="doctable"
|
||||
|-
|
||||
| '''Scope'''
|
||||
| feature
|
||||
|-
|
||||
| '''Status'''
|
||||
| Enabled
|
||||
|-
|
||||
| '''Severity'''
|
||||
| Suggestion
|
||||
|-
|
||||
| '''Applicability'''
|
||||
| All
|
||||
|-
|
||||
| '''Score'''
|
||||
| 60
|
||||
|-
|
||||
| '''Complexity threshold'''
|
||||
| 5
|
||||
|}
|
||||
|
||||
|
||||
=Example of violation=
|
||||
<e>if a > 0 then
|
||||
from j = 1 until j >= s loop
|
||||
from k = 7 until k < 0 loop
|
||||
if enable_check = True then
|
||||
foo (k, j-1)
|
||||
if log_level = 3 then
|
||||
foobar
|
||||
end
|
||||
else
|
||||
bar (2 * j)
|
||||
end
|
||||
k := k - 1
|
||||
end
|
||||
j := j + 1
|
||||
end
|
||||
end
|
||||
</e>
|
||||
|
||||
=Recommendation=
|
||||
Encapsulate some of the inner branches or loops into a reusable routine.
|
||||
|
||||
In the example, it can simply be:
|
||||
<e>if attached a_local then
|
||||
a_local.do_something
|
||||
end
|
||||
</e>
|
||||
|
||||
|
||||
@@ -0,0 +1,45 @@
|
||||
[[Property:title|CA011 - Too many arguments]]
|
||||
[[Property:link_title|CA011]]
|
||||
[[Property:weight|0]]
|
||||
[[Property:uuid|d25e2dc7-7a95-c13a-bfa2-ceb42a084fa6]]
|
||||
__NOTOC__
|
||||
=Description=
|
||||
A feature that has too many arguments should be avoided since it makes the class interface complicated and is not easy to use. The feature arguments may include options, which should be considered to be moved to separate features.
|
||||
|
||||
:{| class="doctable"
|
||||
|-
|
||||
| '''Scope'''
|
||||
| feature
|
||||
|-
|
||||
| '''Status'''
|
||||
| Enabled
|
||||
|-
|
||||
| '''Severity'''
|
||||
| Warning
|
||||
|-
|
||||
| '''Applicability'''
|
||||
| All
|
||||
|-
|
||||
| '''Score'''
|
||||
| 50
|
||||
|-
|
||||
| '''Arguments threashold'''
|
||||
| 4
|
||||
|}
|
||||
|
||||
|
||||
=Example of violation=
|
||||
<e>my_document.print (printer_name, paper_size, postscript_level, print_resolution)
|
||||
</e>
|
||||
|
||||
=Recommendation=
|
||||
Detect arguments that are really options and create procedures to set them.
|
||||
|
||||
In the example, one could write:
|
||||
<e>
|
||||
my_document.set_paper_size (paper_size)
|
||||
my_document.set_postscript_level (postscript_level)
|
||||
my_document.set_print_resolution (print_resolution)
|
||||
my_document.print (printer_name)
|
||||
</e>
|
||||
|
||||
@@ -0,0 +1,61 @@
|
||||
[[Property:title|CA013 - Exported creation procedure]]
|
||||
[[Property:link_title|CA013]]
|
||||
[[Property:weight|0]]
|
||||
[[Property:uuid|26455914-3b04-cacc-67bb-cd8e083ce947]]
|
||||
__NOTOC__
|
||||
=Description=
|
||||
If acreation procedure is exported then it may be called by clients after the object has been created. Usually, this is not intended. A client might, for example, by accident call <e>x.make</e> instead of <e>create x.make</e>, possibly causing a class invariant or postcondition to not hold anymore.
|
||||
|
||||
:{| class="doctable"
|
||||
|-
|
||||
| '''Scope'''
|
||||
| class
|
||||
|-
|
||||
| '''Status'''
|
||||
| Enabled
|
||||
|-
|
||||
| '''Severity'''
|
||||
| Warning
|
||||
|-
|
||||
| '''Applicability'''
|
||||
| All
|
||||
|-
|
||||
| '''Score'''
|
||||
| 50
|
||||
|}
|
||||
|
||||
|
||||
=Example of violation=
|
||||
<e>class TEST
|
||||
create
|
||||
make
|
||||
feature -- Initialization
|
||||
make
|
||||
-- Initialize Current
|
||||
do
|
||||
end
|
||||
update
|
||||
do
|
||||
end
|
||||
end
|
||||
</e>
|
||||
|
||||
=Recommendation=
|
||||
Make sure to export the creation procedure to NONE.
|
||||
|
||||
In the example, add the export to NONE after the feature clause:
|
||||
<e>class TEST
|
||||
create
|
||||
make
|
||||
feature {NONE} -- Initialization
|
||||
make
|
||||
-- Initialize Current
|
||||
do
|
||||
end
|
||||
feature -- Initialization
|
||||
update
|
||||
do
|
||||
end
|
||||
end
|
||||
</e>
|
||||
|
||||
@@ -0,0 +1,40 @@
|
||||
[[Property:title|CA017 - Empty conditional]]
|
||||
[[Property:link_title|CA017]]
|
||||
[[Property:weight|0]]
|
||||
[[Property:uuid|4616cef3-6eaf-1ab6-6071-d629443dfbf0]]
|
||||
__NOTOC__
|
||||
=Description=
|
||||
An empty conditional instruction is useless and should be removed.
|
||||
|
||||
:{| class="doctable"
|
||||
|-
|
||||
| '''Scope'''
|
||||
| Instruction
|
||||
|-
|
||||
| '''Status'''
|
||||
| Enabled
|
||||
|-
|
||||
| '''Severity'''
|
||||
| Warning
|
||||
|-
|
||||
| '''Applicability'''
|
||||
| All
|
||||
|-
|
||||
| '''Score'''
|
||||
| 50
|
||||
|}
|
||||
|
||||
|
||||
=Example of violation=
|
||||
<e>if x and y then
|
||||
end
|
||||
do_something_else
|
||||
</e>
|
||||
|
||||
=Recommendation=
|
||||
Remove the useless conditional.
|
||||
In the example, simply keep:
|
||||
|
||||
<e>
|
||||
do_something_else</e>
|
||||
|
||||
@@ -0,0 +1,54 @@
|
||||
[[Property:title|CA020 - Variable not read after assignment]]
|
||||
[[Property:link_title|CA020]]
|
||||
[[Property:weight|0]]
|
||||
[[Property:uuid|8de22b33-be9c-b946-ce39-709cf42f01c5]]
|
||||
__NOTOC__
|
||||
=Description=
|
||||
An assignment to a local variable has not effect at all if the variable is not read after the assignment, or reassigned.
|
||||
{| class="doctable"
|
||||
|-
|
||||
| '''Scope'''
|
||||
| Instruction
|
||||
|-
|
||||
| '''Status'''
|
||||
| Enabled
|
||||
|-
|
||||
| '''Severity'''
|
||||
| Warning
|
||||
|-
|
||||
| '''Applicability'''
|
||||
| All
|
||||
|-
|
||||
| '''Score'''
|
||||
| 70
|
||||
|}
|
||||
|
||||
|
||||
=Example of violation=
|
||||
<e>
|
||||
local
|
||||
x, y: INTEGER
|
||||
do
|
||||
x := 3
|
||||
y := some_height_query
|
||||
x := some_width_query
|
||||
...
|
||||
end
|
||||
</e>
|
||||
|
||||
=Recommendation=
|
||||
Remove the assignment without effect.
|
||||
|
||||
In the example, remove the first assignment to <e>x</e>:
|
||||
<e>
|
||||
local
|
||||
x, y: INTEGER
|
||||
do
|
||||
y := some_height_query
|
||||
x := some_width_query
|
||||
...
|
||||
end
|
||||
</e>
|
||||
|
||||
{{SeeAlso | [[CA071 - Self-comparison]]}}
|
||||
|
||||
@@ -0,0 +1,43 @@
|
||||
[[Property:title|CA023 - Unneeded parentheses]]
|
||||
[[Property:link_title|CA023]]
|
||||
[[Property:weight|0]]
|
||||
[[Property:uuid|9af7b35f-7e74-2bd1-8680-b59ab81d6791]]
|
||||
__NOTOC__
|
||||
=Description=
|
||||
Parentheses that are not needed should be removed. This helps enforcing a consistent coding style
|
||||
:{| class="doctable"
|
||||
|-
|
||||
| '''Scope'''
|
||||
| Instruction
|
||||
|-
|
||||
| '''Status'''
|
||||
| Enabled
|
||||
|-
|
||||
| '''Severity'''
|
||||
| Suggestion
|
||||
|-
|
||||
| '''Applicability'''
|
||||
| All
|
||||
|-
|
||||
| '''Score'''
|
||||
| 30
|
||||
|}
|
||||
|
||||
|
||||
=Example of violation=
|
||||
<e>if (z > 3) then
|
||||
z := (z - 5)
|
||||
end
|
||||
</e>
|
||||
|
||||
=Recommendation=
|
||||
Remove the parenthesis that are not needed.
|
||||
|
||||
In the example, it simply becomes:
|
||||
<e>if z > 3 then
|
||||
z := z - 5
|
||||
end
|
||||
</e>
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,45 @@
|
||||
[[Property:title|CA024 - Use across loop]]
|
||||
[[Property:link_title|CA024]]
|
||||
[[Property:weight|0]]
|
||||
[[Property:uuid|d24ebe87-3a57-105e-7900-e77608cac47c]]
|
||||
__NOTOC__
|
||||
=Description=
|
||||
When iterating on an instance of <e>ITERABLE</e> with a traditional <e>from ... until ... loop ...end</e> from beginning to end you should use an across loop to avoid forgetting to advance the cursor.
|
||||
:{| class="doctable"
|
||||
|-
|
||||
| '''Scope'''
|
||||
| Instruction
|
||||
|-
|
||||
| '''Status'''
|
||||
| Enabled
|
||||
|-
|
||||
| '''Severity'''
|
||||
| Suggestion
|
||||
|-
|
||||
| '''Applicability'''
|
||||
| All
|
||||
|-
|
||||
| '''Score'''
|
||||
| 30
|
||||
|}
|
||||
|
||||
|
||||
=Example of violation=
|
||||
<e>from
|
||||
list.start
|
||||
until
|
||||
list.after
|
||||
loop
|
||||
...
|
||||
list.forth
|
||||
end
|
||||
</e>
|
||||
|
||||
=Recommendation=
|
||||
Replace with an across loop. In the example it becomes:
|
||||
<e>across list as l loop
|
||||
...
|
||||
end
|
||||
</e>
|
||||
|
||||
|
||||
@@ -0,0 +1,40 @@
|
||||
[[Property:title|CA025 - Use semicolons]]
|
||||
[[Property:link_title|CA025]]
|
||||
[[Property:weight|0]]
|
||||
[[Property:uuid|41ec250b-3967-797e-9843-59eab795f391]]
|
||||
__NOTOC__
|
||||
=Description=
|
||||
Routine arguments should be separated with semicolons. Although this is optional, it is not a recommended style to not put semicolons.
|
||||
:{| class="doctable"
|
||||
|-
|
||||
| '''Scope'''
|
||||
| feature
|
||||
|-
|
||||
| '''Status'''
|
||||
| Enabled
|
||||
|-
|
||||
| '''Severity'''
|
||||
| Suggestion
|
||||
|-
|
||||
| '''Applicability'''
|
||||
| All
|
||||
|-
|
||||
| '''Score'''
|
||||
| 40
|
||||
|}
|
||||
|
||||
|
||||
=Example of violation=
|
||||
<e>f (a: INTEGER b: INTEGER)
|
||||
do
|
||||
end
|
||||
</e>
|
||||
|
||||
=Recommendation=
|
||||
Add the missing semicolons between arguments. In the example, it becomes:
|
||||
<e>f (a: INTEGER; b: INTEGER)
|
||||
do
|
||||
end
|
||||
</e>
|
||||
|
||||
|
||||
@@ -0,0 +1,39 @@
|
||||
[[Property:title|CA028 - Combine two if instructions]]
|
||||
[[Property:link_title|CA028]]
|
||||
[[Property:weight|0]]
|
||||
[[Property:uuid|47b9a80f-16d7-82c7-7d23-19f740fb2978]]
|
||||
__NOTOC__
|
||||
=Description=
|
||||
Two nested instructions, both not having an else clause, could be combined into a single if instruction using the <e>and then</e> boolean operator.
|
||||
:{| class="doctable"
|
||||
|-
|
||||
| '''Scope'''
|
||||
| Instruction
|
||||
|-
|
||||
| '''Status'''
|
||||
| Enabled
|
||||
|-
|
||||
| '''Severity'''
|
||||
| Suggestion
|
||||
|-
|
||||
| '''Applicability'''
|
||||
| All
|
||||
|-
|
||||
| '''Score'''
|
||||
| 40
|
||||
|}
|
||||
|
||||
=Example of violation=
|
||||
<e>if user /= Void then
|
||||
if user.age >= 18 then
|
||||
...
|
||||
end
|
||||
end
|
||||
</e>
|
||||
|
||||
=Recommendation=
|
||||
Combine the nested if instructions using <e>and then</e>. In the example, it becomes:
|
||||
<e>if user /= Void and then user.age >= 18 then
|
||||
...
|
||||
end</e>
|
||||
|
||||
@@ -0,0 +1,35 @@
|
||||
[[Property:title|CA032 - Long routine implementation]]
|
||||
[[Property:link_title|CA032]]
|
||||
[[Property:weight|0]]
|
||||
[[Property:uuid|9edb21ce-ab0c-69ea-c494-a39dc7a26b15]]
|
||||
__NOTOC__
|
||||
=Description=
|
||||
A routine implementation that contains many instructions should be shortened to make it easier to understand.
|
||||
:{| class="doctable"
|
||||
|-
|
||||
| '''Scope'''
|
||||
| feature
|
||||
|-
|
||||
| '''Status'''
|
||||
| Enabled
|
||||
|-
|
||||
| '''Severity'''
|
||||
| Warning
|
||||
|-
|
||||
| '''Applicability'''
|
||||
| All
|
||||
|-
|
||||
| '''Score'''
|
||||
| 70
|
||||
|-
|
||||
| '''Instructions threshold'''
|
||||
| 70
|
||||
|}
|
||||
|
||||
|
||||
=Example of violation=
|
||||
A routine with many lines of code.
|
||||
|
||||
=Recommendation=
|
||||
Decompose the routine by creating new routines that will be used in the original long routine.
|
||||
|
||||
@@ -0,0 +1,39 @@
|
||||
[[Property:title|CA033 - Large class]]
|
||||
[[Property:link_title|CA033]]
|
||||
[[Property:weight|0]]
|
||||
[[Property:uuid|93aaff4c-3406-311e-3760-facad969131e]]
|
||||
__NOTOC__
|
||||
=Description=
|
||||
A large class declaration might not be ideal for readability. Consider moving out features that are not really part of the class.
|
||||
:{| class="doctable"
|
||||
|-
|
||||
| '''Scope'''
|
||||
| class
|
||||
|-
|
||||
| '''Status'''
|
||||
| Enabled
|
||||
|-
|
||||
| '''Severity'''
|
||||
| Warning
|
||||
|-
|
||||
| '''Applicability'''
|
||||
| All
|
||||
|-
|
||||
| '''Score'''
|
||||
| 60
|
||||
|-
|
||||
| '''Features threshold'''
|
||||
| 20
|
||||
|-
|
||||
| '''Instructions threshold'''
|
||||
| 300
|
||||
|}
|
||||
|
||||
|
||||
=Example of violation=
|
||||
A class with too many routines or too many instructions.
|
||||
|
||||
=Recommendation=
|
||||
Refactor the class to reduce the number of routines or instructions.
|
||||
|
||||
|
||||
@@ -0,0 +1,35 @@
|
||||
[[Property:title|CA034 - High NPATH complexity]]
|
||||
[[Property:link_title|CA034]]
|
||||
[[Property:weight|0]]
|
||||
[[Property:uuid|f6ffe1e0-2b46-66db-60de-0cdd5c42f453]]
|
||||
__NOTOC__
|
||||
=Description=
|
||||
NPATH is the number of acyclic execution paths through a routine. A routine's NPATH complexity should not be too high. In order to reduce the NPATH complexity one can move some functionality to separate routines.
|
||||
:{| class="doctable"
|
||||
|-
|
||||
| '''Scope'''
|
||||
| Feature
|
||||
|-
|
||||
| '''Status'''
|
||||
| Enabled
|
||||
|-
|
||||
| '''Severity'''
|
||||
| Warning
|
||||
|-
|
||||
| '''Applicability'''
|
||||
| All
|
||||
|-
|
||||
| '''Score'''
|
||||
| 60
|
||||
|-
|
||||
| '''NPATH complexity threshold'''
|
||||
| 200
|
||||
|}
|
||||
|
||||
|
||||
=Example of violation=
|
||||
|
||||
=Recommendation=
|
||||
Reduce complexity of routine by refactoring parts of the routine into their own routines.
|
||||
|
||||
|
||||
@@ -0,0 +1,38 @@
|
||||
[[Property:title|CA071 - Self-comparison]]
|
||||
[[Property:link_title|CA071]]
|
||||
[[Property:weight|0]]
|
||||
[[Property:uuid|02a649b3-0e4e-6fdf-388d-c411a06fc787]]
|
||||
__NOTOC__
|
||||
=Description=
|
||||
An expression comparing a variable to itself always evaluates to the same boolean value. The comparison is thus redundant. In an Until expression it may lead to non-termination. Usually it is a typing error.
|
||||
:{| class="doctable"
|
||||
|-
|
||||
| '''Scope'''
|
||||
| Instruction
|
||||
|-
|
||||
| '''Status'''
|
||||
| Enabled
|
||||
|-
|
||||
| '''Severity'''
|
||||
| Warning
|
||||
|-
|
||||
| '''Applicability'''
|
||||
| All
|
||||
|-
|
||||
| '''Score'''
|
||||
| 70
|
||||
|}
|
||||
|
||||
|
||||
=Example of violation=
|
||||
<e>if a >= a then
|
||||
...
|
||||
end</e>
|
||||
|
||||
=Recommendation=
|
||||
Replace left or right side of comparison with something else than the other element.
|
||||
|
||||
In the example, replace '''<e>a</e>''' by something else.
|
||||
|
||||
{{SeeAlso| [[CA001 - Self Assignment]]}}
|
||||
|
||||
@@ -0,0 +1,15 @@
|
||||
[[Property:modification_date|Mon, 24 Dec 2018 07:54:57 GMT]]
|
||||
[[Property:publication_date|Mon, 24 Dec 2018 07:54:57 GMT]]
|
||||
[[Property:title|Code Analyzer: Rules]]
|
||||
[[Property:link_title|Rules]]
|
||||
[[Property:weight|15]]
|
||||
[[Property:uuid|109ca62a-212d-8a85-eea8-ddf0f89177a1]]
|
||||
For each rule, you will find an English description of the purpose of the rule, followed by a table providing the following information:
|
||||
* Scope: Instruction/
|
||||
* Status: Enabled/Disabled by default
|
||||
* Severity: Warning/Error
|
||||
* Applicability: All
|
||||
* Score: Value used to
|
||||
|
||||
In addition you will find an example for a rule violation as well as a suggested fix when available.
|
||||
|
||||
@@ -0,0 +1,71 @@
|
||||
[[Property:modification_date|Mon, 24 Dec 2018 07:41:32 GMT]]
|
||||
[[Property:publication_date|Mon, 24 Dec 2018 07:41:32 GMT]]
|
||||
[[Property:title|Running the Code Analyzer]]
|
||||
[[Property:link_title|Running the Analyzer]]
|
||||
[[Property:weight|-14]]
|
||||
[[Property:uuid|d672c769-57fb-6b87-2781-83daff3ab9e7]]
|
||||
= General =
|
||||
|
||||
There are several different ways of running the Code Analyzer. Most importantly, you can select the scope of the analysis. For example it is possible to analyze a single class, a cluster or a whole system. Also for the same scope there are different ways of running the analyzer depending on your personal preferences. To perform the analysis the Eiffel system which will be analyzed must compile without any error.
|
||||
|
||||
There are two ways of running the Code Analyzer
|
||||
# Using the GUI, the Code Analyzer Tool appears as a panel. The panel is mainly used for displaying analysis results. The command to perform the analysis can be found not only in the panel but also in various context menus making it easy to analyze specific classes or sets of classes.
|
||||
# Using command-line arguments with the command-line version of EiffelStudio. The system is compiled (if necessary) and then analyzed. The output of the analysis will be directed to the terminal window.
|
||||
|
||||
= GUI =
|
||||
== Analyzing the System ==
|
||||
|
||||
If you want to analyze the whole system of the currently open project press the '''Analyze System''' button in the toolbar. Every compiled classes of the system will be analyzed.
|
||||
[[Image:CA Analysis Buttons|center|368px|Analyze System]]
|
||||
|
||||
|
||||
== Analyzing a Class or Group ==
|
||||
|
||||
=== Current Class ===
|
||||
Left-clicking the '''Analyze Item''' button in the toolbar will start an analysis of the class that is currently opened in the editor.
|
||||
[[Image:CA Analysis Buttons|center|368px|Analyze Item]]
|
||||
|
||||
=== Any Class ===
|
||||
There are two ways of analyzing an arbitrary class (either from your system or from a library):
|
||||
* Right-click on a class name and select '''Analyze Class...''' from the context menu:
|
||||
[[Image:CA Class Context Menu|center|371px|Class Context Menu]]
|
||||
* Pick a class and drop it on the '''Analyze Item''' button.
|
||||
|
||||
=== Clusters ===
|
||||
To analyze a cluster there are two possibilities, like for classes:
|
||||
* You can either right-click the cluster and select '''Analyze cluster''' from the context menu:
|
||||
[[Image:CA Cluster Context Menu|center|247px|Cluster Context Menu]]
|
||||
* Pick a cluster and drop it on the '''Analyze Item''' button.
|
||||
|
||||
=== Others ===
|
||||
Not only clusters but any other elements of a project (such as a library) can be analyzed by pick-and-dropping it on the '''Analyze Item''' button in the panel.
|
||||
|
||||
|
||||
=Command Line=
|
||||
The Code Analyzer is also available from the EiffelStudio command line compiler by using the '''-code-analysis''' command. The results will be displayed in the terminal window or to a file.
|
||||
|
||||
== Execution / Command Line Options ==
|
||||
|
||||
The following command will perform a code analysis:
|
||||
|
||||
ec.exe -config project.ecf -code-analysis [-cadefaults] [-caloadprefs ''preffile''] [-caclass ''CLASS1 CLASS2 ...'']
|
||||
[-caforcerules "RULE1 (First preference=1, Second preference=2) RULE2"]
|
||||
|
||||
The arguments in brackets are optional. For a complete description of the Code Analyzer command line options see [[EiffelStudio: Using command line options|Using command line compiler options]].
|
||||
|
||||
EiffelStudio will try to compile the system if needed. The analysis will only work with syntactically correct code and a compiled system. Should the compilation fail, EiffelStudio will abort and the analysis will not start.
|
||||
|
||||
== Output ==
|
||||
Upon a successful compilation either the whole system or the classes mentioned in the arguments will be analyzed. The class that is currently being analyzed will be displayed so that the user can follow the progress.
|
||||
|
||||
As soon as everything needed has been analyzed the results will be displayed as a list of rule violations. These rule violations are sorted by class and by location. In addition to the name of the violated rule and the rule ID, a description of the concrete violation will be displayed as well.
|
||||
|
||||
[[Image:Eiffel Inspector Command Line|center|877px|Code Analyzer - Command Line]]
|
||||
|
||||
=== Output to file ===
|
||||
|
||||
Appending "> ''filename''" to the command above will redirect the output to a text file.
|
||||
In addition, a file '''last_analysis_result.csv''' will be saved in the 'EIFGENs/target' directory, with the same content as '''filename''', that can be processed by a spreadsheet tool.
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,8 @@
|
||||
[[Property:modification_date|Wed, 04 Jul 2018 11:29:56 GMT]]
|
||||
[[Property:publication_date|Wed, 04 Jul 2018 09:35:31 GMT]]
|
||||
[[Property:title|Code Analyzer]]
|
||||
[[Property:weight|-8]]
|
||||
[[Property:uuid|3d9edb08-a7dd-7df9-2b1e-b5c30add6529]]
|
||||
The Code Analyzer is a static analyzer that helps maintaining a high code quality. It is capable of detecting many different kinds of issues in the source code. These issues relate to possibly dangerous run-time behavior, performance problems, coding style, and more.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user