Checkout Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Na een Catch() moet er altijd een "reporting" of een nieuwe throw gedaan worden. In dit geval zegt mijn gevoel dat hier geen try-catch moet staan, want het is aan de gebruiker/oproepende code om ze...

Na een Catch() moet er altijd een "reporting" of een nieuwe throw gedaan worden.
In dit geval zegt mijn gevoel dat hier geen try-catch moet staan, want het is aan de gebruiker/oproepende code om zelf te bepalen welke error-handling er nodig is.

Anderszijds lijkt dit meer op een stukje test-code, dan kan je dat best ook zo aangeven (in methodnaam of ev in de comment) of moet je deze testcode verplaatsen naar een zTryout-klasse.
Zo niet, dan krijg je de reviewer(s) op uw dak :-D

Bij iedere UT moet je denken "Kan deze setup fouten verbergen?" of anders gezegd "Kan ik een programmeerfout aan het licht brengen, puur door andere input te kiezen?" Dus de (30, 30) zou je beter ...

Bij iedere UT moet je denken "Kan deze setup fouten verbergen?" of anders gezegd
"Kan ik een programmeerfout aan het licht brengen, puur door andere input te kiezen?"

Dus de (30, 30) zou je beter aanpassen naar verschillende waarden (zoals bvb. erboven 25,30)

Zoals het er nu staat, kan je enigszins verwarring scheppen tussen de echte MaakLijn() en de VerwachtMethodCall, aangezien deze (eerste) dezelfde parameters hebben. Bij voorkeur 2 verschillende (du...

Zoals het er nu staat, kan je enigszins verwarring scheppen tussen de echte MaakLijn() en de VerwachtMethodCall, aangezien deze (eerste) dezelfde parameters hebben.
Bij voorkeur 2 verschillende (dummy) Lijn-objecten gebruiken bij de DanReturn :

DummyLine1 = MaakLijn(0,0,0,0)
DummyLine2 = MaakLijn(0,0,0,0)

Dit is opeetcode. Als er een exception geraised wordt, gaat niemand het weten. Is dit het gewenste gedrag? Indien niet: er iets mee doen (en testje(s) voor schrijven)

Dit is opeetcode. Als er een exception geraised wordt, gaat niemand het weten. Is dit het gewenste gedrag? Indien niet: er iets mee doen (en testje(s) voor schrijven)

indenten tussen de accolades

indenten tussen de accolades

ge gaat toch eens een search voor Do ##class(Tools.Wlip).%New(238) moeten doen http://subversion02.vanhoecke.be/static/ogdo0b/2static/images/wiki/icons/emoticons/smile.gif.

ge gaat toch eens een search voor Do ##class(Tools.Wlip).%New(238) moeten doen .

constructor bovenaan zetten. Technisch maakt dat helemaal geen verschil, maar het maakt het consequent met de rest. Een volgende lezer van de code kan dan ook direct zien welke andere objecten er i...

constructor bovenaan zetten. Technisch maakt dat helemaal geen verschil, maar het maakt het consequent met de rest. Een volgende lezer van de code kan dan ook direct zien welke andere objecten er in deze klasse gebruikt worden

ge kunt het niet laten hé http://subversion02.vanhoecke.be/static/ogdo0b/2static/images/wiki/icons/emoticons/smile.gif (hieronder nog een paar)

ge kunt het niet laten hé (hieronder nog een paar)

[ICT-1348] SVG-025 ' aanpassen naar $$$NOT() + naamgeving van variabelen uitbreiden
[ICT-1348] SVG-025 ' aanpassen naar $$$NOT() + naamgeving van variabelen uitbreiden
[ICT-1365] SVG-029 Mock Testen uitbreiden
[ICT-1365] SVG-029 Mock Testen uitbreiden
AssertClassName bestaat ook

AssertClassName bestaat ook

nu die constructor leeg is, kan je je de vraag stellen of hij hier überhaupt nog moet blijven staan. Een constructie als deze kan een potentieel risico inhouden: aangezien je enkel een Quit $$$OK ...

nu die constructor leeg is, kan je je de vraag stellen of hij hier überhaupt nog moet blijven staan.

Een constructie als deze kan een potentieel risico inhouden: aangezien je enkel een Quit $$$OK doet, maskeer je logica die in de constructor van de Superklasses zit. In dit geval is dat niet echt relevant, omdat het toch klasses zijn zonder enige inhoud (bijna). Wou het gewoon even melden.

(logica van de superklasse oproepen: do ##super() )

[ICT-1374] SVG-031 Aanmaken CrossFactory
[ICT-1374] SVG-031 Aanmaken CrossFactory
Correctie : in dit uitzonderlijke geval lukt het niet om af te leiden van TECH.RegisteredObject --> in totaal zullen er 3 klassen zijn die dus afleiden van (%RegisteredObject,%XML.Adaptor)

Correctie : in dit uitzonderlijke geval lukt het niet om af te leiden van TECH.RegisteredObject
--> in totaal zullen er 3 klassen zijn die dus afleiden van (%RegisteredObject,%XML.Adaptor)

Sam, deze implementatie gaan we in "pair reviewen" (wss rechtstreeks vanop de code). We kunnen hier immers vele kanten mee uit http://subversion02.vanhoecke.be/static/ogdo0b/2static/images/wiki/ico...

Sam, deze implementatie gaan we in "pair reviewen" (wss rechtstreeks vanop de code).
We kunnen hier immers vele kanten mee uit