Coding Standards

[wraith808]

So... we've been given new coding standards where I work.  I'm ok with that.  But one of the conventions is driving me CRAZY!

Normally, I'd write something like...

Code: C# [Select]

1. private string _propertyX = string.Empty;
2. public string PropertyX
3. {
4.   get { return this._propertyX; }
5.   set { this._propertyX = value; }
6. }

(Yes, I know about auto-implemented properties; this is just an example. )

But under the new coding standards, it would look like this.

Code: C# [Select]

1. private string propertyX = string.Empty;
2. public string PropertyX
3. {
4.   get { return this.propertyX; }
5.   set { this.propertyX = value; }
6. }

I have spent *so* much time debugging typing errors now... the _ clearly separated my property store from my property name.  But this... AIEEEEEE!

I just had to vent... 

[mouser]

i also cant stand the practice of using _ prefix for internal properties.  i think it's asinine and ugly.

oops -- i see you were the one using _ hahahaahaha

i can't say i love the coding standard you have to use either -- too hard to distinguish.

i've always liked the idea of using lowercase for internal variables, mixed case for exposed stuff.

[wraith808]

i can't say i love the coding standard you have to use either -- too hard to distinguish.

i've always liked the idea of using lowercase for internal variables, mixed case for exposed stuff.

-mouser (April 03, 2011, 09:04 AM)

Even in that case, don't you have a hard time distinguishing?  And not using any caps in the internal stuff would *really* screw me up... I use CodeRush, and it allows you to navigate the camel caps- saves a lot of time!

And I like the (_)   a lot better than m_, etc at least... 

[mouser]

i just cant wrap my mind around a leading _ it always feels to me like something got truncated.

i'm a fan of long variable names, so i'd even prefer using some prefix like i_

[alivingspirit]

Wow that is annoying. That is the kind of coding standard that makes me want to scream "Why?!". Usually coding standards are supposed to make code easier to read. This just makes you second guess every variable. Is it a property or no? Do we want to set it using the property store?
I strongly am of the opinion the property stores should only be accessed directly under the most dire of circumstances because of how unclear and unstable it makes the code look. They should therefore be unmistakably different from the rest of the code. I hope they change the standards back to the "_" way. Sounds like your work place is a tough bureaucracy. Good luck getting it back the way it was.

[Renegade]

At the risk of sounding like a heretic, Hungarian has some merit.

I'll stop there before I get lynched.

[f0dder]

wraith: Be a rebel - APPEND the underscore!

Renegade: if used properly, yes - most people tend to think hungarian means prefixing the data type ("i" for integer, "s" for string etc, "p" for a pointer etc), which is pretty pointless. If used for the purpose of the variable, the logical data type, it holds some merit... like "cb" for "count (in bytes)".

[worstje]

I prefer the _ prefix myself as well. While a lowercase first letter might work for private variables, it is just too easy to write or read the wrong thing. I've had it happen more than once that autocomplete (or maybe my temperamental shift key - I am not sure yet) caused the wrong one to be put in. It's caused a few nice stack overflows because the property accessor kept looping into itself, which is really bloody annoying.

Hungarian notation is nice, but it needs to be sensible hungarian, not the overly verbose whats-the-point hungarian that adds no extra information. For more information, see Joel On Software: Making Wrong Code Look Wrong.

[Renegade]

Ok, I'll come out of the closet then...

Private variables?

Type _variableName;


Public members?

Done as properties like:

VariableName
get { return _variableName; )
set { _variableName = value; }


Methods? Pascal case:

private void SomeMethod()


Local variables? camelCase:

Type someVariable;


Interface components? Pure Hungarian. e.g. Check boxes are:

chkSomeBoxPurpose

A list?

lstSomething

A text box?

txtWhatIsit

Similar for other components.


I like Hungarian. It's easy to work with and is clear. I really don't care about the anti-Hungarian hype/crap. I'm all for stuff that works and is simple and understandable.

EDIT: Fixed a drunken error.

[wraith808]

^ You've got my preference almost *exactly* written there.  And interfaces, I append I to it, i.e. IMyInterface.  Generic types, I use T.

And worstje hit the nail on the head with why I've been having *so* many problems.  I just can't figure out how intellisense alphabetizes, but it seems that no matter what order I declare them in, I get the problem of it autocompleting with the wrong case.  AIEEEE!

And up until now, it wasn't really that bureaucratic before the beginning of the year.  We have a product side (that deals with client facing apps) and a content side (that deals with internal apps used to create content).  They decided to merge all of the developers into one happy group (yay...?) so this is an attempt to help with that.  As such, I can see the need for a unified standard.  It's just that the upper and lower case is *really* slowing me down, just as I've started to try to minimize the use of the mouse.

Something else I've noticed- the change in your personal coding standards as you go through career development.  My personal code is a mixture of things, purely because of my history as a contractor, and going from place to place, having to adapt.  I looked at a bit of code that I posted in the SQL injection thread, and gagged because I had all of the variables defined in pseudo hungarian, i.e. strThisString, etc.  I was so put off from it, that I actually had to change it, but missed an instance of a variable.  And that's not the first time I've had that issue.

Just an observation...