This post originated from an RSS feed registered with .NET Buzz by Samer Ibrahim. Original Post: Naming Conventions for Forms/Controls/Stored Procs/etc Feed Title: Samer Ibrahim's Blog Feed URL: http://www.asp.net/err404.htm?aspxerrorpath=/SIbrahim/Rss.aspx Feed Description: The Samer I Warrior on battles with .NET Latest .NET Buzz Posts Latest .NET Buzz Posts by Samer Ibrahim Latest Posts From Samer Ibrahim's Blog

Today, I had a long discussion with one of my co-workers about naming conventions for WebForms in a project we are both working on.  The discussion revolved around the question of whether forms should be named Noun+Action or Action+Noun.  For example, let's say you are writing a contact relationship management WebApp where you have clients who own accounts.  The question is do you name the form where you do the editing of account information EditAccount.aspx or AccountEdit.aspx? 
My co-worker argued the side of the former while I was advocating the latter.  I might not do it justice, however, the basic premise of his argument was that it's linguistically more natural and intuitive to call the form ActionNoun than NounAction.  And while I fully agree that it's more linguistically natural, I think from an organizational and maintenance stand point it's structurally unnatural. 
My reasoning is based on the fact that after maintaining our classic ASP app I soon realized that the noun part is what you are usually updating and maintain when new specs are drawn up.  For example, a new field is added to your account object say for instance inception date which must show up on every account form.  With the ActionNoun convention, I have to go hunting for the EditAccount form which may be surrounded by a half a million other EditNoun forms, such as EditClient.  Next, I have to go hunting for every other form that does any other operations on accounts. 
How do I know how many there are or what they might be called?  The answer is I don't.  It's error prone because a form can easily be missed especially if you aren't simply look for the "Edit-" and "View-" forms.  If a form existed to transfer accounts for example it's extremely specific and I might not think to look for a form beginning with the word "Transfer".  Also, people use alternative verbs whereas usually the noun is defined by the business.  An account will always be an account but I might "edit" an account while you might "update" one (same thing different words).  On the other hand, if the convention is NounAction, I know that all my account forms will be right next to each other and therefore not so easily overlooked. 
I try to use this convention with my forms/controls whether in both web projects and windows projects and also with my stored procs.  Stored procs I try to use the convention Tablename+Operation.  So for example the name of a stored proc to retrieve an account from the Accounts table would look like AccountRetrieve.  Personally, I recommend it because it's easy to find related procs this way using a statement like
select * from sysobjects where name like 'Account%' and type = 'P'
or even
select * from sysobjects where type = 'P' order by name
Someone starting in the middle of the development cycle can easily get used to this rather than looking threw a million and one proc that begin "Get". 

Ok, well that's enough of that discussion for one day but if you have a better way let me know.