False positive violation of Naming Rules

I agree on this one. Also, I feel that while Resharper should always have options to let you tune this sort of thing to your liking, by default it should adopt whatever standards Microsoft/Visual Studio use out of the box.  This isn't to say that MS neccessarily has everything correct, and that's a subject for deeper debate elsewhere. My reasoning is simply this. Not everyone on every team is going to have Resharper, and if its reformatting or renaming rules are going to introduce inconsistencies and "merge fights", then it is increasing friction in those areas. This is not the goal of Resharper.

Certainly I should have the option to tweak my settings so that all public properties and fields are camel-cased with leading underscores if that's what I'm into, but by default, R# should be enforcing the generally accepted "real world" standards. In this case, the standard in question would be the naming for event handlers, which is well established as "ObjectName_EventName".

Yeah. It would be nice if there were a checkbox for "exclude these
characters" and then let you list the characters to exclude if checked...
otherwise ALL characters are valid, as long as 'camel case' is used.

Something like that would seem to be a rather straight-forward, but
infinitely useful enhancement.

I have another issue where parameters are supposed to be lowerCamelCase...
however, if a parameter uses an abbreviation (such as ID), it should be
uppercase, and if the parameter is plural, then things like "IDs" should be
acceptable. I'm not sure how you go about allowing that, while preventing
other (non-abbreviation) capitalized parameters, but it's sort of annoying
to have all those warnings for something that follows our own naming
conventions just fine.


"flipdoubt" <no_reply@jetbrains.com> wrote in message
news:14004869.90341240254756068.JavaMail.clearspace@app8.labs.intellij.net...
>I have a method named "AssertFileExists_FileNotFoundException" for which
>Resharper says it violates the "Public properties, methods, events, and
>constants" rule. I have defined this rule as follows:
>

Name style: UpperCamelCase
Name prefix: <empty>
Name suffix: <empty>

>

To me, UpperCamelCase does not mean the name can never contain an
underscore. I use this format for tests where the first part shows the
member to test and the second part shows an expectation where there is
more than one expectation. Normally, my publlc members are camel cased
without underscores i
n the middle, but I don't know that this will always be true. Is there any
work around?

>

---
Original message URL:
http://www.jetbrains.net/devnet/message/5236205#5236205

Just to be extra picky, a parameter named "userID" is not camel-cased because identity is one word, so the "d" should not be capitalized. "userId" is camel-cased, but I agree it is a matter of style that Resharper should be flexible enough to handle. Can't you set an exception for variables that end in "ID"?

That was just one example, and actually the real problem is parameter names
like "userIDs". In that case, it's plural, so we want the plural ending of
"s".

We have a standard that "ID" is always all caps (to avoid the confusion of
whether it's "ID" or "Id" or "id"), regardless of whether it's a variable
name, a method name, a column name, etc. If "ID" is mean, then "ID is what
is used everywhere, for consistency. No guessing. It's easy enough to add
"ID" to the list of acronyms that Resharper keeps, which helps in most
cases, except when the acronym is the only thing (i.e. Resharper correctly
handles "userID", but it doesn't correctly handle "ID" as a parameter name,
nor does it handle "userIDs").

Also, as a side note, I'd love to have a UI in settings that showed the list
of acronyms, to allow us to 1) Edit it, and 2) import/export it (so we can
have the same set for all programmers on a project, and update it easily
from, say, source control).



"flipdoubt" <no_reply@jetbrains.com> wrote in message
news:8534197.139861241547762011.JavaMail.clearspace@app8.labs.intellij.net...

Just to be extra picky, a parameter named "userID" is not camel-cased
because identity is one word, so the "d" should not be capitalized.
"userId" is camel-cased, but I agree it is a matter of style that
Resharper should be flexible enough to handle. Can't you set an exception
for variables that end
in "ID"?

>

---
Original message URL:
http://www.jetbrains.net/devnet/message/5237464#5237464

Hi.

In 4.5.1 we suppressed inspection of underscores in the middle of the method names.

Hi, Paul.

List of acronyms can be edited through naming options (see ‘Manage Abbreviations’ button).

You may also choose a policy how to store code style options (see Languages/Common/Code style sharing). You may consider storing options per solution or in a separate file.

Thanks! Don't know why I couldn't find that on my own.

I hope the next release will add support for explicit exceptions to a rule.
Being able to add explicit exceptions will also help dealing with legacy
code where we're not allowed to go back and do wholesale changes on things.
In my previous example, "ID" would be a specific exception to the rules for
parameter names.

"Sergey Shkredov" <no_reply@jetbrains.com> wrote in message
news:23612875.146971241760034845.JavaMail.clearspace@app8.labs.intellij.net...

Hi, Paul.

>

List of acronyms can be edited through naming options (see ‘Manage
Abbreviations’ button).

>

You may also choose a policy how to store code style options (see
Languages/Common/Code style sharing). You may consider storing options per
solution or in a separate file.

>

---
Original message URL:
http://www.jetbrains.net/devnet/message/5237683#5237683