| For many developers, naming is a dispensable thing, but I think it is one of the major topics in software development. With the help of correct naming, you can easily identify the business aspects of a software component. Additionally good naming avoids unneccessary and bad comments. |
| Bad namings for Wicket-IDs are _birthdateTextField_, _firstnameField_ and _addressPanel_. Why? The naming contains two aspects: A technical aspect (_"TextField"_) and the business aspect (_"birthdate"_ ). Only the the business aspect is relevant because both the HTML template as well as the Java code already contain the technical details (_new TextField("birthdate")_). Additionally, such names add a lot of effort when you do technical refactorings, e.g. if you have to replace a _TextField_ by a _DatePicker_ and the Wicket ID _birthdateTextField_ becomes _birthdateDatePicker_. Another reason for avoiding technical aspects in Wicket IDs is the _CompoundPropertyModel_. This model delegates the properties to its child components named by Wicket IDs (see listing 3). For example the _TextField username_ automatically calls _setUsername()_ and _getUsername()_ on the _Registration_ object. A setter like _setUsernameTextfield()_ would be very inconvenient here. |
