Would be nice to be able to disable smells for specific bits of code instead of using the config file. for example...

def my_method #:nosmell[utility_function]
  ...
end

[Raised by S. Brent Faulkner]

(This is a special case of Dead Code.)

For example, the following method reports Feature Envy (I think - I'd have to check). But Utility Function is the most common one that gets reported.

class ProposedQuestion
  class << self
    def new_for_facts_with_format(times_table_facts, question_format)
      times_table_facts.map { |fact| ProposedQuestion.new(:times_table_fact => fact, :question_format => question_format) }
    end
  end
end

New smell detector.

The name Large Class is a hangover from Martin Fowler's original Java smells; in Ruby it should probably be renamed to Large Module.

Add a command-line option that disables all but the named smell. This should be a rake option too.

Currently the default behaviour is to complain about any block that's nested inside another. Add a config option to allow the user to raise this threshhold above 1.

Feature Envy currently applies only to whole methods. It would be great to find a way to have it report a block, or the else-clause of a conditional, or any branch of a switch.

In a Hexagonal Architectural view of an app, the code style in the Adapters is special. So any name matching /Adapter/ should be exempted from certain smells (particularly those related to conditional code).

When I just define a method at the top level in a script, it has no "instance state" to ignore, and will therefore always be a UtilityFunction. Doesn't make sense.

A class has a field that is not set in the constructor, but is used in some method that doesn't also set it.

Or a class provides an attr_writer.

[Raised by Ashley Moran]

Say you have the following config file:

---
FeatureEnvy:
  exclude:
  - view

but the view method that gets analysed does not have Feature Envy. Should this be considered an error? It seems that exclusions could persist after the code smells have been removed, silently ignoring the smell being introduced.

I've done a few refactorings now that removed code smells, and had to remember to manually take them out of the configs.
Similar idea to code coverage failing if your coverage percentage increases on the basis that you want to maintain any improvements you make.

Possibly the sanest behaviour would be to fail if the config is in the same directory as the file affected, so that global excludes don't raise loads of errors.

[Raised originally by dbalatero]

Given an ActiveRecord model with a number of validations and associations added, and no extra methods, the method count can balloon to larger than the max count really fast.

I believe this is because validates*of-type methods in Rails add methods to the class itself, so they don't get seen as separate modules / inherited methods.

Would there be a way to whitelist some of these generated methods?

A bit like a method on a class, the following should presumably not trigger Utility Function?

module MyModule
  def reset!
    # ...
  end
  module_function :reset!
end

Tools such as perlcritic categorise the smells they report with a "severity". Good idea.

The plug-in should mark up source files in the editor view, showing where the smells are.

The plug-in should mark up source files in the editor view, showing where the smells are.

The following method is envious

def func
  @other.a
  @other.b
  @nother.c
end

because it could be moved to @other, creating a method like tthis:

def other.func(me)
  a
  b
  me.nother_c
end

But FeatureEnvy doesn't pick this up.

The following code includes 3 nested assignments, yet none of these contribute to the method's "length":

def parse(arg, argv, &error)
  if !(val = arg) and (argv.empty? or /\A-/ =~ (val = argv[0]))
    return nil, block, nil
  end
  opt = (val = parse_arg(val, &error))[1]
  val = conv_arg(*val)
  if opt and !arg
    argv.shift
  else
    val[0] = nil
  end
  val
end

The metho'ds length is reported as 6, but should be 9.

Add an optino to write a YAML report into an output folder.
(Could look at metric_fu for the report's format?)

I'd like to be able to configure Reek so that, for example, some methods are allowed to have upto 5 parameters, while the rest must keep within the standard 3.

This came up today. We have a file of ugly monkey-patching hacks to workaround framework bugs, and we wanted to turn reek off for this. But we couldn't control the smells on a per-file basis, so we had to put them in one by one.

Being able to configure smells per-file or per-class/module would have made this easier.

WDYT?

For example, it should be a fatal error if the max_allowed_calls setting for Duplication is set to < 2.

Every class and module should have a brief description of its responsibilities in the comments just ahead of its definition

Attempt to detect when a method has been added to a core class.

New smell: More than 8 calls to require in a single source file.

Tools such as metric_fu currently parse Reek's text output. It would be easier for them to load a YAML file produced by Reek. So I propose a new option --format taking one of (initially) three values: none, yaml, or text; the last would produce the current output, and would be the default.

I've had some of this in my code. Good Ruby style says that in the following code,

class Thing
  def do_something
  end

  def do_something!
  end
end

The second, ! method should only exist if the first also does. Is this in the scope of reek? I propose PrimaDonnaMethod as the smell name if so :)

I'm now convinced that the this code pattern is also code smell. Is it something Reek could detect? (If you believe it should be a code smell?)

For example:

class Level1Generator
  def classes(row, col, value)
    (row == 1 || col == 1) ? %w[ header ] : [ ]
  end
end

Gets both smells. Surely it's not informative to report Feature Envy in this case?

Now please try and resist tearing too much into the other smells here :) But I believe this deserves flagging as a Data Clump?

module CellClassGenerator
  class Level1Generator
    def initialize(multiplicand, multiplier)
      @multiplicand = multiplicand
      @multiplier   = multiplier
    end

    def classes(row, col, value)
      (row == 1 || col == 1) ? %w[ header ] : [ ]
    end
  end

  # TODO figure out why this isn't reported as a data clump
  class Level2Generator < Level1Generator
    def classes(row, col, value)
      classes = super
      classes << "highlighted" if col == @multiplicand 
      classes
    end
  end

  class Level3Generator < Level2Generator
    def classes(row, col, value)
      classes = super
      classes << "highlighted" if row == @multiplier
      classes << "answer" if value == @multiplicand * @multiplier && col == @multiplicand
      classes.uniq
    end
  end
end

(You can't see it here, but if we had CellReference, I'm pretty sure some related code in this HTML table generator module would clean up too.)

In the Reek output it normally separates class with ::, and denotes methods with # or . Inside a module it doesn't do that correctly

example: http://github.com/crnixon/wordbadger/blob/6d6a19064e7b51bfd2507117aee41e216379dd5d/app/helpers/application_helper.rb

reports like so http://assets.devver.net/github_crnixon_wordbadger/6d6a19064e7b51bfd2507117aee41e216379dd5d/reek.html

'ApplicationHelper::section_link' which should be 'ApplicationHelper#section_link'

This makes it hard to tell the difference between a class and a method... Obviously lower case names can't be classes, but it seems using the # is more the standard.