Develop Reference

Naming conventions and ReSharper and application-based acronyms

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).

How to specify order of debugger visualizers in Visual Studio

I've been working on a debugger visualizer for Visual Studio for some time and while the actual visualizer works fine. The problem is that it always places itself at the top of the visualizer list when examining a variable which really annoys some of the users who rather have Text as the top one (since the top one is also default when opening VS).
I can't find any support for this on DialogDebuggerVisualizer or DebuggerVisualizerAttribute which were my first thoughts so I've been scouring SO/MSDN/Google for information on how to affect the sort order of the visualizers (preferably to put mine last in the list) but to no avail.
Below is how I register my visualizer, it then just shows a form based on the value that is being visualized.
using Microsoft.VisualStudio.DebuggerVisualizers;
[assembly: System.Diagnostics.DebuggerVisualizer(
typeof(Shorthand.VSAddins.JsonVisualizer.JsonVisualizer),
typeof(VisualizerObjectSource),
Target = typeof(string),
Description = "Json Visualizer")]
namespace Shorthand.VSAddins.JsonVisualizer
{
public class JsonVisualizer : DialogDebuggerVisualizer
{
protected override void Show(IDialogVisualizerService windowService, IVisualizerObjectProvider objectProvider)
{
var json = objectProvider.GetObject() as string;
var form = new VisualizerForm { Json = json };
windowService.ShowDialog(form);
}
}
}
Does anyone know if it is possible to affect the order of the visualizers or should I just let it be?

I don't think there is a solution. But there is a workaround:
Define your own Text Visualizer and put appropriate DebuggerVisualizer attribute before the attribute of your JsonVisualizer. The result will be that string will be readable by default and Json Visualizer can be chosen. A window with a multi-line textbox is not too much work.
It is probably not even necessary to write visualizer. It should be possible to use internal one but I don't know its name (Which class is used for "Text Visualizer"?).

It will always appear first, by design. The under the hood cast has found the best match for the variable it is reflecting on.
however, you could do either of two things. You could make the visualizer only appear when the sting contains ':'
Or you could use reflection to reorder the visualisers by adding them to the end of the collection in the order you want, then removing the originals from the collection.
For the latter you will most likely have to change the collection from readonly to writable. Via reflection.
There is no reliable source to draw on other than your will to succeed.

I guess that VS 'under the hood' can distinguish between type of string and type of xml quite easily, but Xml is just a string too, so a key question here would be, how does VS tell the difference between the two?
Could you dissect the VS XML visualizer to see how it works (even if you have to use reflector on the DLL to do it, you might get to see the method that works it out)

what will be the Regular Expression to get all the property and variables names of a class in c#?

What will be the Regular Expression to get all the property and variables names of any class in c#, I want to parse the *.cs file. that is i want to select any *.cs file as input and it should get the property name of that selected class, as an output.
can any one help!!!....would appreciate for any help i tried very much but not got the actual result every time class name is coming instead of property.
thanks
Jack

There's no way you're going to be able to get exactly what you want with a regular expression because you need semantic context, not just string parsing.
For example, a good first attempt at finding all of the field and property definitions in a C# file might go something like this
^\s*(?:(?:private|public|protected|internal)\s+)?(?:static\s+)?(?:readonly\s+)?(\w+)\s+(\w+)\s*[^(]
That will match properties (public int Foo {...}) and fields (private int foo;) but not methods (protected void Bar()).
The problem is that a regex engine has no concept of the context within which those tokens appear. It will match both foo and bar in this code:
int foo;
void Stuff()
{
int bar;
}
If you happen to know that your code file follows some coding standards, you may have more luck. For example, if you enforce a style rule that all class members must have access specifiers, then you can make the private/public/etc part of that regex non-optional; since those are only permitted at the class level, it will filter out local variables.
There are other options, none of them too attractive at first glance. There is persistent talk from the C# dev team about exposing the C# compiler as a service in some future version of .NET, which would be perfect here, but I wouldn't expect that any time soon. You could purchase a third-party C# parser/analyzer like this one (caveat: I have zero experience with that, it's just the first Google hit). You could try compiling the .cs file using csc and examining the IL, but you'd need to know all of the third-party references.

C# and Windows Forms control naming guidelines

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.

ReSharper conventions for names of event handlers

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.