Naming things

There are only two hard things in Computer Science: cache invalidation and naming things.
-- Phil Karlton

Naming things seems so trivial, before I read this quote, I would have thought this whole question to be off topic here. However, a well chosen name can make such a huge difference in readability that I consider a thesaurus a basic coding tool. Naming is indeed very important for writing readable code.

Current naming

The app I'm working with is for selling stuff, e.g. carpets. Although being about carpets, I have no class Carpet in my code. The reason is that there are several contenders, which all end up being named as Carpet[Suffix].

  • A controller for a 3D mesh - suffix: Actor
  • A UI part - suffix: View
  • Product specifications for a type of carpet, e.g. name, cost per m2 etc - suffix: Dbo (for DataBaseObject)
  • The apps current selection, including a specific product (the previous point), an amount of products, a total price etc - suffix: CartItem (shortened from ShoppingCartItem)

So I have a CarpetActor, CarpetView, CarpetDbo and CarpetCartItem. It works, but to be honest, "View" is the only one of those I am content with. For this question I want to focus on the last two. Considering how much code has been written for ecommerce, I would expect for some convention for naming these things to exist. However, my searches only turned up marketing centered results.


Are there established conventions for naming the thing that contains all the specifications of a product and the thing that keeps track of product data in the current order?

  • Do the names you've chosen adequately convey the purpose of each class? Note that "carpet" seems a bit specific; I could see a Carpet Dbo, but not carpet controller classes or actors. Perhaps Product or Sales? Commented Mar 13, 2018 at 13:25
  • Phil missed out the last hard thing: off by one errors
    – Robbie Dee
    Commented Mar 13, 2018 at 14:02
  • What is your chosen architecture? Onion? MVVM? Laissez-faire? Commented Mar 13, 2018 at 14:27
  • @RobertHarvey Well, ThreeDRepresentationOfACarpet, while more descriptive, is quite long and sounds awkward. "Actor" is just one existing convention in e.g. video game development for "a thing in the 3D world". Carpet is pretty specific because my product groups behave so differently. E.g. closets, have the option of colour, type of door, interior etc and in the end have completely different code for price calculation, representation in 3D etc. They are both products in that they have a name and a price, but that's pretty much it.
    – R. Schmitz
    Commented Mar 13, 2018 at 14:33
  • @RobbieDee There are indeed many mutations of the original quote.
    – R. Schmitz
    Commented Mar 13, 2018 at 14:37

1 Answer 1


The key question is, What does the business call a Carpet?

They probably don't care about the 3d mesh, or the UI component, but I bet they say 'How many carpets do we have in stock?', or 'who bought that carpet?' and if you keep track of each one, with a barcode for example. Then you should probably have an object called Carpet not CarpetDbo. and the things in the cart should probably be Carpets

But maybe they call it a SKU or a StockItem. The key thing is to try and keep your terms aligned with the business as much as you can reasonably do so.

I don't think you can completely get away from suffixes. Like you say CarpetView or CarpetViewModel etc are generally accepted. But CartItem? bit of a code smell if you ask me.

So to sum up.

  • Yes there are established conventions for suffixes. View, ViewModel, Controller. but these are language/framework dependent
  • No there aren't any (that I know of) for generic eCommerce (which I have a good level of experience working in)
  • There is a principle, possibly from Domain Driven Design, but I think more general than this, That you 'call things names which match the way to business talks about the thing', or 'Object names match their real life counterpart'.
  • "Are there established conventions for naming the thing that contains all the specifications of a product and the thing that keeps track of product data in the current order?" - although nothing in this text seems wrong, I see no answer to the question. Saying that 'CartItem' as a name is a code smell also seems a bit off to me, but even weirder when my whole question is about finding other good, established name for those things.
    – R. Schmitz
    Commented Mar 14, 2018 at 10:05
  • One of the issues with naming a 'CartItem' is that it does not exist in RL. (I am assuming you are not proposing to make a class OneSquareMeterOfCarpet and add that to the shopping cart several times, like in RL.)
    – R. Schmitz
    Commented Mar 14, 2018 at 10:08
  • point taken, i have edited. Obvs I don't know your domain, but 'CartItem' /'Item' by itself seems fine, CarpetCartItem implies that you have multiple wrapper classes for every type of good you could buy, which might be fine if you only have Carpet and Fitting but makes me want to check the code to see if that is true or not. Hence 'code smell'
    – Ewan
    Commented Mar 14, 2018 at 10:42
  • With the edit - especially the second point in the list - this is now a very clear answer to the question. +1 & accepted.
    – R. Schmitz
    Commented Mar 14, 2018 at 10:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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