How do you plan before starting to code ?

[Richi Dubey]

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?

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20200710/64870d28/attachment.html>