How do you plan before starting to code ?

[Gedare Bloom]

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