Naming conventions

F

Fuma

Executive Member
Joined
Jul 9, 2007
Messages
5,365
Reaction score
346
Location
Pretoria
I see a lot of people using different naming conversions, from company to company, for their database objects to their programming language variables, functions and and...
What do you prefer?

E.g. NameOfSomething / Name_Of_Something / name_of_something / etc

How do you name your database objects - tables, stored proc, views, columns, etc?
Do you start with a prefix, and group them accordingly
E.g. (for stored procedures) sp_Procuct_UpdateSomething/ sp_Customer_UpdateSomething
 
I dont like prefixing, postfixing, or underscores, either. I generally use CamelCase for externally accessible things like properties and pascalCase for private methods and variables.
 
I usually try to name within the naming convention of the particular language I'm using.
I also dont like _ in names. Prefer newCustomers or the like.
I only use _ in method parameter names if I already have a variable of the same name:
example
method(_sum)
{ sum=_sum;
}
 
dequadin said:
In C# you could do this:
Code: 
public class MyClass
{
    private int sum;

    public void (int sum)
    {
        this.sum = sum;
    }
}
Click to expand...

I dont like having two variables with the same name in the same scope even if one of them can be referenced using the this keyword. The compiler usually works it out pretty well, but I prefer just naming them differently. Makes it more readable for humans I think.
 
dequadin said:
They aren't in the same scope, this is impossible.
Click to expand...

What would happen if the parameter was not named sum and I wanted to access the class variable called sum. Would I be able to?
 
this.sum

In fact, it's probably better to always use this. for class scope variables, simply for the auto-complete functionality.
 
At the end of the day, whatever naming convention you choose (hopefully NOT a sucky one), the most important thing is to BE CONSISTENT.

Choose a naming convention (carefully, with much consideration), and then stick with it throughout an entire project.

I can live with mediocre or even some bad naming conventions, as long as it is used consistently throughout a project. The worst thing is when different naming conventions are used in a single project. It drives me nuts.
 
Last edited:
dequadin said:
Code: 
public class MyClass
{
    private int sum;

    public void Sum (int paramSum)
    {
        // The compiler will figure this out
        sum = paramSum;
    }

    public void Sum2 (int sum)
    {
        // This is ambiguous, so you need to specify [B]this.[/B]
        this.sum = sum;
    }
}
Click to expand...

Thats my point - the sum class variable is accessible as such from within the class, hence I'd avoid a parameter of the same name to avoid confusion on the programmers side. I would use the this keyword anyway.
 
Ancalagon said:
I dont like having two variables with the same name in the same scope even if one of them can be referenced using the this keyword. The compiler usually works it out pretty well, but I prefer just naming them differently. Makes it more readable for humans I think.
Click to expand...

That is the exact reason why I do it that way. I mainly use C# and Java and do use this all the time (auto complete ftw :D) but for readability _ is easier for me.. Other wise I never use it.
 
For PHP, C# and Java I use CamelCase, although every language/framework will have their own best practice naming conventions.

I avoid prefixes in my databases. I often see schema's with tbl and even type prefixes, ie vcName, which can make changing type annoying. I use all lower case and include underscores for database objects to avoid SQL compatibility issues. ie: invoice_line.
 
dequadin said:
This is impossible, you cannot have the two variables with the same name in the same scope. In my example the two variables have the same name but are in different scopes.
Click to expand...

In compiler terms, as you say it will figure out what you mean starting with the most restrictive interpretation of the variable name. So yes, they arent both defined in the same space.

However, in human terms, they are accessible in the same space, even if one of them has an implicit this. For human readability's sake, I dont like two variables with the same name appearing as if they are in the same scope. Better?
 
I <3 underscores...
Seriously...
*duck*

But I keep to
1) The convention in the code that I'm working on (often not my own)
2) The convention of the language
3) pascalCase + CamelCase

I have to admit, I choose really bad variable names etc for brevity. Maybe silly, but typing out
Code: 
localHistogram->equalise(img->segment[img->nextsegment()]);
a lot gets tedious. Sue me.
 
Heita_Hola said:
I see a lot of people using different naming conversions, from company to company, for their database objects to their programming language variables, functions and and...
What do you prefer?

E.g. NameOfSomething / Name_Of_Something / name_of_something / etc

How do you name your database objects - tables, stored proc, views, columns, etc?
Do you start with a prefix, and group them accordingly
E.g. (for stored procedures) sp_Procuct_UpdateSomething/ sp_Customer_UpdateSomething
Click to expand...

First off, when it comes to naming stored procedures, DO NOT name your stored procedure: sp_whatever_my_stored_procedure

The "sp_" in front of the name makes SQL Server check dbo.master if the stored procedure is there first, then if it fails to find it, checks your database. This is something internal to SQL Server and might have been changed in the 2005/2008/2010 versions.

As for my naming convention: proc_[module]_[function][Description]

So I'll have:

proc_Customer_addCustomer
proc_Customer_editCustomer
proc_Basket_addItem
proc_Basket_deleteItem

etc. Just because adding a basket item is a "customer" function for example, it doesn't fall under the module of the "Basket" functionality, so you'll never see me do: proc_Customer_addBasketItem

Doing this automatically groups all of my modules together in nice alphabetical format and everyone working on the project can immediately see what the function of the procedure and where it should originate from. This ties in with my naming convention for my directories as well when working with web applications:

root/modules/basket/basket_addItem.asp
root/modules/basket/basket_editItem.asp
root/modules/basket/js/basket.js

etc. When working with Windows Applications I tend to:

frmMainUI
frmBasket
frmCustomer_editProfile etc

Internally (speaking of code specific)

