Hi Guys,
From my old Ada days we always force the code through the formatter before checking it in.
I still enforce this "good habit" myself... well the formatter needs a fixup... for Java anyhow.
If you use it you will see what I mean!!!!
This is what I suggest it does to REALLY rock:
All below in alphabetic order unless specified
AND... if possible... all below in folding areas unless specified
Static logging stuff at the top. e.g.
private final Logger logger = Logger.getLogger(GroupingManagementActionController.class.getName());
Scan for the word log?
Next "contextual" stuff like:
@Inject
private Conversation conversation;
@PersistenceContext(type = PersistenceContextType.EXTENDED)
private EntityManager em;
Next "contextual" Event stuff like:
// Events
@Inject
@GroupingCreateEvent
private Event<Grouping> createEvent;
The other @injects...
@Inject
GroupingManagementActionController groupingManagementActionController;
Next "leading" (Cruffy) stuff like ID and Version for Entities
@XmlAttribute
@XmlID
@XmlJavaTypeAdapter(IdAdapter.class)
@Id
@GeneratedValue
private Long id;
@NotNull
@Version
@Column(name = "version4OptLock")
private long optlock;
Next the "simple" private members
@XmlElement(name = "nots")
@Column(name = "notes", length = 1000)
@Length(max = 1000)
private String notes;
Next the Lists/Sets ...
1..*
@XmlElement(name = "tasks")
@OneToMany(fetch = FetchType.LAZY, cascade = { CascadeType.PERSIST, CascadeType.MERGE, CascadeType.REFRESH }, mappedBy = "grouping")
private Set<GroupingTask> tasks;
*..*
@NotNull
@ManyToMany(fetch = FetchType.LAZY, cascade = { CascadeType.PERSIST, CascadeType.MERGE, CascadeType.REFRESH })
private Set<OrganisationRole> organisationRoles;
*..1 (generally backlinks)
@XmlElement(name = "parent_organisation")
@XmlIDREF
@NotNull
@ManyToOne(fetch = FetchType.EAGER)
// -> DO NOT ADD IN AS BREAKS CREATE!// , cascade = { CascadeType.MERGE, CascadeType.PERSIST, CascadeType.REFRESH }
private Organisation parentOrganisation;
Next Constructors
Next @Overridden methods from parent classes
Next methods with names like init, create etc. (that logically would come first)
Next the putters/getters that match the members by public/private
Next other putters/getter for non members by public/private
Next the public methods (followed by any truly private methods they (or their neighbours) completely "own")
Next the private methods (followed by any truly other private methods they (or their neighbours) completely "own")
Finally methods life @Destroy, cancel, done or similar.
I am sure you can think of more!
Cheers.