Reader Response – DB Naming Conventions
Paul Writes:
A couple of observations, based on the discussion so far.
For me, some things that give me some initial pointers:
– How does it look ‘out of the box’ ?
– What does MS do?
– What happens when you use the visual tools?
– How do we avoid valueless annotation?
For Indexes, the visual designer uses IX_ as the prefix. Why should manually named indexes have a different prefix? I can’t see a reason, so IX_ is what I use.
The two fundamentals of an index are the table, and then the columns indexed in their correct order. The ordering is important, and it helps us avoid creating multiple indexes where one will do.
IX_Customer_LastName_FirstName
Makes it clear that, in most cases, adding
IX_Customer_LastName
Is superfluous. I see junior developers adding these unnecessary indexes all the time. So transparency of the column names is useful.
Adding verbs like ‘by’ doesn’t add value for me. Indexes are ‘by’
columns inherently, I don’t telling this over and over.
Sometimes this approach crunches up against object naming limits, but most times it doesn’t and I take a ‘for the good of the many’ approach.
Now, SPs. Much as I hate suffixes for suffixes sake (noo to tbl!), there is, I think, a case here. Lift the lid and we find there’s already a naming convention that MS uses. sp{Something} – we all know it. Using a convention like usp{Something} keeps consistency with what’s already there.
My memory is hazy, but I think the UI made this distinction more apparent way back when, maybe 7.0, but even though these day lsnSystem stored procs maybe separated in the UI, they are all swimming around in the same pool underneath. And – admittedly unlikely – without a prefix you could end up with an SP name that clashes with a system SP.
(And finally, I hugely support NounVerb for SPs, no matter how prevalent or MS endorsed VerbNoun is. The latter goes utterly against any other language I’ve used and frustrates development. Who wakes up and thinks "today, I’m going to work on Get methods"? It’s a nonsense that somehow had become conventional wisdom in DB development. One day AdventureWorks will break away and lead newbies in the right direction
Code Naming Conventions
Today I’d like to get the discussion moving on Code Naming Conventions. I think they are important, just like the database naming conventions, and that a little care results in reduced work in creating and maintaining code. As I said yesterday, I’m not as interested in conventions such as what case you use, as long as you pick something and remain consistent. I’ll just add some thoughts here to get your ideas flowing.
These are pretty much personal preferences I have picked up from things I liked that others have done. I don’t have a lot of thought put into them, and for some of them, I don’t even have compelling reasons. But it should give you food for thought.
Most systems are data centric. As a result, I tend to have a lot of classes that are nouns representing some object or entity. I tend to put this in one or more projects based on the subject area they implement. I only use multiple projects if there are a lot of classes that are used only in a subset of systems. I like to use names that fully describe the noun, if at all possible.
I’m big on using interfaces because of the ease of extensibility they bring to code. So, I’ll have another project with the interfaces named the same as the class they support with the prefix I. No big surprise there. If I use an abstract class instead of an interface, I am likely to name that abstract class the same as the base noun followed with a suffix Base to let me know it is a class used as an interface with implementation included.
If my class is not anemic (a future topic) I will have a separate project and unit test established to test any methods or necessary properties of that class. To keep things simple, I like to name my test class the same thing as the class it tests with a suffix _Test. The reason I separate them into a different project is so that I can easily exclude them from a production build.
ORM types of classes also follow similar naming conventions with suffix for the layer in which they reside (say if you are following a repository pattern). Using tools such as Entity Framework, this can be handled for you pretty easily. For those of us who work in other languages or roll our own data access, the principles for naming projects and classes is pretty well known. If you are not comfortable with the concept, follow up on the Respository pattern.
Tomorrow I’ll get into some of the other kinds of application code classes that are not domain centric. In the mean time, if you have suggestions simply send an Email to btaylor@sswug.org.
Cheers,
Ben
$$SWYNK$$
Featured White Paper(s)
Encryption & Key Management for Microsoft SQL Server 2008
Written by Townsend Security
Simplify encryption and key management on … (read more)
Featured Script
admin dts – Backup Primary Restore Warm spare (SQLLitespeed or native)
Package will backup all databases and restore the user databases (unless you exclude as shown in this script) to the warm bac… (read more)