When I add new event handler for any event, VS creates method like object_Click.
But ReSharper underlines this method as Warning, because all methods should not have any delimeters such as "_".
How can I customize rules of ReSharper so that it doesn't underline such methods? Or may be I should rename such methods?
Thanks in advance.
For C# (or VB), make the following change:
ReSharper | Options | Languages | C# | C# Naming Style, Advanced settings...
Change 'Event subscriptions on fields' from $object$_On$event$ to $object$_$event$.
You may also want to add additional rules to entity kinds like 'Types and namespaces' to account for code-generated classes such as 'Default'. For example, add a new rule with a '' Name Prefix and a Name Style 'UpperCamelCase'.
Personally, I'd suggest renaming the methods. Generally I think VS comes up with terrible names for both controls and events.
I prefer to make a method name say what it does, not what calls it. That promotes reuse as well. Admittedly the signature of an event handler is often not ideal for reuse - I'd argue that often a lambda expression calling a method with more sensible parameters would be useful:
button.Click += (sender, args) => SaveCurrentDocument();
but obviously the designer doesn't support that :(
Of course, renaming all the methods is going to be more work than just changing the R# settings, if you can find some that work...
I just created an extension for Visual Studio 2010, EventHandler Naming, that lets you specify with a simple pattern what you want your generated eventhandler names to be. The default pattern in the extension is On$(SiteName)$(EventName) which will give you event names like OnBtnNameClick instead of btnName_Click. You can get the extension at http://tech.einaregilsson.com/2010/12/22/better-eventhandler-names-in-visual-studio-2010/
On your file menu you should have "Resharper" Click it -> Options -> Naming conventions (on left menu).
From there you can specify what naming conventions are used for each of the naming types/styles.
Related
Does anyone have insight to ReSharper Ultimate 9.1 (2015) and handling naming conventions. I don't want to turn them off and DO prefer context of using CamelCasing via the different versions starting with upper or lower with respect to scope. All that is no problem.
Where I have a problem is working with application-based acronyms. Say I have a "THING" acronym in my app, and in a table, I have a "THAT" acronym. So if I want any variables within different scopes, things like
private _myTHINGs[]
public MyTHINGs[]
private _myTHING
public MyTHING
(and similar with the "THAT" acronym),
I am constantly getting nagged about naming conventions and it wants to keep changing them to something like
private _myThinGs[]
public MyThinGs[]
private _myThinG
public MyThinG
or similar. In some places, during the context-sensitive light-bulb how do I want to handle, it has offered instances of adding the acronym to the global settings for the solution and in some places it appears to work, but in others, it doesn't and I just dont want to have a ton of comments of
// ReSharper disable once InconsistentNaming
I'm using Resharper 7.3 but I can't imagine it's changed.
Go to Resharper Options via the menu bar, select C#, C# Naming Style, and then click Advanced Settings. At the bottom of this dialog, add in your company-specific abbreviations (separated by spaces).
I like how String.Format uses arguments to inject variables in to the string it is formatting. This is called Composite Formating and is discussed by MSDN here.
I want this functionality with my logging facade:
string foo = "fancy";
string bar = "message";
log.Debug("My {0} log {1}.", foo, bar)
My ILoggerFacade has the following method signature:
void Debug<T>(T message, params Object[] args);
And, I know I can implement this quite simply:
ILog m_Log = \\some logging implementation
public void Debug<T>(T message, params Object[] args)
{
m_Log.Debug(String.Format(message, args));
}
However, in Visual Studio I don't get the fancy highlighting of the {0}, {1}, ... arguments:
I guess it is ReSharper who is resposible for them, and it seems like it is just ignoring the formatting arguments and giving no "intellisense" help. This isn't good since the other developers who will be using the facade will be expecting this.
How do I get argument highlighting and "intellisense" for custom formatted methods similar to how these work:
Console.WriteLine(...)
String.Format(...)
etc...
Any help would be appreciated.
Check out ReSharpers External Annotations. Specifically, you want to use StringFormatMethodAttribute for this.
To use the External Annotations there are actually 3 methods. Two that it spells out, and one that you have to read between the lines to see.
Reference "JetBrains.Annotations.dll". I would recommend against this one. I don't like the idea of copying the DLL, or having to reference the ReSharper install directory. This could cause issues if you upgrade or re-install.
Copying and pasting attribute declarations into your solution. I'd recommend this as it gives you more control. Additionally, you can get rid of ReSharper (why would anyone do this? Stranger things have happened, I guess.), and still provide this feature to anyone that consumes your library. There are step by step instructions on how to do this in the first link.
Create an XML file, similar to what it uses for for the .NET Assemblies. I did this for the Silverlight Unit Test Framework. ReSharper does not recognize these tests by default.
To do this
Create a file name <assembly>.xml and put it in "ReSharper\vXX\Bin\ExternalAnnotations".
Add a root element "<assembly name="<assembly>">
Now add <member> elements for each member that you want to give an attribute.
I do not recommend doing this for your own code. However, if you have an assembly that you want to have this functionality, but cannot edit, this is the way to do it. This will only apply on your machine and each developer that uses the assembly will need to copy the xml file.
If I have a constant with name SomeConst (in UpperCamelCase form) in my code I can enter just the upper letters SC for showing it in intellisense list.
Is there a similar behaviour for constants in ALL_UPPER format, i.e. SOME_CONST?
I tried also SC. But SOME_CONST did not appear in intellisense proposal list.
Doesn't look like it. The re-sharper 'Go to' functionality only supports Camel Case naming conventions http://www.jetbrains.com/resharper/features/navigation_search.html
I can do this in resharper 6.1.1000.82 I could not do it before this version.
Currently if I have a const like this
public const string TEST_ME = "Hello";
and I type TM after hitting ctrl-space then my constant appears for selection. You can also generate constants in this style by editing the code formatting options in resharpers option dialogs under languages.
After another quick check there is no need to hit ctrl-space thats just my habits.
Does anyone have any guidelines/best practices for naming conventions for Forms and controls (e.g., events, buttons)?
I usually use Systems Hungarian notation
Example:
btnSubmit: is button
lblAccountNum : variable is a label
In WinForms I usually use suffixes, so for example:
submitButton
accountNumberLabel
etc.
But a lot of companies still use a prefix, like anthares said.
I don't believe any special rules are needed for forms development; the Microsoft .NET naming guidelines cover it.
I name forms like any other class in the application: MainForm, SaveDialog, etc.
I name controls like any other field within a class: okButton, nameTextBox, etc.
I usually prefix the full class name e.g. textBoxName. I find it easier to read than three letter prefixes and it's consistent with the names that are generated by the IDE. I only name controls that are referred to by code. Controls that are databound usually don't need a name.
The following example is most of the .net programmer is used
Control: Label
Prefix : lbl
Example: lblFirstName
The reason that the prefixes are not the full class names in most of the companies but some abbreviations of the class name are as follows:
Most of the naming conventions are approved before Visual Studio 2010.
All Visual Studio versions before 2010 have their inteli sense filter with something like "starts with" instead of contains.
That's why a lot of people / architects / leaders decided it will be a better idea to type "txt" and inteli sense will filter all textboxes for you, so then you just type "E" for example and you get txtEmail. If you have the full class name, you will need to type "textBoxE" to get the same result in inteli sense. This adds a lot of overheat when you have complex UI.
Now with Visual Studio 2010 you get a better inteli sense so you can just type "em" and you can easilly see the "textBoxEmail" in the list (along with Email and some other things that contain "em"). Still I seem to prefer to have 2-3 or up ot 4 letters abbreviation that will allow me to filter in inteli sense by control type (specially for UI) than having to type textBox. The reason I prefer it is that even if you are puzzled for a while with some control type (e.g. "rg" for RadGrid) you will need 5 minutes 3-4 times to remember it and start typing without thinking about it. While if you have radGrid everywhere you will need to hit 7 strokes to get to the meaningful one that will filter for you (e.g. "radGridC" in "radGridCustomers").
I do agree that only naming controls that are referenced in the code is usually enough.
What have you done to remove (Helpers/extension methods) string literal in code?
e.g. I have nhibernate search criteria code like this all over the place.
Expression.Eq("Status", LoginStatus.LoggedIn),
“Status” being the property of an entity object used as a string in the case.
Update: Primary reason in this case is to enable refactoring. If I write a helper method which reflects the object and gets the value, will make the above expression strongly typed.
This is what "Resources" and "Settings" is for. You can find this by right clicking your project in Visual Studio and clicking "Properties", then going to the "Resources" or "Settings" tab.
For pre-built resources that won't change often, use resources. For things you want to be configurable use Settings instead because it will auto-generate blocks of configuration for your App.config. You will still need to manually copy and paste these values if you do not want to use the defaults.
The nice thing about both is that VS will build a nice static class with properties you can use throughout your code. VS will maintain the class and resources for you dynamically as long as you continue to use the wizard.
I'll usually declare them as constants, or, if I have groups of related strings, I'll create an enum instead.
Either way, at least they have a descriptive name attached to them (instead of using "magic strings"), and their use will always be consistent.
In the past, I've used CodeRush (or your favourite refactoring tool) to convert to a const string in the class, and then moved said const strings to be public members of the entity class to which they apply.
The real answer here, if you're looking to get your code less brittle in the face of refactoring is to get out of the strings business, and use Linq 4/to NHibernate, but you'd have to research whether it's completeness is sufficeint for your purposes.
Realized that I could do this the Expression trees way. Using Code as data!
Something like this
protected IList<T> _FindByProperty<TResult>(Expression<Func<T, TResult>> expression, TResult value)
{
return _FindByProperty((expression.Body as MemberExpression).Member.Name, value);
}
IList<User> costCenters = _FindByProperty( user=> user.Name, "name");
Credits: http://suryagaddipati.wordpress.com/2009/03/14/code-as-data-in-c-taking-advantage-of-expression-trees/
This is related to a lot questions in the expression-trees tag.
I use a similar approach as Cherian. I got my idea from the FluentNhibernate's ReflectionHelper.
The principle is to use expression trees and then you could just put in a x => x.Status expression. The method would return the property name as string.
In fact, you could also just use FluentNHibernate? However, I don't know if their querying model is evenly extensive as their mapping interfaces...