6

I've always reversed names so that they naturally group in intellisense. I am wondering if this is a bad idea.

For example, I run a pet store and I have invoicing pages add, edit, delete, and store pages display, preview, edit. To get the URL for these, I would call the methods (in a suitable class like GlobalUrls.cs

InvoicingAddUrl()
InvoicingEditUrl()
InvoicingDeleteUrl()

StoreDisplayUrl()
StorePreviewUrl()
StoreEditUrl()

This groups them nicely in intellisense. More logical naming would be:

AddInvoiceUrl()
EditInvoiceUrl()
DeleteInvoiceUrl()

DisplayStoreUrl()
PreviewStoreUrl()
EditStoreUrl()

Is it better (better being, more of an industry standard way) to group them for intellisense, or logically?

Josh Lee
  • 171,072
  • 38
  • 269
  • 275
NibblyPig
  • 51,118
  • 72
  • 200
  • 356
  • 1
    I don't see any reason to put the verb first, aside from reading better in English. I would have no problem naming things so they alphabetize by object instead of verb. – Gabe Jan 13 '11 at 16:33
  • 1
    to be honest, I consider the former set more readable and logical. However, if you prefer the latter you can always use namespaces and class files to "guide" your Intellisense while retaining names you like – Michael Lowman Jan 13 '11 at 16:33
  • I frequently use `NounVerb` style naming (as in your first example) to group things together when I am looking at lists of methods or controls within a form. It is quite helpful when a large collection of disparate elements exist (such as on a tab control) and there are some very clear groupings to take advantage of. – JYelton Jan 13 '11 at 16:45

5 Answers5

6

Grouping in Intellisense is just one factor in creating a naming scheme, but logically grouping by category rather than function is a common practice as well.

Most naming "conventions" dictate usage of characters, casing, underscores, etc. I think it is a matter of personal preference (company, team or otherwise) as to whether you use NounVerb or VerbNoun formatting for your method names.

Here are some resources:

Related questions:

Community
  • 1
  • 1
JYelton
  • 35,664
  • 27
  • 132
  • 191
2

Check out how the military names things. For example, MREs are Meals, Ready to Eat. They do this because of sort order, efficiency and not making mistakes. They are ready to ignore the standard naming conventions of the language (i.e., English) used outside of their organization because they are not impressed with the quality of operations outside of their organization. In the military, the quality of operations is literally a matter of life and death. Also, by doing things their own way they have a way of identifying who is inside and who is outside of the organization. Anyone unable or unwilling to learn the military way, which is different but not impossibly difficult, is not their first choice for recruitment or promotion.

So, if you are impressed with the standard quality of software out there, then by all means keep doing what everyone else is doing. But, if you wish to do better than you have in the past, or better than your competitor, then I suggest looking at other fields for lessons learned the hard way, such as the military. Then make some choices for your organization, that are not impossible but are for you and your competitiveness. You can choose big-endian names (most significant information comes last) or the military-style little-endian names (most significant information comes first), or you can use the dominant style your competitors probably use, which is doing whatever you feel like whenever you feel like it.

Personally, I prefer little-endian Hungarian (Apps) naming, which was widely seen as superior when it first came out, but then lost favor because Hungarian (Sys) naming destroyed the advantage due to a mistranslation of the basic idea, and because of rampant abbreviations. The original intent was to start a name with what kind of a thing it is, then become increasingly specific until you end with a unique qualification. This is also the order that most array dimensions and object qualifiers are in, so in most languages little-endian naming flows into the larger scheme of the language.

You are on to something. Forward, march.

Xan
  • 74,770
  • 16
  • 179
  • 206
DaveWalley
  • 817
  • 10
  • 22
1

It's not intrinsically bad. It has the upside of being easier to identify the type while scanning, and groups the options together in Intellisense like you said. As long as you and everyone else on your team picks a way of doing things and stays consistent about it there shouldn't be any big problems.

coreyward
  • 77,547
  • 20
  • 137
  • 166
1

Based on the methods listed, you might be able to refactor Invoicing and Store out into their own classes, which would be closer to the mythical "industry standard" way.

That said, whatever your programming team can agree on for naming convention should be fine. The important thing is to be consistent within the project.

Nathan
  • 71
  • 2
0

I don't think it's a good idea to develop a coding standard around a tool (as least not as the first consideration). Even though most IDEs will have Intellisense these days, and most people will be using said IDEs, I think that first and foremost a coding standard should be about making the code legible and navigable on its own merits.

I would opt for most logical naming, personally. When I write code and I have some object I'm about to call a member function on, I'm usually thinking about what member function to call based on the action I'm about to do, because I already know the object I'm manipulating. So my first impulse would be to start typing "Add" if I wanted to add something, and see what Intellisense showed me. This is, of course, subjective.

I have never actually seen anybody using your alphabetical, Intellisense grouping anywhere -- at least not in code that is not worth using as a basis for comparison because it was so horrid in other ways.

That said, if it's your standard, do what you want -- consistency is the important part.