How do you recommend denoting static class members?

Question

I have a naming strategy for denoting the nature of code entity (variable, method, etc.) which accounts for the most common permutations of scope, entity type, and mutability, but I have not been able to choose a way of denoting private static member fields (not properties).

What are some recommended ways of denoting this?

Update: For what it's worth, I do understand that this has fallen out of fashion, and that for C# particularly, Microsoft argues against it. I should specify that my goal in this is not to provide a level of "documentation", but simply to be able to get as much information as possible with as little motion and cross referencing as possible.

Personally I feel it would be ideal if identifiers could be restricted to conveying information about purpose, and leave code context information to the IDE to convey. However, since VS2008 does not appear to provide highlighting/styling options which are based on scope or mutability, and I don't feel that tooltips are particularly efficient in this because of the required mouse motion and waiting, I find myself limited in my options.

For reference, I primarily program in C#, and below is a sampling of my current naming conventions:

• Method argument or local variable: thisIsMyVariable
• Instance-level private field: _thisIsMyVariable
• Public instance- or class-level property or method: ThisIsMyVariable
• Constant: THIS_IS_MY_VARIABLE

For private static fields I've been considering these:

• s_thisIsMyVariable
• _ThisIsMyVariable

Answer 1

I use s_ for static members and m_ for instance members.

However what you're asking for, and what I do, contravene the Microsoft-recommended naming conventions for C# which are listed here: Names of Type Members.

Answer 2

I don't differentiate between private static or instance variables. They're both camel-cased with a leading underscore:

private static readonly ILog _someLog = ...;

And I don't think I've ever been left scratching my head as a result.

HTH, Kent

Answer 3

I have no doubt this will degenerate into an argument about who's way is better (put those braces on the same line dammit!) but I don't like doing or seeing anything like this apart from the constants. I can see your reasoning behind this but unless you're a one-man shop it will just cause confusion when someone else is editing your code and doesn't stick to it.

I personally prefer to not care if its method, instance, static etc. scope and let the IDE help me on that when I do need to know. Besides, aren't there naming conventions published for your language?

Answer 4

Like Kent, I camel case with a leading underscore. Prefixing declarations has not been in vogue for some time. I find that organizing my declarations into regions and the tools tips that you get in the IDE are sufficient to keep track of this stuff.

Answer 5

I wouldn't use underscores, as everything public should look nice.

As for me, I use prefix the, like theApplication, theSettings, etc.

Answer 6

I use g_ , as static variable is nothing but a glorified global variable

Answer 7

You should stick to the conventions already in place for your language. Your IDE should make clear which variable is public / private, static / instance ... There was a need to put the visibility or the type of a variable in its name before we had syntax coloring editors. But now that we have it, I find the code much cleaner and easier to read if it isnt cluttered with prefixes.

Answer 8

I let my IDE format them differently. Way easier to see that italic=static. Then, when I have to refactor code I don't have to worry about renaming as well.