CODEWITHSUNDEEP
variablesnaming-conventions
Chris Ammerman
Chris Ammerman

Reputation: 15316

How do you recommend denoting static class members?

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:

For private static fields I've been considering these:

Upvotes: 1

Views: 256

Answers (8)

Kent Boogaart
Kent Boogaart

Reputation: 178770

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.

Upvotes: 1

Marc Hughes
Marc Hughes

Reputation: 5858

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.

Upvotes: 3

Guillaume
Guillaume

Reputation: 18865

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.

Upvotes: 2

Naveen
Naveen

Reputation: 73493

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

Upvotes: 1

Quassnoi
Quassnoi

Reputation: 425713

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

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

Upvotes: 0

Jim Petkus
Jim Petkus

Reputation: 4508

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.

Upvotes: 0

tddmonkey
tddmonkey

Reputation: 21184

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?

Upvotes: 0

ChrisW
ChrisW

Reputation: 56123

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.

Upvotes: 4

Related Questions