[Insight-developers] Modes versus Objects

[Bill Lorensen]

I agree regarding code coverage. It would be great to have a machine
available (just one platform) that developers could use to see the
coverage of their class.

A first step, would be a cdash filter that shows the coverage for
requested classes. The current cdash presentation of coverage is not
useful if you are looking at only a few classes.

I for one do not have enough horsepower on my machines to do code coverage.

On Thu, Jun 2, 2011 at 11:58 AM, Luis Ibanez <luis.ibanez at kitware.com> wrote:
> 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
>>>>
>>>
>>
>