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'.
can be generated automatically. All nontrivial functions should have a comment
above them explaining what the function does, even if it is just one sentence.
All structures and their member variables should be documented, too.
+
+Avoid Qt-style and similar Doxygen syntax with @code{!} in it, i.e. replace
+@code{//!} with @code{///} and similar. Also @@ syntax should be employed
+for markup commands, i.e. use @code{@@param} and not @code{\param}.
+
@example
/**
* @@file
@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
+a valid function name and @samp{AVFilterGetVideo} is not. The exception from this are type names, like
+for example structs and enums; they should always be in the CamelCase
+
There are following conventions for naming variables and functions:
@itemize @bullet
@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
should also be avoided if they don't make the code easier to understand.
@end itemize
+@subsection Editor configuration
+In order to configure Vim to follow FFmpeg formatting conventions, paste
+the following snippet into your @file{.vimrc}:
+@example
+" indentation rules for FFmpeg: 4 spaces, no tabs
+set expandtab
+set shiftwidth=4
+set softtabstop=4
+" allow tabs in Makefiles
+autocmd FileType make set noexpandtab shiftwidth=8 softtabstop=8
+" Trailing whitespace and tabs are forbidden, so highlight them.
+highlight ForbiddenWhitespace ctermbg=red guibg=red
+match ForbiddenWhitespace /\s\+$\|\t/
+" Do not highlight spaces at the end of line while typing on that line.
+autocmd InsertEnter * match ForbiddenWhitespace /\t\|\s\+\%#\@@<!$/
+@end example
+
+For Emacs, add these roughly equivalent lines to your @file{.emacs.d/init.el}:
+@example
+(setq c-default-style "k&r")
+(setq-default c-basic-offset 4)
+(setq-default indent-tabs-mode nil)
+(setq-default show-trailing-whitespace t)
+@end example
+
@section Development Policy
@enumerate
always check values read from some untrusted source before using them
as array index or other risky things.
@item
- Remember to check if you need to bump versions for the specific libav
+ Remember to check if you need to bump versions for the specific libav*
parts (libavutil, libavcodec, libavformat) you are changing. You need
to change the version integer.
Incrementing the first component means no backward compatibility to
Use the patcheck tool of FFmpeg to check your patch.
The tool is located in the tools directory.
-Run the @ref{Regression Tests} before submitting a patch in order to verify
+Run the @ref{Regression tests} before submitting a patch in order to verify
it does not cause unexpected problems.
Patches should be posted as base64 encoded attachments (or any other
be rejected. Instead, submit significant changes or new features as
separate patches.
+@anchor{Regression tests}
@section Regression tests
Before submitting a patch (or committing to the repository), you should at least
test that you did not break anything.
-Running 'make fate' accomplishes this, please see @file{doc/fate.txt} for details.
+Running 'make fate' accomplishes this, please see @url{fate.html} for details.
[Of course, some patches may change the results of the regression tests. In
this case, the reference results of the regression tests shall be modified