One of our senior developers has stated that we should be using a naming convention for stored procedures with an "objectVerb" style of naming such as ("MemberGetById") instead of a "verbObject" type of naming ("GetMemberByID"). The reasoning for this standard is that all related stored procedures would be grouped together by object rather than by the action.

While I see the logic for this way of naming things, this is the first time that I have seen stored procedures named this way. My opinion of the naming convention is that the name can not be read naturally and takes some time to determine what the words are saying and what the procedure might do.

What are your takes on this? Which way is the more common way of naming a stored proc, and does a what types of stored proc naming conventions have you used or go by?

  • 1
    "the name can not be read naturally"? By whom? What is your first natural language? English? Or something else?
    – S.Lott
    Commented Jan 26, 2011 at 15:52
  • 9
    @S.Lott - to me it does look like something you'd hear in a swamp in Degobah.
    – TZHX
    Commented Jan 26, 2011 at 15:54
  • 1
    Great question! Having some standards are better than having no standards, but some able people took this concept even further and came up with a good standard. For instance, Dijkstra has written about why it makes so much more sense to index arrays with a 0 as the first element rather than 1. developeronline.blogspot.com/2008/04/… It is a seemingly trivial topic, and yet I bet it took him some tinkering to come up with it. Similarly, Spolsky has a nice system: joelonsoftware.com/articles/Wrong.html Some thinking upfront avoids pain
    – Job
    Commented Jan 26, 2011 at 16:07
  • 4
    I'd say get rid of stored procedures alltogether ;) Commented Jan 26, 2011 at 16:45

4 Answers 4


Look at it like this. How are your methods organized in code? By object, with the methods hanging off.


By having your stored procs mimic that naming, it will be much easier to see how they relate to your source code.

  • Good point, but SQL is not inherently OO. In fact, it is VERY different from Java/C#/etc. code that interfaces with it. It is only natural to let SQL do its thing and let Java do its thing. If code must be generated, it can be accomplished with little effort.
    – Job
    Commented Jan 26, 2011 at 16:01
  • 4
    I don't think OO is a consideration here. The above is just an example of how it's not as unnatural as it may first appear to use such a naming convention. Commented Jan 26, 2011 at 16:10
  • 2
    If by having a method in the code be "MyObject.GetById(int)" why could a stored proc not also be called "MyObject.GetById" ? The grouping would still occur, and a dot would give separation between the object/table and the action that is wanted.
    – Chris
    Commented Jan 26, 2011 at 16:32
  • 1
    @Chris, I'm not sure you can use a '.' in a proc name, but certainly using objectVerb groups thing in the same manner as one thinks about them. I don't think of get first, I think of what I want, then how to retrieve it.
    – CaffGeek
    Commented Jan 26, 2011 at 17:04
  • 1
    @Mark Freedman, not that it's necessarily OO, you group things in procedural languages the same way, only they aren't in actual objects. But usually prefixed with what would naturally become an object if the code were converted. strCompare, strLen, etc, etc, objectAction
    – CaffGeek
    Commented Jan 26, 2011 at 17:06

I too can see the logic; it groups actions together by entity. However, if your actions are always GET, PUT, and DELETE the change in naming might not matter that much. I see the best benefit from the new naming standard occurring when you have unique action names e.g. "AccountTransferMoney," that kind of thing.

The most important thing is that there is a single standard, and that it is followed by everyone.

  • 1
    Coming from a company that had no official naming standards (other than "prefix with sp"), having a standard is the only thing that matters. Commented Jan 26, 2011 at 15:54

You have to decide what's the bigger issuer, finding the procs you're looking for or quickly deciphering their meaning?

If you see:

memberGetID memberGetName memberGetThis memberListSomething memberDelete

At some point, once you've already found 'member' you just ignore that and go from there.

Look in a phonebook. If you want to find John Smith, is Smith, Dave Smith, John Smith, Robert

really that hard? I don't call people by their last name and then first name unless it's James Bond.

  • 1
    +1 I love this question and the responses! It deals with usability, and that can get pretty tricky and interesting.
    – Job
    Commented Jan 26, 2011 at 16:09

Instead of "objectVerb", you could use "namespace_verbObject", like Member_GetById.
It will group procedures by namespace, and still use traditional "verbSomething" naming.

Not the answer you're looking for? Browse other questions tagged or ask your own question.