Properties vs. Public Variables

Chalk me up for constants with all capitals. Most people know that all caps is a constant and it makes sense to see them that way.

To me, it just screams YOU_CANT_CHANGE_ME_IM_IMPORTANT and I like it that way.

If you need to refactor to an instance variable it helps, because you can search for the caps version and replace with the instance var of the same name in camelCase or whatever.

It also helps when using code completion in your IDE, as you can just scroll to the capitalised constants to get what you are looking for.

I don’t see a better way of doing this. I’m curious, what do you use instead of caps?

public property int Name;

The last few weeks I have really been thinking about that for VB. Maybe…

Public Auto Property Name as Integer

I think Auto is still a keyword.

I also want a way to expose some methods of an internal object without exposing them all.

Private m_myList as ArrayList

Public Function Count as Integer Exposes m_myList.Count

Jeff, you still haven’t said how you declare your constants. I, too, use SCREAMING_CAPS. I agree with Brian and Sam – it’s a great way to set the constant apart from your other variables. You can quickly tell that a value is a constant.

To any C++ (or C programmer for that matter) the all caps conventionn is only for macro definitions. No code that survives through the pre-processing stage should use it.

As far as C# is a descendant of C/C++ I would expect it to follow their conventions.

A while I ago I wrote about how to get public variables to feel like accessors in C++. I don’t know if it can be used in languages like C# - I have no idea what the template support is like. Anyway the article is here:

http://www.kirit.com/C%2B%2B%20killed%20the%20get%20%26%20set%20accessors

Jeff,

I’m going to have to disagree with you here. If you are developing public reusable API, then you should use properties for the following reasons:

  • Not all binding works with fields
  • You can’t apply CAS attributes to fields
  • Harder to debug (ie can’t set breakpoints on fields)
  • It’s a breaking change to turn a field into a property
  • Obviously you can’t do validation

We actually have an FxCop rule (DoNotDeclareVisibleInstanceFields) that checks for visible fields.

By-the-way not all of Microsoft (let alone DevDiv) uses the Microsoft internal coding guidelines. Each individual team is free to choose their own style guidelines.

Regards

David

So Jeff, how do you write your consts? You hate ALL CAPS, OK we got it. :slight_smile:

So it looks like the benifits of wrapping fields with properties wins out. Next!

Not to beat a dead horse, but mocking a public data member is pretty difficult…

(That’s mocking as in unit testing using mock objects, just to clarify.)

Honestly Jeff, you really just want to morph C# into Ruby.

"Also, I really like Kevin Dente’s idea:

public property int Name;"

attr :Name, true

“That said, I think ALL CAPS IS REALLY HARD TO READ!”

For anything particularly long (several words, a whole sentance, etc - sure. For something relatively short it’s ok, imo.

eg:

static int MAXTHREADS = 4; // Ok
static int MAXCUSTOMERDISCOUNTINDOLLARS = 50; // Annoying…

(excuse me if the syntax is wrong, I’m a VB.NET guy)

In VB.NET you don’t have case sensitivity, so “MAXTHREADS” vs “MaxThreads” vs “maxThreads” is all the same (Intellisense will auto-correct the case to the same as where it is defined, however).

Private variables should be prefixed with an underscore if you’re going to have a method or property of the same name.

Eg:

Public Class Customer
Private _Name as String

Public Property Name as String
Get
Return _Name
End Get
Set(ByVal Value as String)
_Name = Value
End Set
End Property
End Class

I have to say, on point 1, you’re very mistaken. It’s absolutely essential in libraries for binary compatibility, replaceability and servicing reasons to always expose private fields as properties, and never as public fields - not to mention the uniformity benefits of depending on reflection and making the assumption that only properties matter.

What’s more, fields can be passed as ref or out arguments, whereas properties can’t - so that refactoring can easily break code. It’s more essential in libraries, of course, where you have a strong business case not to break other people’s code.

(Also, I notice you’ve got something against me hosting my blog on BlgSpt - that’s not very nice. Not a problem though, since I’ve got some domains too :slight_smile:

I have to disagree with Jeff.
SCREAMINGCAPS are hard to read, true.
SCREAMINGCAPSTHATAREEVENLONGER are even worse.
But having a const value shine from the code is a timesaver and sometimes, a lifesaver.
Here (at work) we use SCREAMING_CAPS_WITH_UNDERSCORES and the code looks just fine. Seeing all these i18n consts and no string consts let you know you’ve done the work correctly (at least from that aspect). Searching for that elusive place where the code gets called is easier, since you’ve got a related string (an I18N const) highlighted and… well, screaming. I’ve been programming “alone” for quite some time and working at it for a bit (though I wouldn’t consider myself a junior programmer) and I’ve always (at least since I started paying attention to coding style) used caps for consts. always. So, like some said, it feels “right” to me.

The framework provides a pretty clear example for how to name public constants - Pascal case. For example, Int32.MaxValue.

Much as I’d love to ditch Hungarian and ALL_CAPS conventions, as a consultant I’m always handed the yellowed, rusty-paper-clip-stained “standards” document that one overambitous employee wrote to coincide with the release of Visual Studio 6 SP5…

Exposing public fields is only ok when you will always control all of the code that references them, it will always be ok to update all of that code when you need to change the type/name, and you will always recompile and redeploy all of that code at the same time.

Or, said another way, it’s a lazy tradeoff that lets you avoid a completely trivial amount of work in favor of a potential “holy hell we’re screwed” problem later. That’s not the sort of tradeoff a professional would make - once they’ve been bitten by it and have spent time thinking about the tradeoffs they’re unconsciously making.

I do use “SCREAMING_CAPS” for constants.
However, one way to distinguish them is to prefix it with c

for e.g. const int cMaxThreads = 10;

If I remember correctly, you also can’t use the intellisence help things with fields in Visual Studio, only properties.

C’mon, what happened to the fundamentals of object-oriented design? State, behaviour, identity??

Preferences when coding are always a topic of disagreement, but seriously .NET provides such a clean class and object design, so you must do it justice and follow the naming conventions outlined in the SDK.

Public variables? No, no, no! Bad, bad, monkey. Objects should maintain state and behaviour, and should not allow random access to their state variables.

Naming collisions when variables and properties differ only by case? Well that’s bad naming as not all languages are case sensitive - it’s not CLS compliant.

I like to name constants using SCREAMING_CAPS_WITH_UNDERSCORES.

A_CONSTANT_ByAnyOtherCaps_SCREAMS_justassweet