Same Thing Same Name

Everyone has seen newbie code like this:

CUSTOMER_NAME is a column in the database.

edtCustName is an entry field in the GUI.

strCustomer is a string in the GUI RepresentationLayer.

sCust_Name is a parameter to the business object model.

Often the same newbie wrote those.

This violates OnceAndOnlyOnce. Fix it. Because databases often enforce false stability, let it win. Change everything else to CUSTOMER_NAME. A wart (not HungarianNotation) is optional: edtCUSTOMER_NAME, strCUSTOMER_NAME, etc.

After the fix, as usual, seek related opportunities to RefactorMercilessly. For example, apply the VariableState pattern to fold arrays of GUI, business and database variables together.

Just like one of those ready-made commercial frameworks that advertise you can declare everything once.

Remember that there's more to code than just the run-time source. If you apply SameThingSameName to, say, the names of modules and configurations within your build scripts, you can fold together lines in your Makefile.

It's all good. And it's all required by the XpSimplicityRules.

I agree in principle with this, but I think the rules stated above are too strict.

Firstly, the capitalisation convention used for names communicates information. In Java, for example, THIS_CONVENTION is used for constants, ThisConvention for classes and thisConvention for variables and methods. So using THIS_CONVENTION in class, variable or method names communicates incorrect information to the reader.

Secondly, a customer name, the name of the table column that contains customer names, and a text edit field that can be used to input or edit a customer name are different things. They should not, therefore, be given the same name. However, the relationships between them should be made clear by relating their names with a SystemOfNames.

I would suggest a SystemOfNames like this for the customer name example:

    CUSTOMER_NAME (name of a column in the database)

    // A Java constant defining the name of the table column containing customer names
    static final String CUSTOMER_NAME_COLUMN = "CUSTOMER_NAME";

    // A Java variable that holds a customer name
    String customerName;

    // A text field that can be used to input or edit a customer name
    JTextField customerNameField = new JTextField();

--NatPryce

Isn't using naming conventions like this just a offspring from PrematureOptimization (column names may not be constant, also it is against UniformAccessPrinciple) and HungarianNotation (appending Field to a name to indicate it is a JTextField)?

Optimisation does not come into it. If you generate SQL "by hand" in a program, you will need to refer to column names. It's better to define the column name once, as a constant, than to have the name scattered in many strings throughout your code. However, the name of the constant does not identify the same thing as the name of the column. The name of the constant names the name of the column and the name of the column names the data in the column.

Your HungarianNotation criticism is a good one. The term "Field" is very close to the class JTextField, which is an implementation detail. The name was meant to reflect the role of the object rather than the class of the object. "Input" might be better. However, an input field in which the user can input a customer name is not a customer name and they should therefore have different names. In defense of the SystemOfNames, it tries to be close to English, rather than use cryptic warts, and I have found that this is important when reading and understanding code. --NatPryce

Let me reformulate my point. The customer column name may not be constant. Good OO principles state that we should hide this kind of implementation detail behind a query method, like getCustomerColumnName. Also shouldn't we use something like SQL'Column'Document as in Java's Document model for JTextFields with a column name getter and (perhaps) a setter? I'm not arguing against a SystemOfNames but I have a PetPeeve against LotsOfConstants?.

SmalltalkBestPracticePatterns covers a pattern called "VariableState". Everyone uses it, and it's how JavaScript, PerlLanguage, PythonLanguage or RubyLanguage declare their own normal member variables. You can simulate it with other languages.

What VariableState gives you is the ability to vary what member you refer to by putting its name in a string. In Perl:

  $hash{"member"};

So if you make all those member names exactly the same, then they are the same member experiencing different aspects of your program as they travel through it. The opportunities for duplication removal become endless.

Imagine you add a single element to a list at the top of your program, and the database gets it (refactored into the table declarations on the fly), the business layer gets it as payload, and the GUI automatically displays it.

If you paid for a framework to do all that, it would be a pair of golden handcuffs. If you wrote it yourself, as light and simple as you need, it's heaven.

Also see: SystemOfNames