Class naming conventions

Question

I have the following scenario:

The (web-) application is built with Java/Spring. I have several REST-endpoints which deliver data prepared to be consumed by a frontend by datatables.net. Each of this endpoint has a somehow similar signature (sEcho, iDisplayStart, iDisplayLength etc.) which are standardparameters necessary to work with datatables. Some of the controllers need additional Information, which are provided in extra variables.

So I made a DatatablesOptions class for the general usecase and if I need additional fields I extend the DatatablesOptions class.

My question is now about the naming of the extended classes.

There are two approaches:

1. I have a package for each of the endpoints, where all additional classes for a topic are stored: e.g. "CustomerComplaints". In such a package you would find the derived class which is used for the additional fields exactly for the usecase of "customer complaints". Hence it is in the "CustomerComplaints"-package the name of e.g. "ViewOptions" would be enough to say what it is used for: »This object is used for the options of a view in the context of "CustomerComplaints"«.

   So my code in the Controller looks like this:

   @Controller
   @RequestMapping("/")
   public class CustomerComplaints {
   [...]
    @RequestMapping(value="/customercomplaints/datatable", method= RequestMethod.GET)
    @ResponseBody
    public AjaxTableModel getCustomerComplaintsForDataTable(@RequestParam (value="sEcho")int echo,
    @RequestParam (value="iDisplayStart")int startLine,
    @RequestParam (value="iDisplayLength")int linesPerPage,
    @RequestParam (value="iSortCol_0")int columnToSort,
    @RequestParam (value="sSearch", required = false) String searchString,
    @RequestParam (value="statusfilter")FilterOptions filterOptions,
    @RequestParam (value="sSortDir_0")String sortingDirection
   [...]
   ViewOptions o = new ViewOptions()
    .setLinesPerPage(linesPerPage)
    .setStartLine(startLine)
    .setSortColumn(getSortingKeyForColumnNumber(columnToSort))
    .setSortingDirection(sortingDirection)
    .setFilterOptions(filterOptions)
    .setSearchString(searchString);
   

   The job of the ViewOptions-class is in every controller the same and for the understanding of the code neglectable.

   So a further specification via the classes name is not necessary. It seems to me like some kind of "Hungarian Notation". The name CustomerComplaintsViewOptions provides not more Information in this context. And the package makes it unambigous enough. Every smart IDE should resolve the definition for that.

2. The second approach, which is more texteditor-friendly, is to make it easy to find the definition of this class and name it CustomerComplaintsViewOptions. So a coworker sees from the variable name, where to look, when he wants to know more.

What kind of naming is better style?

Answer 1

1. Actually #1 is called smurf naming (here is a question about it on Programmers.SE).

   One thing to consider: Do you have to work with more than one ViewOptions at the same time (or at the same source file)? If that's true having a more specific name would help. Two possible advantages of smurfier names:

   • There aren't multiple editor tabs with the same filename.
   • You don't have to use full package names to declare two ViewOptions in the same source file.

2. So I made a DatatablesOptions class for the general usecase and if I need additional fields I extend the DatatablesOptions class.

   Check Effective Java, Second Edition, Item 16: Favor composition over inheritance if you don't know already.

3. Try to format the code in a way which avoid unnecessary horizontal scrolling. It would make it esasier to read.

4. @RequestParam (value="iDisplayStart")int startLine,
   @RequestParam (value="iDisplayLength")int linesPerPage,
   @RequestParam (value="iSortCol_0")int columnToSort,
   @RequestParam (value="sSearch", required = false) String searchString,
   

   Some of the parameters have a space between the closing parentheses (...false) String) , some of them doesn't (...th")int linesPerPage). You can find another inconsistencies too. It should be consistent. Modern IDEs have autoformat, they do a really good job here, use them.

• Thomas Junk: Sorry for the bad formatting - I made this quickly up and fiddeled in a texteditor not my IDE. I have to deal only with one kind of optionset at a time - therefore I came up with (1). Dealing with FQNs would in my eyes be worse than smurfnames. But you are right in another direction: Perhaps I should refactor the whole Options classes and make only one class, which has a Map as the underlying structure (each option's name is unique)?
• palacsint: @ThomasJunk: The current ViewOpions with type-safe options looks better to me than a non-type-safe Map, so I wouldn't bother it.
• Thomas Junk: Mhm. Okay. But how could I benefit from refactoring the options to a composition? Simple case: I have an extra demand for adding dates, so my extended Options would inherit the common fields and add from Date and toDate. What would a refactored/composited version look like? Injecting the DatatablesOptions in the constructor and adding getters and setters which point to the injected object? what would be the advantage? With inheritance I have to type less ;)
• palacsint: @ThomasJunk: I don't say that you should use composition (I don't know too much about the context). I'm just saying that consider it. Inheritance trees could become nightmare to maintain. I've better experience with composition but it depends on the context.
• Thomas Junk: Okay, agreed. In general I prefer composition - only in this case it isn't appropriate. I have one parent and exactly one child which adds some getters and setters. And the whole object is only to encapsulate these options to keep the signature of called functions small. And you are right: the time to understand the code matters. And as a lazy (but caring) programmer for me less writing and less reading is easier. Time's too short to spend it on typing ;)