| 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. |
