| All blog entries are the opinions of the author and do not necessarily reflect the opinions of their employer. All the code presented is for explanation and demonstration purposes only. Any damages incurred to your site and/or data are not the responsibility of the author. Every effort is taken to ensure the code properly compiles, however sometimes there are some hiccups and you might be required to do your own debugging. |
|
|
Series: Coding Contentions: Naming Conventions
Aug
27
Written by:
Wednesday, August 27, 2008 9:03 AM
I would like to start a series (nope, don't know how many installments yet :>) on coding better. The first installment/chapter will be on Naming Conventions.
I read today an article over at igloocoder.com by Don Belcham who I saw at Dev Teach in Toronto. He gave a presentation about working on existing projects (Brownfield Projects) and knows his stuff when it comes to working on existing projects (very insiteful). So when I saw his topic today it peaked my interest on how he handles naming conventions.
Naming conventions are either non-existant or a new kind of religion at most companies. If you are new employee, having to learn a new convention can feel like putting a round peg into a square hole. At least it was like that for me in my past. :< And to make matters worse, the companies I've been at in the past have had different naming conventions for code, SQL, procs, files, XML, etc.
Microsoft has itself gone through a bit of naming convention transformation. They no longer push the Hungarian naming convention in favour of a new .NET style (uses Pascal and camel casing).
What are your standards? Do you use the same standards at work that you use at home when you're playing? I'm very interested in reading what you have to say.
2 comment(s) so far...
Re: Series: Coding Contentions: Naming Conventions
I was just talking about coding style with a few friends over the weekend, so you're defintiely not the only one thinking about.
These are the styles I use. I have no idea where I picked them up, but they're probably a mix of what was used at the various companies I've worked at, and what I find most intuitive.
I use camel case for variable names, with a prefix for the datatype. (ie, strUserName, iUserID etc). Class-level variables are prefixed with an underscore (ie, _strConnectionString). Interface class names are prefixed with an 'I' (ie, IUserRepository). We had a bit of a debate about whether this made any sense, but I've just gotten so used to it that I can't remember the original reasons I started. I do like being able to tell from the class name though whether or not it's an interface.
As far as syntax, I vastly prefer to have braces on separate lines. I know there's a name for that style, I just can never remember it. if (null != user) { //do something } as opposed to if (null != user ) { //do something }
The main reason I prefer this is that when scanning down a code listing I find it much easier to break up the code into logic units (ie, control flow paths).
By Peter Bernier on
Tuesday, September 02, 2008 8:35 AM
|
Re: Series: Coding Contentions: Naming Conventions
Very cool! :> Thanks for your input! By chance, is your background C/C++? The hungarian notiation, and underscores give that away. :>>>> The "I" for interfaces is very MS (IMHO). :>
See you at the study group! :>
By phenry on
Tuesday, September 02, 2008 8:50 AM
|
|
|
|