How do you plan before starting to code ?

[Gedare Bloom]

On Fri, Jul 10, 2020 at 4:58 AM Richi Dubey <richidubey at gmail.com> wrote:
>
> Hi,
>
> Thanks for the suggestions, they're all very valid and helpful.
>
>> We advocate a test-driven development (TDD) approach in RTEMS. Write
>> the test that should pass once your implementation is correct. Making
>> it multi-layered from simpler to more complex functionality allows you
>> to keep track of your progress and make sure you don't break something
>> (regression) that was working earlier.
>
>
> Should it be a complete test suite like the ones in the folder smptests or should it just be an idea in the Doxygen comment?
>

For TDD you need to have a real test.

> On Thu, Jul 9, 2020 at 8:27 PM Gedare Bloom <gedare at rtems.org> wrote:
>>
>> Richi,
>>
>> Some good advice from others. I'll just add a few more notes.
>>
>> On Thu, Jul 9, 2020 at 2:23 AM Richi Dubey <richidubey at gmail.com> wrote:
>> >
>> > Hi,
>> >
>> > I understand. I'll learn how to use Doxygen and put it in my codes. Thank you.
>> >
>> Not just that, he also suggests you can start with a doxygen
>> description before you really start coding. This is useful to help
>> think through the interfaces and structures of your functions before
>> you start to implement them.
>>
>> If you need help to run doxygen locally, ask.
>>
>> > On Thu, Jul 9, 2020 at 12:43 PM Sebastian Huber <sebastian.huber at embedded-brains.de> wrote:
>> >>
>> >> Hello Richi,
>> >>
>> >> we use Doxygen to document the software design. Maybe you can write your
>> >> high-level description with it. This way it is integrated already
>> >> integrated in the sources. You can use @dot for graphs and @msc for
>> >> message sequences.
>> >>
>>
>> Personally, I like to start with pen and paper drafts in a notebook. I
>> keep my notebook handy to keep track of revisions and ideas. I'll move
>> to either text- or graphic-based design if I need to share it with
>> others. Text-based is easier to integrate in documentation, while
>> graphic-based can make for some really nice explanations in blogs and
>> other reports. Doing text-based in doxygen is a good way to save time
>> on internal doco later.
>>
>> >> I would document the data structures and the invariants of the data
>> >> structures. I would also try to write code which checks that the
>> >> invariants are satisfied. This can be used in _Assert() and RTEMS_DEBUG
>> >> blocks.
>> >>
>> >> I would also write test cases. You can already run the test cases with:
>> >>
>> >> https://docs.rtems.org/branches/master/c-user/scheduling_concepts.html#arbitrary-processor-affinity-priority-smp-scheduler
>> >>
>>
>> We advocate a test-driven development (TDD) approach in RTEMS. Write
>> the test that should pass once your implementation is correct. Making
>> it multi-layered from simpler to more complex functionality allows you
>> to keep track of your progress and make sure you don't break something
>> (regression) that was working earlier.
>>
>> >> There should be test cases which would fail with the Linux push and pull
>> >> scheduler.
>> >>
>> >> You should identify the key scheduler operations (e.g. block and
>> >> unblock) and write a high level description of the algorithms used for
>> >> these operations in some sort of pseudo code.
>> >>
>> >> --
>> >> Sebastian Huber, embedded brains GmbH
>> >>
>> >> Address : Dornierstr. 4, D-82178 Puchheim, Germany
>> >> Phone   : +49 89 189 47 41-16
>> >> Fax     : +49 89 189 47 41-09
>> >> E-Mail  : sebastian.huber at embedded-brains.de
>> >> PGP     : Public key available on request.
>> >>
>> >> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>> >
>> > _______________________________________________
>> > users mailing list
>> > users at rtems.org
>> > http://lists.rtems.org/mailman/listinfo/users