[dpdk-dev] [PATCH] doc/contributing/documentation: add info about including code
Thomas Monjalon
thomas at monjalon.net
Tue May 4 11:59:20 CEST 2021
04/05/2021 11:32, Burakov, Anatoly:
> On 03-May-21 10:02 PM, Thomas Monjalon wrote:
> > 21/04/2021 11:11, Conor Walsh:
> >> + The following will include a snippet from the skeleton sample app::
> >> +
> >> + .. literalinclude:: ../../../examples/skeleton/basicfwd.c
> >> + :language: c
> >> + :start-after: Display the port MAC address.
> >> + :end-before: Enable RX in promiscuous mode for the Ethernet device.
> >> + :dedent: 1
> >
> > I would prefer indenting the options with 3 spaces
> > to make them aligned with literalinclude.
> >
> > [...]
> >> +* ``start-after`` and ``end-before`` can use any text within a given file,
> >> + however it may be difficult to find unique text within your code to mark the
> >> + start and end of your snippets. In these cases, it is recommended to include
> >> + explicit tags in your code to denote these locations for documentation purposes.
> >> +
> >> + This can be done as follows:
> >> +
> >> + .. code-block:: c
> >> +
> >> + /* #guide_doc: Example feature being documented. */
> >> + ...
> >> + /* #guide_doc: End of example feature being documented. */
> >
> > I think we can standardize this usage in a beautiful syntax.
> > My proposal, using the scissor sign:
> >
> > /* Foo bar >8 */
> > foo(bar);
> > /* 8< End of foo bar */
> >
> > .. literalinclude:: foobar.c
> > :language: C
> > :start-after: Foo bar >8
> > :end-before: 8< End of foo bar
> >
> > Another idea:
> >
> > /*~ Foo bar */
> > foo(bar);
> > /*~ End of foo bar */
> >
> > .. literalinclude:: foobar.c
> > :language: C
> > :start-after: ~ Foo bar
> > :end-before: ~ End of foo bar
> >
> > Maybe we don't need any markup for the start line and keep it natural:
> >
> > /* Foo bar */
> > foo(bar);
> > /* end: Foo bar */
> >
> > .. literalinclude:: foobar.c
> > :language: C
> > :start-after: Foo bar
> > :end-before: end: Foo bar
>
> Not having markup will 1) risk people accidentally "fixing" or otherwise
> modifying comments, and 2) has bigger potential for collisions elsewhere
> in the comments. While these aren't big risks, IMO it should be
> explicitly obvious that a comment is not just a comment but a marker docs.
>
> Having named tags like in the original proposal is the most explicit
> version of the above, which is why i favor it, but i think it's OK to
> have a lighter-weight syntax (e.g. with scissors for example), however i
> don't think it's a good idea to leave things implicit like your last
> suggestion.
I think the first comment is not only for code extraction,
but also for code reader, that's why I think it's good to keep it natural.
More information about the dev
mailing list