As a beginning programmer, I'm trying to settle on a standard naming convention for myself. I realize that it's personal preference, but I was trying to get some ideas from some of you (well a LOT of you) who are much smarter than myself.
I'm not talking about camel notation but rather how do you name your variables, etc. IMHO, var_Quantity is much more descriptive than Q or varQ. However, how do you keep the variable from becoming too long. I've tried to be more descriptive with naming my controls, but I've ended up with some like "rtxtboxAddrLine1" for a RadTextBox that holds address line 1. Too me,that is unmanageable, although it's pretty clear what that control is.
I'm just curious if you have some guides that you follow or am I left up to my own devices?
Classic C doesn't use camel-case; I've written code in camel-case in C, and it looks weird (so I don't do it like that any more). That said, it isn't wrong - and consistency is more important than which convention is used.
The general practice for a C style language like Java or JS is to use camelCase for all variables and object members (properties & methods), and PascalCase for class names and constructors. Namespaces (or Packages in Java world) are usually in camelCase. But some languages make an exception to that.
A naming convention is a convention (generally agreed scheme) for naming things. Conventions differ in their intents, which may include to: Allow useful information to be deduced from the names based on regularities.
The standard naming conventions used in modern software development are as follows: Pascal case. camel case. snake case.
Some basic rules can be found here. And much more extended rules can be found here. These are the official guidelines from the Microsoft framework designers.
As for your example, the variable should should be called simply quantity
.
In this case, I think you'd be better off naming it as primaryAddressLine or firstAddressLine. Here's why - rtxt as a prefix uselessly tells you the type. Intellisense will help you with the type and is immune to changes made to the actual object type. Calling it firstAddressLine keeps it away from the (poor) convention of using 1, 2, 3...on the end of variable names to indicate that for some reason you needed more of them instead of a collection.
Name it for what it represents/how it's meant to be interpreted or used not for its data type, and in naming it don't abbreviate if you don't need to.
The Guidelines for Names is the best starting point. But as in other areas of life, once you know the rules, you begin to know where it's reasonable to break them.
I never use the old Hungarian notation that calls things strFirstName
, intCount
, and the like; but I still use it on controls: txtFirstName
, btnVerifyData
, etc. Reasons include:
In addition, I'm quite likely to do the same thing to many of the TextBoxes or ComboBoxes on a page or form, whereas I'm not likely to do something to all the ints or strings referred to on a page or form. So it helps to be able to quickly find all the TextBoxes with their txt
prefix.
There are others, though, that adamantly oppose Hungarian even in this case, and I'm sure they have their reasons. Regardless of your personal style, you may find yourself working on a team that has a very different style. In which case, just do what they do; it's very, very rarely worth making an issue of it. The only time I'd do so is if their style leads to a lot of bugs, but off the top of my head I can't think of a case that would cause that.
There are a few good coding standards documents available online - David Lance wrote one: http://weblogs.asp.net/lhunt/attachment/591275.ashx
I'd recommend that you use Microsoft's own guidelines as a starting point. Typically, most companies start there (in my experience, anyway).
http://msdn.microsoft.com/en-us/library/czefa0ke(VS.71).aspx
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With