Configuring UncommunicativeVariableName
gwgeller
reek is barking at it. I've been messing with reek config files for
hours trying to get it to exclude our variables from the reek reports.
The only success I've had is this:
---
UncommunicativeVariableName:
enabled: true
accept: @aryClearance
I've tried adding multiple, specific variable names and it doesn't
work. Of course I'd want to use a pattern which I haven't got to work
either. Can anyone tell me what to put in the config file to accept
our naming convention? Basically we have a half dozen three letter
prefixes for different datatypes. So any variable preceded with one of
these prefixes should be valid.
IE. intTotal, strName, decMoney, etc.
Thanks,
Gunner
Kevin Rutherford
> I've tried adding multiple, specific variable names and it doesn't
> work. Of course I'd want to use a pattern which I haven't got to work
> either. Can anyone tell me what to put in the config file to accept
> our naming convention? Basically we have a half dozen three letter
> prefixes for different datatypes. So any variable preceded with one of
> these prefixes should be valid.
In the current version of Reek the "accept" list for the naming smells
is always a list of actual names; there's currently no way to specify
a regular expression asking Reek to accept all names with a given
pattern.
I suppose the real smell here is that you're using Java-style naming
in Ruby source code. If you want to continue with that, I see no
reason to have Reek perform naming-convention checks at all. One way
to document your preferences would thus be to include class-level
comments such as this in your code:
# :reek:uncommunicative_variable_name: {accept: @aryClearance}
Or even:
# :reek:uncommunicative_variable_name:
which disables the named smell detector for a whole class or method.
Hope that helps,
Kevin
--
http://www.kevinrutherford.co.uk -- agile, TDD, XP, lean, TOC
Gunner Geller
Thanks for the reply. I know I'm not using Ruby convention, but it's
what we are used to. My hope was to use reek to make sure all of us are
adhering to the convention. If someone names a variable name instead of
strName it would be cool if those things were caught or even srtName instead
of strName. Is there any way to finagle the reject list to not reject this
convention? Or maybe I should make a rule that rejects if they don't match
the convention. Or is there a tool out there that I should be using?
Out of curiosity for the accept list how would I specify multiple variable
names? I tried and could not get it to work. The most I got working was
accepting one specific variable name.
Thanks,
Gunner Geller
Heartland America
952-361-5672
gge...@heartlandamerica.com
http://www.heartlandamerica.com
Hi Gunner,
Or even:
# :reek:uncommunicative_variable_name:
--
You received this message because you are subscribed to the Google
Groups "ruby-reek" group at http://groups.google.com/group/ruby-reek?hl=en
Kevin Rutherford
> Out of curiosity for the accept list how would I specify multiple variable
> names? I tried and could not get it to work. The most I got working was
> accepting one specific variable name.
Something like this should work:
---
UncommunicativeVariableName:
enabled: true
accept:
- @aryClearance
- @otherName
- @hungarianNotation
Cheers,
Ashley Moran
On 2 Jul 2010, at 11:35 AM, Kevin Rutherford wrote:
> I suppose the real smell here is that you're using Java-style naming
> in Ruby source code.
That plus Open Secret/Primitive Obsession?
Gunner - do all your variables get prefixed with a data type, or did you just happen to pick those as examples?
Regards
Ashley
--
http://www.patchspace.co.uk/
http://www.linkedin.com/in/ashleymoran
Gunner Geller
Thanks, for the reply. Any input on my other suggestions for a work
around? Ashley, yes we prefix each variable with a datatype or structure. To
me it makes the code more clear. If I'm working with hshNames I know it is a
hash. I don't have to search the code where it was assigned to see what it
is. Another situation I run into a lot is comparing or using arithmetic on
string variables that contain a number. If it is prefixed with str I know I
should convert it.
Gunner Geller
Heartland America
952-361-5672
gge...@heartlandamerica.com
http://www.heartlandamerica.com
-----Original Message-----
From: ruby...@googlegroups.com [mailto:ruby...@googlegroups.com] On
Behalf Of Ashley Moran
Sent: Saturday, July 03, 2010 6:21 AM
To: ruby...@googlegroups.com
Subject: Re: [reek] Configuring UncommunicativeVariableName
Regards
Ashley
--
Gunner Geller
Thanks for the input. That would be great if you added the regex
support. I have not read your book, but I think we are too far along to
change our naming convention, but do you have a good reference for Ruby
naming conventions? It seems when I look I find snippets and nothing
complete. To be honest I haven't programmed for any extended period of time
in Ruby for months. I'm starting to get back into it now and we are starting
to use metrics. We did a medium size project months ago and I just remember
using .to_d a lot to make stuff work. I think a lot of it had to do with
getting data from databases which made the datatype a decimal.
Gunner Geller
Heartland America
952-361-5672
gge...@heartlandamerica.com
http://www.heartlandamerica.com
-----Original Message-----
From: ruby...@googlegroups.com [mailto:ruby...@googlegroups.com] On
Behalf Of Kevin Rutherford
Sent: Thursday, July 15, 2010 5:15 AM
To: ruby...@googlegroups.com
Subject: Re: [reek] Configuring UncommunicativeVariableName
Hi Gunner,
I'll consider adding regex support to UncommunicativeVariableName in
Reek's next release; probably a good move in general.
> Ashley, yes we prefix each variable with a datatype or structure. To
> me it makes the code more clear. If I'm working with hshNames I know it is
a
> hash. I don't have to search the code where it was assigned to see what it
> is.
I would argue against this for two reasons. First, this is the "Type
Embedded in Name" smell, which makes the code much harder to change.
(Have you read my book [1]?)
And second, by using camelcase it violates the commonly accepted Ruby
conventions; which will make it harder for anyone outside your team
(or newcomers) to contribute to your code.
> Another situation I run into a lot is comparing or using arithmetic on
> string variables that contain a number. If it is prefixed with str I know
I
> should convert it.
This sounds like your code is riddled with the Open Secret [1] smell
(also known as Primitive Obsession). If the value was encapsulated
inside an object that did the conversion (and hid the representation),
the string's clients wouldn't need to know whether to convert it.
Sounds as if you're using a naming convention to compensate for
horrible coupling and leaky data hiding?
Cheers,
Kevin
[1] http://www.refactoringinruby.info/
--
http://www.kevinrutherford.co.uk -- agile, TDD, XP, lean, TOC
--