Trim some long lines and remove a stray space between i and ++ in the
coding style example.
---
doc/developer.texi | 29 +++++++++++++++++------------
1 files changed, 17 insertions(+), 12 deletions(-)
diff --git a/doc/developer.texi b/doc/developer.texi
index 128b46e..a63bea7 100644
--- a/doc/developer.texi
+++ b/doc/developer.texi
@@ -49,10 +49,10 @@ mailing list.
The code is written in K&R C style. That means the following:
@itemize @bullet
@item
-The control statements are formatted by putting space betwen the statement and
parenthesis
-in the following way:
+The control statements are formatted by putting space betwen the statement
+and parenthesis in the following way:
@example
-for (i = 0; i < filter->input_count; i ++) @{
+for (i = 0; i < filter->input_count; i++) @{
@end example
@item
The case statement is always located at the same level as the switch itself:
@@ -79,7 +79,8 @@ if (!pic || !picref)
goto fail;
@end example
@item
-Do not put spaces immediately inside parenthesis. @samp{if (ret)} is a valid
style; @samp{if ( ret )} is not.
+Do not put spaces immediately inside parenthesis. @samp{if (ret)} is
+a valid style; @samp{if ( ret )} is not.
@end itemize
There are the following guidelines regarding the indentation in files:
@@ -91,7 +92,8 @@ The TAB character is forbidden outside of Makefiles as is any
form of trailing whitespace. Commits containing either will be
rejected by the git repository.
@item
-You should try to limit your code lines to 80 characters; however, do so if
and only if this improves readability.
+You should try to limit your code lines to 80 characters; however, do so if
+and only if this improves readability.
@end itemize
The presentation is one inspired by 'indent -i4 -kr -nut'.
@@ -167,9 +169,10 @@ GCC statement expressions (@samp{(x = (@{ int y = 4; y;
@})}).
@end itemize
@subsection Naming conventions
-All names are using underscores (_), not CamelCase. For example,
@samp{avfilter_get_video_buffer} is
-a valid function name and @samp{AVFilterGetVideo} is not. The only exception
from this are structure names;
-they should always be in the CamelCase
+All names are using underscores (_), not CamelCase. For example,
+@samp{avfilter_get_video_buffer} is a valid function name and
+@samp{AVFilterGetVideo} is not. The only exception from this are structure
+names; they should always be in the CamelCase
There are following conventions for naming variables and functions:
@itemize @bullet
@@ -178,13 +181,15 @@ For local variables no prefix is required.
@item
For variables and functions declared as @code{static} no prefixes are required.
@item
-For variables and functions used internally by the library, @code{ff_} prefix
should be used.
+For variables and functions used internally by the library, @code{ff_} prefix
+should be used.
For example, @samp{ff_w64_demuxer}.
@item
-For variables and functions used internally across multiple libraries, use
@code{avpriv_}. For example,
-@samp{avpriv_aac_parse_header}.
+For variables and functions used internally across multiple libraries, use
+@code{avpriv_}. For example, @samp{avpriv_aac_parse_header}.
@item
-For exported names, each library has its own prefixes. Just check the existing
code and name accordingly.
+For exported names, each library has its own prefixes. Just check the existing
+code and name accordingly.
@end itemize
@subsection Miscellanous conventions
--
1.7.8.rc1
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