When working with Boolean's, my naming convention for example is: blnDescriptive_Name (real world example: blnCustomer_IsActive). Just touching on Boolean usage quickly. Always try to be positive (as you should be in life all the time sonny boy). If you do:

"If NOT blnCustomer_Active Then"

All the time, you should reconsider your approach. By naming your variable "blnCustomer_IsActive" it makes the code quite enjoyable to read when looking at it from an outside perspective. "If this customer is active then do this bit of code"

Going back to SQL Server, since I started with SQL Server I figured I'll end with it again. Absentminded as I am.

When dealing with tables, I make it hard to guess from an outside perspective. This is just to **** with someone trying to guess my table names IF they find a way to inject SQL into the system (which you can't always be sure of, especially when you're programming in a multi-programmer environment for one project). I'll call my table something like, cms_tblCustomer (nb, I never use plurals in my naming convention. Or if I do, I always use it throughout the database. I guess I have OCD when it comes to this)

I never use Views because I find them clunky and abused by programmers who are too lazy to code properly and have no insight into a growing database and what an unchecked view could do to the server's performance.

Columns are pretty easy. I almost never use "_" in the naming convention and always capitalize "ID". So:

cms_tblCustomer would contain CustomerID,FirstName,Surname,DOB etc

I always add the following to any and all my tables, you might want to do this too!

Active (boolean, default 'true')
UserIDLastModified (integer, required)
LastModifiedDate (datetime, default null)
DateCreated (datetime, default getdate())

This should leave a basic paper trail of who did what in your database. I have a more advanced auditing system I wrote a couple of years back based on triggers which keeps the actual changes to every column in every table including which user did what, and it's proven several times that if someone ****s up, notices the ****-up, goes back and changes it and then when their manager queries this because it filtered through to the client somehow (or if it's the client itself that did this) and then conveniently blames IT, I just pull up the logs and go "Ah I see, you authorized this item to be published in the catalog at 11:41:23.022 AM today, then you changed it back 10 minutes ago. I can see why people bought this special, as the price was entirely wrong."

Then they're really quick to STFU. And when the manager bitches about the system "because it can't be his/her employees" I just pull another log and go "And at 11:49:44.052 you approved the changes to this item and it subsequently went live"

Anyway. Hope you n00bs learned something ;)

And yes i know I predominantly talk "VB", it's easier to understand for most people starting out and I wrote this in hopes someone else might find this useful.
 
AcidRaZor said:
......
Doing this automatically groups all of my modules together in nice alphabetical format and everyone working on the project can immediately see what the function of the procedure and where it should originate from.
Click to expand...
That's how I prefer it.

Then you spoil the whole thing by this:
Anyway. Hope you n00bs learned something ;)
Click to expand...
 
AcidRaZor said:
When working with Boolean's, my naming convention for example is: blnDescriptive_Name (real world example: blnCustomer_IsActive). Just touching on Boolean usage quickly. Always try to be positive (as you should be in life all the time sonny boy).
Click to expand...

That becomes a pain when migrating databases and changing types. If you were to migrate to MySQL, you'd have blnCustomer_IsActive which is actually a tinyint (no boolean datatype). If you were to change field types, you'd need to rename your fields to stay consisitent. If you were to move to Postgres you'd need to rewrite your SQL statements and quote any objects that are mixed case. Underscores are ugly, but using them and all lower case naming is the only way to keep your schema consistent among a variety of RDBMS's.

While obfuscation can be useful for security, in your DB I think readability and conciseness are far more important. cms_tblCustomer and blnCustomer_IsActive seem like overkill to me. You have a "customer" table and a field "is_active". Keep it simple. This makes reading and writing SQL as well as deciphering someone's schema far simpler. While this may include hackers, you should have mechanisms in place for auditing your software and code checked-in. Where I work, the only access I have to the database is through SP's.

I like the logging tip for simple logging in the database.
 
Last edited:
hof said:
That becomes a pain when migrating databases and changing types. If you were to migrate to MySQL, you'd have blnCustomer_IsActive which is actually a tinyint (no boolean datatype). If you were to change field types, you'd need to rename your fields to stay consisitent. If you were to move to Postgres you'd need to rewrite your SQL statements and quote any objects that are mixed case. Underscores are ugly, but using them and all lower case naming is the only way to keep your schema consistent among a variety of RDBMS's.

While obfuscation can be useful for security, in your DB I think readability and conciseness are far more important. cms_tblCustomer and blnCustomer_IsActive seem like overkill to me. You have a "customer" table and a field "is_active". Keep it simple. This makes reading and writing SQL as well as deciphering someone's schema far simpler. While this may include hackers, you should have mechanisms in place for auditing your software and code checked-in. Where I work, the only access I have to the database is through SP's.

I like the logging tip for simple logging in the database.
Click to expand...

We use trigger logging in our system - very reliable and powerful.

I agree about the variable naming though - keep it simple. I dont like things like Customer.CustomerID for instance, should just be Customer.ID. Besides which, if its got to the point that all hackers need to do is guess your table name, your security has failed. You may as well name them with GUIDs, and make them totally unreadable (to humans) but immune to injection.
 
hof said:
That becomes a pain when migrating databases and changing types. If you were to migrate to MySQL, you'd have blnCustomer_IsActive which is actually a tinyint (no boolean datatype). If you were to change field types, you'd need to rename your fields to stay consisitent. If you were to move to Postgres you'd need to rewrite your SQL statements and quote any objects that are mixed case. Underscores are ugly, but using them and all lower case naming is the only way to keep your schema consistent among a variety of RDBMS's.
Click to expand...
Very valid point. I suppose one has to take some time to plan and design thoroughly before jumping into something.
Vendor vs Generic.
 
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X