[Insight-developers] Modes versus Objects
Luis Ibanez
luis.ibanez at kitware.com
Thu Jun 2 11:58:51 EDT 2011
On Thu, Jun 2, 2011 at 11:49 AM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
> The dashboard should not get this red in the first place. It shows a
> breakdown/weakness in our process.
>
Agree,
It shows a weakness in our process.
Here is the trivial case of the weakness:
A) Patch 1 introduces a new code
B) Patch 1 doesn't introduce unit testing for that code
C) Patch 2 exercises the code of Patch 1,.. and exposes
compilation errors from it.
I this context, both Patch 1 and Patch 2 look
green when tested in isolation from one another.
The flaw in Patch 1 should have been captured
by
1) Human code review, ...or
2) by a drop in code coverage....
If we were measuring code coverage by module,
as we should....
> With our tools there is no way it should have gotten this red.
>
>
My take:
The hole is that we are not requiring 100% coverage of
new code in the form of unit tests in the *same* module
where the code is.
We have violated the rules of Test-Driven development:
We should do:
a) write the test (in the same module)
this test initially fails
b) write the code until it makes the test pass.
c) now the test should pass
d) verify all other tests
e) Then... submit the patch to Gerrit
Reviewers should verify that any new lines of
code in a patch have 100% code coverage
exercised by tests in the *same* module.
>
> On Thu, Jun 2, 2011 at 11:46 AM, Luis Ibanez <luis.ibanez at kitware.com> wrote:
>> Bill,
>>
>> Yeap,
>>
>> We need more of these guiding principles,
>>
>> and
>> we need to capture them somewhere in the Wiki,
>> so they are available for quick reference when
>> we are making code changes.
>>
>> Something along the lines of what we have in:
>>
>> http://www.itk.org/Wiki/ITK_Coding_Style_Guide
>> http://www.itk.org/Wiki/ITK_Code_Review_Check_List
>>
>> Otherwise,
>> it is easy to settle for the quickest solution
>> that let the Dashboard go back to green.
>>
>> Here is a first cut at that new Wiki
>> page on Design Principles:
>>
>> http://www.itk.org/Wiki/ITK_Design_Principles
>>
>>
>> and it is now linked from:
>> http://www.itk.org/Wiki/ITK_Policies_and_Procedures
>>
>>
>> Luis
>>
>>
>> ------------------
>> On Thu, Jun 2, 2011 at 11:32 AM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
>>> Folks,
>>>
>>> This discussion is motivated by recent activity...
>>>
>>> Back in the early days of OO programming, I recall having discussions
>>> about the use of modes versus objects. When I taught OO courses I
>>> always discouraged modes if they changed the "identity" of the object.
>>>
>>> Should a mode be used to change the behaviour of an object or should a
>>> new object be created?
>>>
>>> A case where a mode is better than an object:
>>> Controlling the visibility of an actor in VTK:
>>> 1) Mode: vtkActor VisibilityOn/Off
>>> or
>>> 2) Object: two classes vtkActor and vtkVisibleActor
>>>
>>> 1) is the appropriate solution since, at run time, an application
>>> may want to change the visibility of an actor.
>>>
>>> A case where an object may be better than a mode:
>>> 1) Mode: itkShiftScaleImageFilter
>>> SetOperationOrderToShiftScale()/SetOperationOrderToScaleShift()
>>> or
>>> 2) Object: two classes itkShiftScaleImageFilter and itkScaleShiftImageFilter
>>>
>>> A VTK approach versus an ITK approach
>>> 1) mode: vtkImageMathematics 21 different modes (ADD,SUBTRACT,MULTIPLY,...)
>>> 2) object: itkAddImageFilter, itkSubtractImageFilter,
>>> itkMultipleImageFilter...
>>>
>>> It is not always obvious as to the best choice. But, I think the
>>> question should be asked anytimne we introduce a new "mode".
>>>
>>> Bill
>>> _______________________________________________
>>> Powered by www.kitware.com
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Kitware offers ITK Training Courses, for more information visit:
>>> http://kitware.com/products/protraining.html
>>>
>>> Please keep messages on-topic and check the ITK FAQ at:
>>> http://www.itk.org/Wiki/ITK_FAQ
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://www.itk.org/mailman/listinfo/insight-developers
>>>
>>
>
More information about the Insight-developers
mailing list