Is it possible to add an exception to Resharper naming conventions for a specific word? In particular, I'd like to be able to make an enum value "iPhone", even though I generally prefer PascalCase for enum values.
I checked out Resharper's naming style documentation, but didn't see any way to add a custom exception. I also tried using the custom abbreviations list, but that only works for all caps.
You can't add an exception for specific word, but there's some kind of workaround.
With ReSharper you can add more than one naming rules for a member. You can add new rule for "enum members" settings and set its name prefix to "iPhone". With this setting you'll be able to define "iPhone" enum value. Notice that with this setting you'll also be able to define "iPhoneWithReallyCoolFeature" enum value, because it doesn't violate this rule.
Screenshot for settings:
Update:
If you don't mind of polluting your code, you can add
// ReSharper disable once InconsistentNaming
just before your "iPhone" enum member.
Related
[property: Obsolete]
static int X
{
get { return 42; }
}
In the code above, what purpose does the word "property" serve? The code seems to work the same way if I replace [property: Obsolete] with [Obsolete]. And although "property" is coloured blue in Visual Studio, it does not appear in the list of C# keywords:
https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/
The Attribute specification defines this as an attribute target.
Certain contexts permit the specification of an attribute on more than
one target. A program can explicitly specify the target by including
an attribute_target_specifier. When an attribute is placed at the
global level, a global_attribute_target_specifier is required. In all
other locations, a reasonable default is applied, but an
attribute_target_specifier can be used to affirm or override the
default in certain ambiguous cases (or to just affirm the default in
non-ambiguous cases).
It also states that in many cases, like the one you mention, it is permitted but not necessary.
In other contexts, inclusion of an attribute_target_specifier is
permitted but unnecessary. For instance, a class declaration may
either include or omit the specifier type.
This is an attribute target specification.
In your code the use of it is not really necessary, since there is just one allowed target for that attribute at that place. The Obsolete attribute can be placed on a type, method or a property, but if placed on a property, only the property target specifier is allowed (and used implicitly).
The most practical use for this is the assembly target specifier, where you can set assembly configuration through attributes:
[assembly: AssemblyProduct("Foo bar")]
You can set the allowed targets on your custom attributes using AttributeUsage.
I used a decompiler to extract all the code from a DLL (SharpSVN -- cannot get my hands on the source code) and I want to modify an enum to give it a DisplayName.
public enum SvnStatus
{
Zero,
None,
[DisplayName("Not Versioned")]
NotVersioned,
//other one-word values that don't need a display name
}
But this gives me the following error:
Attribute 'System.ComponentModel.DisplayNameAttribute' is not valid on this declaration type. It is valid on 'Class, Method, Property, Event' declarations only.
Googled around and found a number of threads where people seem to do this no problem with their enums. Am I missing something? I can't Resolve the error in Visual Studio, the option doesn't even show up (but that might be because I just installed Resharper and am not familiar with it yet?)
Edit: Just found DevExpress has a CustomColumnDisplayText event where I can change the value as desired, so I'm going to go with that instead, since the data is only being displayed in a GridControl.
The reason is given in the error you're getting.
The System.ComponentModel.DisplayNameAttribute has been attributed with a System.AttributeUsageAttribute which constricts the usage to only be applied to classes, methods, properties, or events. Enums are excluded. It looks like this:
[AttributeUsageAttribute(AttributeTargets.Class|AttributeTargets.Method|AttributeTargets.Property|AttributeTargets.Event)]
Perhaps you can write your own attribute instead?
I want to raise warnings, if certain properties are used in the code. I could use the obsolete-attribute. But the used properties aren't obsolete, thus it wouldn't be that correct to give an obsolete warning.
How can I define own warnings for some properties that are printed during compilation, when the property is used?
Why not use the obsolete atrribute?
You can use task list with comments. Just use of the keywords defined here
If I am accessing a member field, property, or method, I'm never sure when I should prepend it with 'this'.
I am not asking about cases where it is required, like in the case where a local variable has the same name. I am talking about cases where the meaning is exactly the same. Which is more readable? Are there any standards, best practices, or rules of thumb I should be following? Should it just be consistent throughout a class, or an entire code base?
I disagree with StyleCop on this one, and I'm not even sure that StyleCop's opinion should be interpreted as an official Microsoft guideline anyway. It was an internal tool used at Microsoft but not all teams use it, and not all teams use all the rules.
Adding this everywhere is not necessary and often just adds clutter. It does not improve performance and I'm not convinced that adding this all over the code improves readability either.
You might hear arguments that it makes it more clear where the variable is defined, but I would argue that if your class/method is so long and complicated that it is difficult to work out where something is declared then you probably should refactor it anyway. If you use the single responsibility rule and have short functions it should be obvious whether a variable is a member, a function parameter or a local variable.
As you point out, sometimes it is necessary. For example in the constructor if you want to set a private member with the same name as the parameter.
public class Foo
{
private Bar bar;
public Foo(Bar bar)
{
this.bar = bar;
}
}
I recommend using Microsoft's guidelines, as verified by StyleCop: http://blogs.msdn.com/sourceanalysis/
The general rule is, prepend members with "this." when they are defined in the class, unless they are static, in which case you cannot.
Here is the rule directly from StyleCop:
SA1101: The call to {method or property name} must begin with the
'this.' prefix to indicate that the item is a member of the class.
I would say avoid as much as possible, it saves you some(in fact a lot of) typing.
I would depend on Visual Studio more to help me to find where what belongs(never forget F12). I don't use notepad to read my cs files :P
If you follow Microsoft's StyleCop, you should always use prefix class members with the this keyword.
SA1101: PrefixLocalCallsWithThis
TypeName: PrefixLocalCallsWithThis
CheckId: SA1101 Category: Readability Rules
Here's a similar StackOverflow question on the same topic.
I usually access parameters on the current object with this. Given a naming convention for instance variables "m_", this makes it easy to see at a glance what is affected by following statements without knowing their context:
m_Height += 10; // an instance variable
height += 10; // a local variable
this.Height += 10; // a property
In my code, I only use this.<PropertyName> when the property is a member of a base class, not the class I'm currently in.
Of course, not using 'this' at all is another popular choice, since it's unnecessary code being added.
Our coding standards at work state that member variables shouldn't be prefixed with 'm' or'_' or whatever else most people use. I've actually found myself using this.memberVariable all the time. I prefer the clarity over a little extra typing. And as mentioned in other answers, it's necessary when referencing parameters with the same name as member variables.
If you're using Visual Studio and Intellisense. When you type this you get a list of just your class level variables methods etc. Leaving out all the other possible items.
Which is the appropriate (more readable) way of naming enumerator? will you consider:
enum FilterOperators
{
IsEqual,
Contains,
StartsWith
}
class QueryFilter
{
FilterOperators Operator{get;set;}
}
var filter = new QueryFilter();
filter.Operator = FilterOperators.IsEqual;
Or is this preferable
enum FilterOperatorType
{
IsEqual,
Contains,
StartsWith
}
class QueryFilter
{
FilterOperators Operator{get;set;}
}
var filter = new QueryFilter();
filter.Operator = FilterOperatorType.IsEqual;
Also, Colors or ColorType?
IrritatedVowel.com suggests the following:
Enumerations
Standard Based Upon Microsoft .NET Library Standards
Follow class naming conventions. Do
not add "Enum" to the end of the
enumeration name. If the enumeration
represents a set of bitwise flags, end
the name with a plural.
Why: This convention is consistent
with the .NET Framework and is easy to
read.
Example:
SearchOptions (bitwise flags)
AcceptRejectRule (normal enum)
As such, I believe the preferred choice would be FilterOperator.
The "Framework Design Guideline" says:
Do use a singular type unless its a bit field
Do use plural types for flags enums (bit fields)
Do not use enum suffix
Do not use flag or flags suffixes
Do not use a prefix (e.g. ADO...)
So my suggestion would be FilterOperator
I think it's all about agreeing on a standard (you can define your own) and then sticking to it. I'd say appending "Type" seems like a good idea, even though for something as simple as "Color" it might seem a bit silly. It does hint that it is an enum, which I think is nice.
I'd say go for the last example :)
This is extremely subjective, but the first thing that pops to mind is 'Colors' strikes me as a list of many colors and seems appropriate. However, for a smaller list, like 'FilterOperatorType', the '...Type' seems appropriate.
In short, if their are many the plural of the word seems appropriate, if they are few and represent broad categories the '...Type' seems appropriate.