|
I use m_camelCasing for Members, l_camelCasing for local Variables and p_camelCasing for Parameters.
Properties and Methods are in PascalCasing.
Because of the lack of guidelines I made this my own guidline hoping that it will keep me sane ( no need to comment that  )
I just like to be able to write something like this:
<br />
public void DoSomething(int p_theValueToWorkWith)<br />
{<br />
...<br />
...<br />
int l_theValueToWorkWith=p_theValueToWorkWith;<br />
...<br />
...<br />
}<br />
Beside that, using CodeRush I can still type faster than I can think.
|
|
|
|
|
I use m_camelCase for members, PascalCase for classes, properties, and methods. In C++ I used the C prefix for classes. Not in C#. I use the I prefix in both languages for interfaces. e prefix for enums to establish that its not a #define. I like the m_ for members as it pushes out the name with the direct association that its a member, and doesn't conflict with a local that is usually being compared to the member. I don't like my, as its two characters the same as m_ but makes me think Hungarian. I used informal Hungarian in C++, but I threw it out in C#. m_ is the only common usage of an underscore. I like it.
I was a believer in informal hungarian earlier but have moved on. At my last company we had a formal set of guidelines. This current place doesn't, but I'm adhering to my own. I believe strongly in having consistency across the entire code base. It should be intuitive to all members of the team. And when a new person joins, they shouldn't have to learn umpteen coding styles. I like my curly braces on their own line and directly below the start of the block. It allows me to grab the block as a whole with drag n drop. Plus its a direct visual as to what's in the block.
Comments are always welcome. Anything that helps me understand what I was thinking then, or what they were thinking then. The code isn't always intuitive. Sure I can read it and reverse engineer its meaning, but I won't know why immediately most of the time. I'm a lover of comments.
What happens instead if there isn't a consistency followed is what we have here now, as a new person starts, a new branch of standards are introduced and it becomes just a bit unwieldy. Prefixed stored procnames are another one.
In addition I think a generic best practices guideline is also helpful. Logging, data access, NOT using strings for EVERYTHING. I find this often with ASP developers. Build a search string from the database, and index into it for your keyword instead of putting together a bitflag. But I digress.
This statement is false
Semantic Sense in a Stream of Syntax
Twiddles my Bits from Degree in Form
To Dissipate into Meaning
This statement is false
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
