CodingGuidelines: document the API in *.h files

It makes it harder to let the API description and the reality drift apart if the doc is kept close to the implementation or the header of the API. We have been slowly migrating API docs out of the Documentation/technical/api-* to *.h files, and the development community generally considers that how inline docs in strbuf.h is done the best current practice. We recommend documenting in the header over documenting near the implementation to encourage people to write the docs that are readable without peeking at the implemention. Helped-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>

Junio C Hamano committed Sep 28, 2018 at 09:50 UTC d9f079ad1a866151fea01f7f977dfbd1ba4d97f7
1 file changed +4 -1
Documentation/CodingGuidelines
+4 -1
@@ -358,7 +358,10 @@ For C programs:
358 string_list for sorted string lists, a hash map (mapping struct
359 objects) named "struct decorate", amongst other things.
360
361 - - When you come up with an API, document it.
361 + - When you come up with an API, document its functions and structures
362 + in the header file that exposes the API to its callers. Use what is
363 + in "strbuf.h" as a model for the appropriate tone and level of
364 + detail.
365
366 - The first #include in C files, except in platform specific compat/
367 implementations, must be either "git-compat-util.h", "cache.h" or