Oplossen Checkstyle meldingen

AlexMekkering commented 10 years ago

Om de kwaliteit van het product te vergroten dienen de Checkstyle meldingen in de huidige implementatie dienen zoveel mogelijk opgelost te worden.

De package fresnelio kan in eerste instantie buiten beschouwing worden gelaten.

TeunTheunissen commented 10 years ago

Hallo Alex, ik heb zoveel mogelijk checkstyle meldingen verholpen. De meldingen die er nu nog instaan hebben betrekking op classes in de fresnelio package. Daarnaast ook nog een paar meldingen over complexiteit betreffende abstract datatypes en fanout. Ik moet daarvoor het systeem eerst beter bestuderen. Ik heb geprobeert per refactor stap een commit te doen. Graag even reviewen. Groeten Teun

AlexMekkering commented 10 years ago

Ziet er goed uit Teun, flink wat werk verzet! Ik heb de volgende opmerkingen:

Ik zou de @author Javadoc elementen weghalen, het is een Team (28 & 30) effort :wink:
Voor PropertyFormat.java en Property.java zou ik een hashCode genereren ipv 0 (volg bijv. Eclipse context menu Source->Generate hashCode() & equals() ...). Dit kan goed van pas komen voor in ieder geval PropertyFormat en lost weer Checkstyle meldingen op over duplicate lines.

TeunTheunissen commented 9 years ago

Hallo Alex, @Author is aangepast. Alleen bij code die ik zelf heb toegevoegd heb ik het laten staan. Om aan te geven dat dat stukje code mijn verantwoordelijkheid is. Ik heb de hashcode methode zoals gegenereerd door eclipse toegevoegd aan de classe: Property, PropertyBinding, PropertyFormat. De classe Lens had geen hashcode en geen equal methode beiden zijn toegevoegd. Een test suite 'AllEquilityTestSuite' aangemaakt, zie package 'fresnelequalitytest' met unit test om de equal en de hashcode methode te testen. Via deze test tegen een bug aangelopen van de classe Property: De constructor property(naam,uri) maakt geen ontology property aan en daardoor wordt een nullpointer error gegenereerd bij het vergelijken. Ik heb deze constructor aangepast, er wordt een ontology.property object aangemaakt. Verder heb ik de oorspronkelijke equals methode laten staan, deze equals methode genereerd een nulpointer exception als een nullpointer object meegegeven wordt. In de door de eclipse gegenereerde code wordt een if-then gebruikt om deze situatie af te vangen. De reden is dat het via een exception makkelijker is om fouten te detecteren. Laat maar weten als je dit overbodig lijkt dan vang ik de nulpointer af en retourneerd de equals methode gewoon false.

Vr.gr. Teun

AlexMekkering commented 9 years ago

Code & Unit tests zien er goed uit. De equals methode eerst zo laten lijkt me goed.

ABI-Team-30 / Fresnel-Forms

Oplossen Checkstyle meldingen #16