View source for CA Adding New Rules

You do not have permission to edit this page, for the following reasons:
The action you have requested is limited to users in one of the groups: Autoconfirmed users, emailconfirmed, editors.
You must confirm your email address before editing pages. Please set and validate your email address through your user preferences.
You can view and copy the source of this page:
<center><small>[[User:Stefan/Code Analysis/Command Line Usage|&lt;&lt; 5. Command Line Usage]] | [[User:Stefan/Code Analysis/Architectural Overview|7. Architectural Overview &gt;&gt;]] </small></center>
----
<br />
The Code Analysis framework was designed with regard to the fact that '''adding new rules''' should be as simple and as fast as possible. Looking at the initial set of rules that were implemented, nearly all of them have an implementation of less than 200 lines of code. Many of them use even less than 100 lines of code. Rules that search the code for certain patterns (this applies to the vast majority of rules) are particularly simple to implement.

== Standard Rules ==

All rules must conform to <e>CA_RULE</e>. The class you implement for a rule is on one hand responsible for checking the rule and contains metadata about the rule (i. e. title, description) on the other hand. As of now, rules must moreover conform to either <e>CA_STANDARD_RULE</e> or <e>CA_CFG_RULE</e>, both of which are subtypes of <e>CA_RULE</e>. A large number of possible rules are '''standard rules''', no matter whether they are trivial or more complicated.

All ''Standard rules'' are checked by iterating on the [http://en.wikipedia.org/wiki/Abstract_syntax_tree abstract syntax tree] (AST) of the class code. The developer who adds a new rule can very well ignore the details thereof. He needs to know however which AST nodes his rule needs to process. For each type of AST node you need to add an agent so your routine will be called during the iteration on the AST.

To start implementing your rule you have basically two possibilities. (1) You start from scratch, implementing all deferred features of <e>CA_STANDARD_RULE</e> or (2) you use the following template.

=== Standard Rule Template ===

<e>
class
  CA_YOUR_RULE

inherit
  CA_STANDARD_RULE

create
  make

feature {NONE} -- Initialization

  make (a_pref_manager: attached PREFERENCE_MANAGER)
      -- Initialization for `Current'.
    do
      make_with_defaults
        -- This initializes the attributes to their default values:
        -- Severity = warning
        -- Default Severity Score = 50 (`severity score' can be changed by user)
        -- Rule enabled by default = True (`Rule enabled' can be changed by user)
        -- Only for system wide checks = False
        -- Checks library classes = True
        -- Checks nonlibrary classes = True

        initialize_options (a_pref_manager)

        -- TODO: Add your initialization here.
    end

  initialize_options (a_pref_manager: attached PREFERENCE_MANAGER)
      -- Initializes the rule preferences.
    local
      l_factory: BASIC_PREFERENCE_FACTORY
    do
      create l_factory
     
        -- TODO: Add the initialization of your custom preferences here.
        -- Example:
--    threshold := l_factory.new_integer_preference_value (a_pref_manager,
--      preference_namespace + "Threshold",
--      30)  -- default value
--    min_local_name_length.set_default_value ("30") -- default value, too
--    min_local_name_length.set_validation_agent (agent is_integer_string_within_bounds (?, 1, 1_000_000))
    end

feature {NONE} -- Activation

  register_actions (a_checker: attached CA_ALL_RULES_CHECKER)
    do
      -- TODO: Add agents for the features in section `Rule checking' here.
    end

feature {NONE} -- Rule checking

  -- TODO: Add the AST processing here.

feature -- Properties

  title: STRING_32
    do
        -- TODO: Add the title of your rule here.
      Result := "(Your title)"
    end

    -- TODO: Add the ID of your rule here. Should be unique!
  id: STRING_32 = "(YourID)"

  description: STRING_32
    do
        -- TODO: Add the rule description here.
      Result :=  "(Your description)"
    end

  format_violation_description (a_violation: attached CA_RULE_VIOLATION; a_formatter: attached TEXT_FORMATTER)
    do
      -- TODO: Add a formatted description of a concrete violation of this rule here.
    end

end
</e>

Let us have a closer look at the various parts of a rule class.

=== Initialization ===

Calling <e>make_with_defaults</e> initializes the attributes to their default values and makes sure that the class invariant is true. If you want to set an attribute to a custom value you can do so by setting it after the call to <e>make_with_defaults</e>.

The creation procedure from the template takes an argument of type <e>PREFERENCE_MANAGER</e>. This is used for initializing preferences that are specific to your rule. Such preferences usually represent integral or boolean values. If you do ''not'' need any custom preferences then you can leave out the argument ''a_pref_manager'' of ''make'' and you can remove the whole <e>initialize_options</e> feature.

=== AST processing ===

The main part of your rule implementation consists of checking the source code for rule violations. Say, for example, that you want to check <e>if</e> instructions to have certain properties. Then you would add a feature like <e>process_if (a_if_ast: IF_AS)</e> to the section ''Rule checking''. Also, you would need to modify the <e>register_actions</e> feature by adding the line

<e>a_checker.add_if_pre_action (agent process_if)</e>.

Of course you may register as many such agents as you want.

=== Properties ===

=== Formatted Violation Description ===

== More Customized Rules ==

== Accessing Type Information ==

== Accessing the Control Flow Graph ==
Return to CA Adding New Rules.
Retrieved from "https://dev.eiffel.com/CA_Adding_New_Rules"
View source for CA Adding New Rules

Navigation

Development

Wiki

Search

Tools
