Survey Results

It still blows my mind in these days of OO and strongly typed languages that people prefix variable instances with the details of the implementation.

It's so anti data hiding.

Dale Thompson

Dale Thompson wrote:
It's so anti data hiding.

Doesn't data hiding include hiding the actual variables?

Behind every great black man...
... is the police. - Conspiracy brother

Blog[^]

-- modified at 10:00 Monday 29th August, 2005

We use camelCasing for local Variables, m_camelCasing for Members.
Function names are in PascalCasing, and statics and globals are rare Wink | ;-)

(Well - the theory says that they are PascalCasing).

MACROS and DEFINEs are Capitals.

"We trained hard, but it seemed that every time we were beginning to form up into teams we would be reorganised. I was to learn later in life that we tend to meet any new situation by reorganising: and a wonderful method it can be for creating the illusion of progress, while producing confusion, inefficiency and demoralisation."

-- Caius Petronius, Roman Consul, 66 A.D.

I mostly use PascalCasing for function names and extended version of the hungarian notation for all the other things.

Behind every great black man...
... is the police. - Conspiracy brother

Blog[^]

I use PascalCasing for classes, methods, and class members and camelCasing for local variables in methods.

We use Pascal case for classes and functions.
Hungarian notation for all variables.

In VB6 i used to use hungarian style but since moving to DotNet i use m_camelCase for member variables, camelCase for local variables and PascalCase for Class names and Functions.

I think more important than what style you use is that you use a style (or structured mix like above) and stick to that. That way anybody else who looks at your code should be able to read it like a book.

Nothing annoys me more than code which has no style and deliberatly obscure variable/function names.

JJ

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 Wink | ;)

)
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. Wink | ;)

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. Wink | ;)

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

Option	Votes	%
Yes, and they must be adhered to	228	22.18
Yes, but they are fairly casual	292	28.40
No, we just try to be consistent with one another	317	30.84
No	191	18.58
Total	1,028	100%

Do you have formal coding guidelines in your company? [Edit]