sanger/sequencescape

Class variables form part of the global runtime state, and as such make it easy for one part of the system to accidentally or inadvertently depend on another part of the system. So the system becomes more prone to problems where changing something over here breaks something over there. In particular, class variables can make it hard to set up tests (because the context of the test includes all global state).

For a detailed explanation, check out this article

Example

Given

class Dummy
  @@class_variable = :whatever
end

Reek would emit the following warning:

reek test.rb

test.rb -- 1 warning:
  [2]:Dummy declares the class variable @@class_variable (ClassVariable)

Getting rid of the smell

You can use class-instance variable to mitigate the problem (as also suggested in the linked article above):

class Dummy
  @class_variable = :whatever
end

Classes and modules are the units of reuse and release. It is therefore considered good practice to annotate every class and module with a brief comment outlining its responsibilities.

Example

Given

class Dummy
  # Do things...
end

Reek would emit the following warning:

test.rb -- 1 warning:
  [1]:Dummy has no descriptive comment (IrresponsibleModule)

Fixing this is simple - just an explaining comment:

# The Dummy class is responsible for ...
class Dummy
  # Do things...
end

Class variables form part of the global runtime state, and as such make it easy for one part of the system to accidentally or inadvertently depend on another part of the system. So the system becomes more prone to problems where changing something over here breaks something over there. In particular, class variables can make it hard to set up tests (because the context of the test includes all global state).

For a detailed explanation, check out this article

Example

Given

class Dummy
  @@class_variable = :whatever
end

Reek would emit the following warning:

reek test.rb

test.rb -- 1 warning:
  [2]:Dummy declares the class variable @@class_variable (ClassVariable)

Getting rid of the smell

You can use class-instance variable to mitigate the problem (as also suggested in the linked article above):

class Dummy
  @class_variable = :whatever
end

Duplicated Code

Duplicated code can lead to software that is hard to understand and difficult to change. The Don't Repeat Yourself (DRY) principle states:

Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

When you violate DRY, bugs and maintenance problems are sure to follow. Duplicated code has a tendency to both continue to replicate and also to diverge (leaving bugs as two similar implementations differ in subtle ways).

Tuning

This issue has a mass of 46.

We set useful threshold defaults for the languages we support but you may want to adjust these settings based on your project guidelines.

The threshold configuration represents the minimum mass a code block must have to be analyzed for duplication. The lower the threshold, the more fine-grained the comparison.

If the engine is too easily reporting duplication, try raising the threshold. If you suspect that the engine isn't catching enough duplication, try lowering the threshold. The best setting tends to differ from language to language.

See codeclimate-duplication's documentation for more information about tuning the mass threshold in your .codeclimate.yml.

Refactorings

• Extract Method
• Extract Class
• Form Template Method
• Introduce Null Object
• Pull Up Method
• Pull Up Field
• Substitute Algorithm

Further Reading

• Don't Repeat Yourself on the C2 Wiki
• Duplicated Code on SourceMaking
• Refactoring: Improving the Design of Existing Code by Martin Fowler. Duplicated Code, p76