Capitalisation

[Uchiha Jax]

I just read this:

http://msdn.microsoft.com/library/d...s/cpgenref/html/cpconcapitalizationstyles.asp

But wondered if languages such as VB.NET would have any problems with:

private int color;

public int Color
{
get{return color;}
}

That only differs by case although the lower case version is private and the
uppercase is public, were a VB.NET coder to use the class would they be able
to use the property ok?
I only mention this because i've always designed my properties this way and
I wouldn't like to make my code unusable by a VB.NET developer.

 

[Bruce Wood]

Private properties are just that: private. a VB.NET caller will see
only the Color property and not the private color member, and once
inside the code of the Color get method, it's all IL anyway. The only
way that a caller could find out that there is a private member called
"color" would be via Reflection, and then only if it is a fully trusted
caller.

That said, this is not good coding practice. FxCop, Microsoft's freebie
coding style checker, will jump on you for this. I know, because I
often do the same thing, and FxCop complains. Yes, it's a pain thinking
up new names for private members versus public properties, but it is
better coding practice.

For my part, I use abbreviations for private members, so I might have
the public property Color that returns the contents of the private
field clr, or something like that.

 

[Bob Powell [MVP]]

To overcome this problem in the articles which I write that are targeted at
VB and C# users I use a property backing field named _color for a property
named Color and one called _fred for a property called Fred.

It's the best method I've found for code that might need to be converted to
and distributed in VB.

--
Bob Powell [MVP]
Visual C#, System.Drawing

Find great Windows Forms articles in Windows Forms Tips and Tricks
http://www.bobpowell.net/tipstricks.htm

Answer those GDI+ questions with the GDI+ FAQ
http://www.bobpowell.net/faqmain.htm

All new articles provide code in C# and VB.NET.
Subscribe to the RSS feeds provided and never miss a new article.

 

