doc: break some long lines in developer.texi

This commit is contained in:
Luca Barbato 2011-12-03 01:18:28 +01:00
parent 2cf74eca70
commit a0338b598b

View File

@ -49,8 +49,8 @@ mailing list.
The code is written in K&R C style. That means the following: The code is written in K&R C style. That means the following:
@itemize @bullet @itemize @bullet
@item @item
The control statements are formatted by putting space betwen the statement and parenthesis The control statements are formatted by putting space betwen the statement
in the following way: and parenthesis in the following way:
@example @example
for (i = 0; i < filter->input_count; i++) @{ for (i = 0; i < filter->input_count; i++) @{
@end example @end example
@ -79,7 +79,8 @@ if (!pic || !picref)
goto fail; goto fail;
@end example @end example
@item @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 @end itemize
There are the following guidelines regarding the indentation in files: 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 form of trailing whitespace. Commits containing either will be
rejected by the git repository. rejected by the git repository.
@item @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 @end itemize
The presentation is one inspired by 'indent -i4 -kr -nut'. 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 @end itemize
@subsection Naming conventions @subsection Naming conventions
All names are using underscores (_), not CamelCase. For example, @samp{avfilter_get_video_buffer} is All names are using underscores (_), not CamelCase. For example,
a valid function name and @samp{AVFilterGetVideo} is not. The only exception from this are structure names; @samp{avfilter_get_video_buffer} is a valid function name and
they should always be in the CamelCase @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: There are following conventions for naming variables and functions:
@itemize @bullet @itemize @bullet
@ -178,13 +181,15 @@ For local variables no prefix is required.
@item @item
For variables and functions declared as @code{static} no prefixes are required. For variables and functions declared as @code{static} no prefixes are required.
@item @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}. For example, @samp{ff_w64_demuxer}.
@item @item
For variables and functions used internally across multiple libraries, use @code{avpriv_}. For example, For variables and functions used internally across multiple libraries, use
@samp{avpriv_aac_parse_header}. @code{avpriv_}. For example, @samp{avpriv_aac_parse_header}.
@item @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 @end itemize
@subsection Miscellanous conventions @subsection Miscellanous conventions