| commit | c7e5fe79b985dbe9a9bfaca5a097a4d53ab77437 | |
| author | Stefan Beller <sbeller@google.com> | |
| Fri, 28 Sep 2018 17:30:33 +0000 (28 10:30 -0700) | ||
| committer | Junio C Hamano <gitster@pobox.com> | |
| Sat, 29 Sep 2018 18:21:05 +0000 (29 11:21 -0700) | ||
| tree | c74d39320fe2459cbbd6004b06dcbe21c3665923 | treesnapshot (tar.gz zip) |
| parent | 1d4361b0f344188ab5eec6dcea01f61a3a3a1670 | commitdiff |
strbuf.h: format according to coding guidelines
The previous patch suggested the strbuf header to be the leading example
of how we would want our APIs to be documented. This may lead to some
scrutiny of that code and the coding style (which is different from the
API documentation style) and hence might be taken as an example on how
to format code as well.
So let's format strbuf.h in a way that we'd like to see:
* omit the extern keyword from function declarations
* name all parameters (usually the parameters are obvious from its type,
but consider exceptions like
`int strbuf_getwholeline_fd(struct strbuf *, int, int);`
* break overly long lines
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The previous patch suggested the strbuf header to be the leading example
of how we would want our APIs to be documented. This may lead to some
scrutiny of that code and the coding style (which is different from the
API documentation style) and hence might be taken as an example on how
to format code as well.
So let's format strbuf.h in a way that we'd like to see:
* omit the extern keyword from function declarations
* name all parameters (usually the parameters are obvious from its type,
but consider exceptions like
`int strbuf_getwholeline_fd(struct strbuf *, int, int);`
* break overly long lines
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
| strbuf.h | diffblobblamehistory |