DPDK patches and discussions
 help / color / mirror / Atom feed
From: Ferruh Yigit <ferruh.yigit@intel.com>
To: Thomas Monjalon <thomas@monjalon.net>,
	Conor Walsh <conor.walsh@intel.com>,
	"Burakov, Anatoly" <anatoly.burakov@intel.com>
Cc: john.mcnamara@intel.com, david.marchand@redhat.com,
	bruce.richardson@intel.com, dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH] doc/contributing/documentation: add info about including code
Date: Tue, 4 May 2021 12:15:44 +0100	[thread overview]
Message-ID: <27d6ea7a-d7c7-431b-d4a5-f1bc852e3a1f@intel.com> (raw)
In-Reply-To: <3962445.YuhGqRbsoE@thomas>

On 5/4/2021 11:44 AM, Thomas Monjalon wrote:
> 04/05/2021 12:35, Ferruh Yigit:
>> On 5/4/2021 10:59 AM, Thomas Monjalon wrote:
>>> 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.
>>
>> +1 to Anatoly's comment, to make it obvious to the reader of the code that the
>> comment is used for documentation purposes and use explicit syntax for it.
> 
> So you assume the comment is only for doc extraction?
> I think it can be a real comment, otherwise we'll need to have
> 2 lines: 1 for doc extraction, 1 for code comment.
> 

I see your point, for the cases that there is already a comment before (or
after) the code, will it be too bad to have multiple lines, something like:

/* Actual comment
 * More details
 *
 * explicit marker */


I think explicit marker has the advantage of:
- Whoever updating the comment will know that it is a marker for the
documentation and be careful on update
- Whoever updating the code between the markers, know that it may be required to
re-visit the relevant documentation and update it because of code change
- Whoever reading the code will know that part is in a documentation, and may be
interested to go and check the relevant documentation
- Whoever reading the code, and not very familiar with DPDK convention, still
can understand what that comment is for and benefit from above

  reply	other threads:[~2021-05-04 11:15 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-21  9:11 Conor Walsh
2021-04-21 10:21 ` Mcnamara, John
2021-04-21 10:31   ` Thomas Monjalon
2021-04-21 14:17     ` Mcnamara, John
2021-04-21 14:21       ` Thomas Monjalon
2021-04-27  9:54         ` David Marchand
2021-04-27  9:54 ` David Marchand
2021-05-03 21:02 ` Thomas Monjalon
2021-05-04  9:32   ` Burakov, Anatoly
2021-05-04  9:59     ` Thomas Monjalon
2021-05-04 10:35       ` Ferruh Yigit
2021-05-04 10:44         ` Thomas Monjalon
2021-05-04 11:15           ` Ferruh Yigit [this message]
2021-05-04 11:56             ` Thomas Monjalon
2021-05-05 12:02               ` Burakov, Anatoly
2021-05-06 13:50                 ` Walsh, Conor
2021-05-06 16:40 ` [dpdk-dev] [PATCH v2] doc/contributing/doc: " Conor Walsh
2021-05-07  9:54   ` Burakov, Anatoly
2021-05-07 13:15     ` Thomas Monjalon
2021-05-19 21:36   ` Thomas Monjalon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=27d6ea7a-d7c7-431b-d4a5-f1bc852e3a1f@intel.com \
    --to=ferruh.yigit@intel.com \
    --cc=anatoly.burakov@intel.com \
    --cc=bruce.richardson@intel.com \
    --cc=conor.walsh@intel.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=john.mcnamara@intel.com \
    --cc=thomas@monjalon.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).