Comparing reek reports across projects (eg Caliper)
Ashley Moran
Just a few random thoughts prompted by Reek being on Caliper[1].
Should tools that use reek operate with or without configs? Say I
have to disable some detectors because they are highlighting issues
not deemed worth fixing, should a tool like Caliper respect my configs
or not?
If comparison tools should not respect configs, how would you handle
warnings disabled to work around Reek bugs?
Finally, does Reek generate a metric suitable for higher-level
management of Ruby projects? I mean for example, say you're
overseeing 10 projects, all with Reek on the CI, is Reek output
suitable to highlight projects in need of attention? Or should it
only be used be members of a team to improve their own code?
Cheers
Ashley
--
http://www.patchspace.co.uk/
http://www.linkedin.com/in/ashleymoran
http://aviewfromafar.net/
Kevin Rutherford
On Sat, Oct 10, 2009 at 4:57 PM, Ashley Moran
<ashley...@patchspace.co.uk> wrote:
>
> Should tools that use reek operate with or without configs? Say I
> have to disable some detectors because they are highlighting issues
> not deemed worth fixing, should a tool like Caliper respect my configs
> or not?
Caliper runs metric_fu, which in turn runs the Reek gem. Reek looks
for config files as it is parsing the source; if they're present it
should always apply them. Are you hinting that that's not happening?
If so, you've probably found a bug in Reek.
Assuming configs work as expected, there's another interestiing point
here. I'm about to add a --profile switch, which will set the base
config to one of a set of different profiles. Those profiles will, by
default, be housed in the gem -- which would mean that different tools
could apply different profiles than you're using yourself. Does that
imply that the project needs to house some kind of "master" settings
for Reek? (Maybe a .reekrc file in the root of the examined folders,
to set the default profile? Would .reekrc contain "--profile xp", or
a full YAML config?)
> Finally, does Reek generate a metric suitable for higher-level
> management of Ruby projects? I mean for example, say you're
> overseeing 10 projects, all with Reek on the CI, is Reek output
> suitable to highlight projects in need of attention? Or should it
> only be used be members of a team to improve their own code?
I think of Reek as highly subjective (which is why I'm planning to add
profiles). What smells today might be unimportant tomorrow; and what
is cost-effective to fix today may not be so tomorrow. Etc etc. Blah
blah. I just don't like the idea of comparing teams or codebases, I
guess. use Reek to help you do your own job, and don't worry about any
other teams doing theirs :)
Cheers,
Kevin
--
http://www.kevinrutherford.co.uk -- agile, TDD, XP, lean, TOC
Ashley Moran
On 12 Oct 2009, at 10:40, Kevin Rutherford wrote:
> Caliper runs metric_fu, which in turn runs the Reek gem. Reek looks
> for config files as it is parsing the source; if they're present it
> should always apply them. Are you hinting that that's not happening?
> If so, you've probably found a bug in Reek.
Ah, no, not suggesting that at all. I was just raising questions
about how it should behave.
> Assuming configs work as expected, there's another interestiing point
> here. I'm about to add a --profile switch,
This is what I had at the back of my mind...
> which will set the base
> config to one of a set of different profiles. Those profiles will, by
> default, be housed in the gem -- which would mean that different tools
> could apply different profiles than you're using yourself. Does that
> imply that the project needs to house some kind of "master" settings
> for Reek? (Maybe a .reekrc file in the root of the examined folders,
> to set the default profile? Would .reekrc contain "--profile xp", or
> a full YAML config?)
Or maybe master.reek? I'm not overly keen on hidden files...
> I think of Reek as highly subjective (which is why I'm planning to add
> profiles). What smells today might be unimportant tomorrow;
...highlighted by a conversation about Utility Functions I had with
another developer tonight, so I'm awaiting the results of your
experiment...
> and what
> is cost-effective to fix today may not be so tomorrow. Etc etc. Blah
> blah. I just don't like the idea of comparing teams or codebases, I
> guess. use Reek to help you do your own job, and don't worry about any
> other teams doing theirs :)
I had a feeling you'd say something like this. I'm not keen on
metrics either, as they are all ultimately gameable (at least LoC,
code coverage, defect rate, etc). I guess I had a naive hope that
since the issues Reek highlights are largely communication issues that
they could be used cross-team. But I'm not actually in a situation to
need that, so it was just hypothetical.
I wonder though, could someone write Reek-proof code that was worse
that the Reek-flagged code they started with? I'd be interested to
know what Reek-gaming was like, if it was possible.
Ashley
Kevin Rutherford
On Mon, Oct 12, 2009 at 10:46 PM, Ashley Moran
<ashley...@patchspace.co.uk> wrote:
>
> I wonder though, could someone write Reek-proof code that was worse
> that the Reek-flagged code they started with? I'd be interested to
> know what Reek-gaming was like, if it was possible.
Oh it's dead easy. Reek doesn't look too closely at singleton methods
right now, so move all your code into class methods. Or break Large
Methods into daft pieces. Or choose nonsensical names for everything.
Etc etc.
This is why I'm currently experimenting without Large method, Nested
Iterators, Feature Envy and Utility Function. Those things are all
symptoms of other problems, and I'mtrying to get to the core without
them distracting me.
Ashley Moran
On 19 Oct 2009, at 07:59, Kevin Rutherford wrote:
> Oh it's dead easy. Reek doesn't look too closely at singleton methods
> right now, so move all your code into class methods. Or break Large
> Methods into daft pieces. Or choose nonsensical names for everything.
> Etc etc.
Good point. Looks like the ungameable code metric is still away off,
if even such a thing were to exist...
> This is why I'm currently experimenting without Large method, Nested
> Iterators, Feature Envy and Utility Function. Those things are all
> symptoms of other problems, and I'mtrying to get to the core without
> them distracting me.
I'll do my best to fill in for them in the mean time.