Coding Rules / Guide

Hi,

Does anyone of you got some kind of set rules that prescribe the coding styles you should follow in your company? Like variable naming, indenting, best practices (like "Dont hard code sql queries in your code"), etc?

I need such document for our team (even though we are only 2 members) and really really dohnt have time to sit down and think up a fixed set of rules that covers all aspects.

You may want to look at this

We've got a "SQL Rules to live by" list - it's in my signature...

Otherwise we also have templates for every SUB/FUNCTION and rules associated with that.

But they really developed out of a personal style - what do you like to do?

Greg Snooks law: "For every coder there is a coder that doesn't like his coding style".


It is all about just get togheter and make them. I always do that when I start a new project in a team. So we have the standards from the start of. It often rely a lot on the language. Like if the lanague has it's standard functions made up with camel back, hungarian notation and so on. So it is more or less impossible to find 100% rule for all projects, with all teams for all lanagues.

For the team I am working on now, we mostly use Python. And we have a web page where the standards are written. They mostly build on common sense and what Guido van Rossum wanted it to look like. I can PM you the link to our guids if you like. But the lanaguges spesific is not too far from this:

http://www.python.org/dev/peps/pep-0008/


- ØØ -

You could start with The 7 secrets of successful programmers before you get into the nitty gritty of naming conventions...

Rather than Hungarian notation, I use Wokawidget Notation :D

Quote:

---

Originally Posted by Wokawidget

I go for a 3 letter convention.

str for string (strUsername)
lng for long (lngUserID)
int for integer (intUserID)
bln for boolean (blnIsAdmin)
byt for byte (bytData)
cur for currency
dte for date

etc

I then prefix these with another letter depending on their scope.

m - modular
p - passed param in a sub
g - global


ie in a form/class/module:

Code:

---

Option Explicit

Private mstrUsername As String

---

If the varible is global in a module then:

Code:

---

Option Explicit

Public gstrUsername As String

---

If the varible is passed to a function then I use:

Code:

---

Private Sub Woof(ByVal pstrUsername As String)
Dim lngIndex As Long
  'code here
End Sub

---

I find this method VERY handy for debugging code as you can see exactly what the varible is, and it's scope.

If you take a peek at ANY of the projects in my sig you will see this naming convention is use :)

---

For .Net:
Microsoft Patterns & Practices: Webcasts
Microsoft Patterns & Practices: 2.0 Fx
Microsoft Patterns & Practices: 1.1 Fx
Dr. Joe Hummel's Webcasts (Series on Modern Software Architecture) << Highly recommended. He did the series in both C# and VB (both are on the page). If you have the time, watch as much of the series as you can.

I realise this might be contraversial, but I personally dislike any form of variable type decoration because it distracts from the readability (and therefore quality) of the code, and because Option Strict makes it pretty much superfluous.

For example, if you consider

VB Code:

Dim CustomerName As String

It is more important to know that this variable is intended to hold a customer name than it is to know that this is held internally as a string.

I would say it depends on the language. I can't see the point in VB, but in old C code, I sure can.

I have to agree that with VB.Net putting variable type decoration has become less meaningful. I find with a .Net app I use just a purely readable and descriptive variable - but with VB6 code I go back to notation...

btw - I like boo over bln - much easier to type ;)

As you can see StrangerInBeijing, this thread is living proof of the old adage "put 10 programmers in a room and ask them the same question, and you will get 15 different answers". :D

To me the bottom line is that you need to adopt a standard for you and your fellow programmers that works for you within the confirms of both your shop and your application needs.

Since it's controversial, I'll stand on the opposing side (go me!).

I still like doing it. While it is true that option strict will do the restricting for you, I still find it to be good practice not to rely entirely on the IDE and intellesense. Also, if I stopped using the prefixes, my object's properties would easily get confused with my variable names. Take the example they gave "CustomerName". If I have a variable named that, what would I name the exposed property? CustName? Seems like it could get sloppy pretty quick.

While the code that uses the object can easily determine which is the property and which is the variable through intellesense (and its awesome icons); if I'm inside of the object, I may be using the property by accident. It's happened to me before and I know it can happen again.

Also, I fail to see how it would actually hamper readability. The notation I've always used it:

Dim strCustomerName as String

And if it's not exposed, but at object level:

Private _strCustomerName as String

This actually helps me read it. If I saw something named "CustomerName", common sense would let me know it's a string (along with the ide and such), but what does it tell me about its scope without jumping into object browser or deleteing one or two characters so intellesense will pop up and educate me?

My personal preference is keep them. It's a habit you worked hard at to instill (I still remember getting beat up over not doing it) and it seems like a step back to just forget it all together.

Frankly, using

CustomerName

and assuming its readable is a self-centered notion. The coder who created it knows it, but when someone needs to read the code quickly, (we all have deadlines, we all need to rush), then I don't want to have to move my mouse over it and look at the tooltip to appear and tell me what it is. If I can tell just by looking at

strCustomerName

that it is a string, and not an object of some other odd type like NameClass, then good for me.

When you say

strCustomerName

it only requires 3.5 brain cells (out of billions) to figure out that it is about customer names.

Of course that specific example isn't very good, there are other areas where this would make a big difference.

If anyone has mentioned this in this thread already I may not have seen it, because I skimmed it. I am just that arrogant.

Thanks for all the replies (see what you mean Hack!)

Reason why I posted this is: I worked at 3 companies so far (including MS Research) and everywhere I landed they allready had a system in place...From what we all take for granted (like a network!) to coding rules, a source safe database, etc etc.

I landed at this company and there was NOTHING! But I was so busy the first 6 months learning asp.net and creating a new web site, I did not do much to set things right.

Now the workload is TEMPORARY a bit lighter, and I am creating a network, domain, source safe database, singel development site and database, etc.

But this thing about creating a set of coding "rules" and "standards" will take me a few days, and I found that all the Coding Guidelinese at the previous company did what it were supposed to do...ensure that everyone code in a consistant manner. Even though each was different, all worked.

So, I thought someone would share with me the coding guideline document they use at their company, so I can just use it as such, maybe modify a bit, and save myself 2,3 days of work which I dont really have time for anyhow.

Wasn't that more or less just what I did? What do you mean with coding guide lines if you don't ment what I linked to?