[Anders Borum [.NET/C# MCP]]

Hello!

That said, this is not good coding practice. FxCop, Microsoft's freebie
coding style checker, will jump on you for this. I know, because I
often do the same thing, and FxCop complains. Yes, it's a pain thinking
up new names for private members versus public properties, but it is
better coding practice.

I don't agree here. I think a "this.color" is much more readable than
m_Color, but I am interested in the arguments for using prefixes.

 

[Bruce Wood]

Apart from the problems that it causes with case-insensitive languages
like VB, creating identifiers that differ only by case also causes
readability problems, in my opinion.

Natural languages (like English or Spanish) generally don't have words
that change their meaning when capitalized. Yes, there are a few
(proper names, for example), but in general they don't: color and Color
mean the same thing. Now, as a programmer I can train myself to see
color and Color as different things, or different aspects of the same
thing, but I agree that it's mentally taxing, at least at the outset.

In particular, in a multi-language shop this would be difficult for
someone used to a case-insensitive language. It's common in such shops
that some of the VB programmers be thrown onto a C# project in a pinch,
or vice versa. You want to avoid language constructs that would confuse
programmers who understand the domain and the Framework, but not the
language. That's why I try to avoid the : ? ternary operator in C#, C,
and C++, and I avoided assignments inside conditions in C (if (status =
fopen(...) == null)...). I've always worked in mixed-language shops and
constructs like these are unreadable to VB programmers. The same goes
for color and Color being different things.

I often slip up, though, and use exactly the convention described: all
lower case for private data members, camel case for public things. My
only defense is that I always use "this." when referring to private
variables, in an effort to further differentiate them from public
properties, etc.

Using an underscore, as Bob Powell does, is also a handy
differentiation.

Anyway, at the end of it all, I think that this is why FxCop complains
about the different-only-by-case practice. It's only "wrong" when you
look at it in the context of all .NET languages, in a mixed-language
shop.

 

[Uchiha Jax]

I'm now in agreement with Bob Powell and today wrote quite a few classes
using the _ prefix.
Unexpectedly it turned out fine, I always rememebered the prefix and I don't
think it's going to take a lot to accommodate this in the long run.

A lot of very interesting points made here about the difficulties of working
with different languages and I thank everyone for replying..

Out of interest what do people use as a prefix for inbound arguments such as
a constructor?

E.G.

public class foo
{
private string _str1;
private string _str2;

public foo(string str3, string str4)
{
_str1 = str3;
_str2 = str4;
}
}

 

[Jon Skeet [C# MVP]]

Apart from the problems that it causes with case-insensitive languages
like VB

Only if both are exposed, of course.

creating identifiers that differ only by case also causes
readability problems, in my opinion.

Natural languages (like English or Spanish) generally don't have words
that change their meaning when capitalized. Yes, there are a few
(proper names, for example), but in general they don't: color and Color
mean the same thing. Now, as a programmer I can train myself to see
color and Color as different things, or different aspects of the same
thing, but I agree that it's mentally taxing, at least at the outset.

As is using an underscore, or prefixing everything with "m". Neither of
those occur in natural language either. I find it a pain to read code
with underscores all over the place - I always have a mental hiccough
between the words.

In particular, in a multi-language shop this would be difficult for
someone used to a case-insensitive language. It's common in such shops
that some of the VB programmers be thrown onto a C# project in a pinch,
or vice versa. You want to avoid language constructs that would confuse
programmers who understand the domain and the Framework, but not the
language.

I would argue that you want to avoid using programmers who don't
understand the language... train them to understand the language and
*then* put them on the project.

That's why I try to avoid the : ? ternary operator in C#, C,
and C++, and I avoided assignments inside conditions in C (if (status =
fopen(...) == null)...). I've always worked in mixed-language shops and
constructs like these are unreadable to VB programmers. The same goes
for color and Color being different things.

There are any number of things which may be unreadable to someone who
isn't familiar with the language though - not using them is seriously
limiting. For instance, I don't know many other languages with an
equivalent to C#'s "using" statement (not directive) - but it would
cause a significant amount of pain to not use it, putting try/finally
in there everywhere instead.

 

[Bruce Wood]

I should have qualified my comments further. I meant to say that one
should avoid using gratuitous constructs that wouldn't be understood by
programmers of other languages.

For example, the only place that you can't substitute the ternary
operator : ? with an if...then statement is in a call to a base
constructor. In every other case you can use if...then and it means the
same thing (and would be understood by anyone), so I prefer that
construct.

Yes, it's better to put people who know the language on a project that
uses the language, but 20 years of experience have taught me that
business doesn't always work the way one would like. I've lost count of
the number of times that someone thinks it a good idea to throw a VB
programmer unfamiliar with C on a C project because it's shorthanded.
So, I write code with this sort of thing in mind.

Apart from readability and cross-language concerns, can you think of
any other reason why FxCopy flags identifiers that differ only by case
as "bad practice"? I'm sure that they must have had a good reason....

 

[Jon Skeet [C# MVP]]

I should have qualified my comments further. I meant to say that one
should avoid using gratuitous constructs that wouldn't be understood by
programmers of other languages.

For example, the only place that you can't substitute the ternary
operator : ? with an if...then statement is in a call to a base
constructor. In every other case you can use if...then and it means the
same thing (and would be understood by anyone), so I prefer that
construct.

Similarly you can use try/finally instead of using - but using is a lot
simpler and easier to get right. Try/finally may be understood by more
people, but if someone's going to read my code they ought to learn the
language it's written in - or be willing to learn bits that they see
that they don't understand.

Yes, it's better to put people who know the language on a project that
uses the language, but 20 years of experience have taught me that
business doesn't always work the way one would like. I've lost count of
the number of times that someone thinks it a good idea to throw a VB
programmer unfamiliar with C on a C project because it's shorthanded.

How often has that come out well, out of interest?

So, I write code with this sort of thing in mind.

I think I'd rather discourage the bad practice, personally - while
getting the full range of expression that the language has to offer.

Apart from readability and cross-language concerns, can you think of
any other reason why FxCopy flags identifiers that differ only by case
as "bad practice"? I'm sure that they must have had a good reason....

A lot of people think it leads to mistakes where you type Foo instead
of foo. Having used the convention for years and never had a problem
with it, I don't think it's a good argument - at least, it's not a good
argument for *me* not to use that convention.

(Readability is the reason I *do* use it, by the way.)

Fortunately, as these members should never become visible to calling
code (which is why cross-language concerns aren't normally an issue) it
ends up being a matter of taste - the only problem is if you're on a
team which uses a convention you don't like.

 

[Anders Borum [.NET/C# MCP]]

Hello!

Natural languages (like English or Spanish) generally don't have words
that change their meaning when capitalized. Yes, there are a few
(proper names, for example), but in general they don't: color and Color
mean the same thing. Now, as a programmer I can train myself to see
color and Color as different things, or different aspects of the same
thing, but I agree that it's mentally taxing, at least at the outset.

I don't see how prefixing "m_" helps making the source code easy to read.
Jon mentions that prefixes don't occur in natural languages either (which is
also my argument), and if applied, does nothing but creating an ackward
pause between the words.

Personally, I use the "this" keyword extensively, as it helps read the code
faster (most of my teammates agree with this one, but don't enforce this
consistently).

Again, as private members are not directly exposed through the public
interface, I am not going to decide on what standards other people should
use - that is, if I am an end customer.

However, if I am going to work on the source code, I would prefer my fellow
team mates to use the same standard through-out the entire code base. I am
not a fan of source code inconsistency.

Don't forget the important three slashes .. ///<summary></summary>

 

[Bruce Wood]

Yes, it's better to put people who know the language on a project
that

shorthanded.


How often has that come out well, out of interest?

It usually doesn't. However, in business one is often at the mercy of
political forces beyond one's control. "Doing things the right way"
usually takes a back seat to "getting things done," even though
sometimes the apparently expedient solution is in fact more time
consuming than the "right way." Telling your boss to follow proper
procedure, or resisting the addition of a new team member on a
high-pressure project looks bad. This is not always a bad thing: often
it's the case that high-minded architectural ideals are overkill and
"just getting it done" is, in fact, sufficient. In short, I tend to
design, and choose my standards, based on the rough-and-tumble world of
everyday business, rather than how I would prefer things to be.

One of the best papers I read on architecture (although it could
equally well apply to standards) was called "The Big Ball of Mud"
(http://www.laputan.org/mud/mud.html)... the current version is
unfortunately substantially sanitized... the original version was much
better reading, IMHO. Foote and Yoder's point is that although business
often does things "wrong," it does so for good reasons.

So, if a language feature really does offer significant benefits, I'll
use it and require "newbies" to learn it. For example, "using" offers
real benefits over "try...catch" because it reduces the chances for
errors of omission. There are, however, other features of C# (and C and
C++) that I consider mere window-dressing: the ternary operator (in
most cases), the post- and pre-increment and decrement operators, among
others. I'm still undecided on identifiers that differ only by case: on
the one hand it's confusing to programmers of other languages, but on
the other hand, as many have pointed out here, prefixes and inventing
new, cryptic names for things that already have names is just as
confusing.