Request: methods' parameter renaming enhancment

Hello.
I'm a fan of using comments for methods invocation with explicit bool parameters' values (true/false) and nulls:
void boo()
{
foo1(/bParam/true);
foo2(/bParam/null);
}
bool foo1(bool bParam)
{
return !bParam;
}
string foo2(string sParam)
{
return sParam;
}

I'm sure it's very usefull for clarity of code.
But, there is an issue though. If I rename paramer's name using R#, comments'll leave unchanged. It's bad.
It would be REALLY nice if you added renaming parameters' names in comments too.

8 comments
Comment actions Permalink

So, how about it?

0
Comment actions Permalink

Hello Shike,

Though the suggestion itself is valid, it seems to me that it promotes practices
that are considered dangerous. I would like community to chime in and discuss.


In specific cases, for bool parameters I'd use enum. For string parameter,
if "null" means something like "default value", I'd use static field initialized
with default value (null here) and use it. Then, you code don't need clarification
with comments:

foo1(ProgressWindow.Invisible);
foo2(TaskName.Default);

Not only it makes it clear what argument means, it allows you to change,
rename, refactor and extend your code without breaking existing code. For
example, ProgressWindow enumeration containing Visible and Invisible (replacing
true and false) can some day get another value like "VisibleNonModal".

What do you think?

Sincerely,
Ilya Ryzhenkov

JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


S> Hello.
S> I'm a fan of using comments for methods invocation with explicit bool
S> parameters' values (true/false) and nulls:
S> void boo()
S> {
S> foo1(/bParam/true);
S> foo2(/bParam/null);
S> }
S> bool foo1(bool bParam)
S> {
S> return !bParam;
S> }
S> string foo2(string sParam)
S> {
S> return sParam;
S> }
S> I'm sure it's very usefull for clarity of code.
S>
S> But, there is an issue though. If I rename paramer's name using R#,
S> comments'll leave unchanged. It's bad.
S>
S> It would be REALLY nice if you added renaming parameters' names in
S> comments too.
S>


0
Comment actions Permalink

Agreed. Comments are almost always a code smell. In the provided example, they were being used to clarify a set of confusing bool arguments. Bool arguments are fine when they don't need such clarification, but when they do they should be refactored to enums.

0
Comment actions Permalink

Hello,

I think there are other, more important features waiting to be implemented.
I agree with Jeremy on this issue that such comments are a kind of
code-smell.

Kind regards,
Henning Krause

"Shike" <shrike@freemail.ru> wrote in message
news:26101180.8511213005095732.JavaMail.jive@app4.labs.intellij.net...

So, how about it?


0
Comment actions Permalink

I agree that these comments are used to attempt to clean a code smell that
should be better handled with enumeration values or static variables as
appropriate. Looking at the .NET Framework as an example, using

foo.StartsWith("bar", StringComparison.OrdinalIgnoreCase)

is a lot more readable than

foo.StartsWith("bar", true, CultureInfo.InvariantCulture);

The first example provides a clean definition of intent whereas the second
example requires one to examine the method signature to understand the
intent and to decipher the meaning of true.

"Ilya Ryzhenkov" <orangy@jetbrains.com> wrote in message
news:76a2bd0b1599148ca9851a1a01cdc@news.intellij.net...

Hello Shike,

>

Though the suggestion itself is valid, it seems to me that it promotes
practices that are considered dangerous. I would like community to chime
in and discuss.

>

In specific cases, for bool parameters I'd use enum. For string parameter,
if "null" means something like "default value", I'd use static field
initialized with default value (null here) and use it. Then, you code
don't need clarification with comments:

>

foo1(ProgressWindow.Invisible);
foo2(TaskName.Default);

>

Not only it makes it clear what argument means, it allows you to change,
rename, refactor and extend your code without breaking existing code. For
example, ProgressWindow enumeration containing Visible and Invisible
(replacing true and false) can some day get another value like
"VisibleNonModal".
What do you think?

>

Sincerely,
Ilya Ryzhenkov

>

JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

>
>

S> Hello.
S> I'm a fan of using comments for methods invocation with explicit bool
S> parameters' values (true/false) and nulls:
S> void boo()
S> {
S> foo1(/bParam/true);
S> foo2(/bParam/null);
S> }
S> bool foo1(bool bParam)
S> {
S> return !bParam;
S> }
S> string foo2(string sParam)
S> {
S> return sParam;
S> }
S> I'm sure it's very usefull for clarity of code.
S> S> But, there is an issue though. If I rename paramer's name using R#,
S> comments'll leave unchanged. It's bad.
S> S> It would be REALLY nice if you added renaming parameters' names in
S> comments too.
S>

0
Comment actions Permalink

Hi all.
Of cause we should consider using enums instead of bools. Sure. But I hope you won't tell that methods with bool arguments are evil, won't you?
Moreover we often have to call 3d-party componets' methods. I'm sure it's good to provider additional information into code.
You appeal to .NET FW. Hmm. There very many methods with bool arguments in the FW. Just for an example:
public FileStream(string path, FileMode mode, FileAccess access, FileShare share, int bufferSize, bool useAsync )

2Ilya: you said "In specific cases, for bool parameters I'd use enum". What did you mean by "specific cases"?

I'd sum up as: yes, we should consider using enums for parameters if possible. But in all other cases it's good to provider comments for bools and null.
Are you agree with such statement?
If so it'd be good to support parameters names renaming in comments ;)

Edited by: Shike on Jun 19, 2008 1:01 PM

0
Comment actions Permalink

Hello Shike,

Well, you can't rename 3rd party assembly parameter, can you? And if you
can rename it, then it is your code and you should be able to refactor it
to something better.

I agree that .NET Framework assemblies contains methods with booleans, and
it is acknoledged by MS as a "wrong thing, but we cannot change this, sorry".
Check this, for example: http://blogs.msdn.com/brada/archive/2004/01/12/57922.aspx

Said that, I don't think we will support renaming of parameter names in comments
attached to arguments. However, you can write your own plugin, which will
provide, resolve and bind references to parameters in comments. Then ReSharper
will be able to rename them, and find usages, etc.

Sincerely,
Ilya Ryzhenkov

JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


S> Hi all.
S>
S> Of cause we should consider using enums instead of bools. Sure. But I
S> hope you won't tell that methods with bool arguments are evil, won't
S> you?
S>
S> Moreover we often have to call 3d-party componets' methods. I'm sure
S> it's good to provider additional information into code.
S>
S> You appeal to .NET FW. Hmm. There very many methods with bool
S> arguments in the FW. Just for an example:
S>
S> public FileStream(string path, FileMode mode, FileAccess access,
S> FileShare share, int bufferSize, bool useAsync )
S>
S> 2Ilya: you said "In specific cases, for bool parameters I'd use
S> enum". What did you mean by "specific cases"?
S>
S> I'd sum up as: yes, we should consider using enums for parameters if
S> possible. But in all other cases it's good to provider comments for
S> bools and null.
S>
S> Are you agree with such statement?
S>
S> If so it'd be good to support parameters names renaming in comments
S> ;)
S>


0
Comment actions Permalink

I see. Thanks for explaning your position.

0

Please sign in to leave a comment.