X-Git-Url: http://www.privoxy.org/gitweb/?p=privoxy.git;a=blobdiff_plain;f=doc%2Fwebserver%2Fdeveloper-manual%2Findex.html;h=decc62d5b392221cad676258662ca6736a7a5bcf;hp=729a9596aeaea67ee579fcb2f19b32c1bfeba246;hb=d5bba1fd0bce2185b191b7a8280cae9a62c829d6;hpb=afdf7f7b2cbdff9a333ac73e0bdb74474015705d diff --git a/doc/webserver/developer-manual/index.html b/doc/webserver/developer-manual/index.html index 729a9596..decc62d5 100644 --- a/doc/webserver/developer-manual/index.html +++ b/doc/webserver/developer-manual/index.html @@ -1,342 +1,184 @@ - Privoxy Developer Manual - + - + - - +
-

Privoxy Developer - Manual

- -

Copyright © 2001-2016 by Privoxy - Developers

- -

$Id: developer-manual.sgml,v 2.65 2016/01/23 - 11:58:58 fabiankeil Exp $

- +

Privoxy Developer Manual

+

Copyright + © 2001-2018 by Privoxy Developers

- - -

The developer manual provides guidance on coding, testing, - packaging, documentation and other issues of importance to those - involved with Privoxy development. - It is mandatory (and helpful!) reading for anyone who wants to join - the team. Note that it's currently out of date and may not be + +

The developer manual provides guidance on coding, testing, packaging, documentation and other issues of + importance to those involved with Privoxy development. It is mandatory (and + helpful!) reading for anyone who wants to join the team. Note that it's currently out of date and may not be entirely correct. As always, patches are welcome.

- -

Please note that this document is constantly evolving. This copy - represents the state at the release of version 3.0.24. You can find - the latest version of the this manual at http://www.privoxy.org/developer-manual/. Please have a - look at the contact section in the user manual if you are interested - in contacting the developers.

+

Please note that this document is constantly evolving. This copy represents the state at the release of + version 3.0.29. You can find the latest version of the this manual at https://www.privoxy.org/developer-manual/. + Please have a look at the contact + section in the user manual if you are interested in contacting the developers.


-
Table of Contents
-
1. Introduction
-
-
1.1. Quickstart to - Privoxy Development
+
1.1. Quickstart to Privoxy Development
- -
2. The CVS Repository
- +
2. The Git Repository
-
2.1. Access to CVS
- -
2.2. Branches
- -
2.3. CVS Commit - Guidelines
+
2.1. Access to Git
+
2.2. Branches
+
2.3. Git Commit Guidelines
-
3. Documentation Guidelines
-
-
3.1. Quickstart to Docbook - and SGML
- -
3.2. Privoxy Documentation Style
- -
3.3. Privoxy Custom - Entities
+
3.1. Quickstart to Docbook and SGML
+
3.2. Privoxy Documentation + Style
+
3.3. Privoxy Custom Entities
-
4. Coding Guidelines
-
4.1. Introduction
-
4.2. Using Comments
-
-
4.2.1. Comment, Comment, - Comment
- -
4.2.2. Use blocks for - comments
- -
4.2.3. Keep Comments on their - own line
- -
4.2.4. Comment each logical - step
- -
4.2.5. Comment All Functions - Thoroughly
- -
4.2.6. Comment at the end of - braces if the content is more than one screen length
+
4.2.1. Comment, Comment, Comment
+
4.2.2. Use blocks for comments
+
4.2.3. Keep Comments on their own line
+
4.2.4. Comment each logical step
+
4.2.5. Comment All Functions Thoroughly
+
4.2.6. Comment at the end of braces if the content is more than one screen + length
-
4.3. Naming Conventions
-
4.3.1. Variable Names
-
4.3.2. Function Names
- -
4.3.3. Header file - prototypes
- -
4.3.4. Enumerations, and - #defines
- +
4.3.3. Header file prototypes
+
4.3.4. Enumerations, and #defines
4.3.5. Constants
-
4.4. Using Space
-
-
4.4.1. Put braces on a line by - themselves.
- -
4.4.2. ALL control statements - should have a block
- -
4.4.3. Do not belabor/blow-up - boolean expressions
- -
4.4.4. Use white space freely - because it is free
- -
4.4.5. Don't use white space - around structure operators
- -
4.4.6. Make the last brace of a - function stand out
- -
4.4.7. Use 3 character - indentions
+
4.4.1. Put braces on a line by themselves.
+
4.4.2. ALL control statements should have a block
+
4.4.3. Do not belabor/blow-up boolean expressions
+
4.4.4. Use white space freely because it is free
+
4.4.5. Don't use white space around structure operators
+
4.4.6. Make the last brace of a function stand out
+
4.4.7. Use 3 character indentions
-
4.5. Initializing
-
-
4.5.1. Initialize all - variables
+
4.5.1. Initialize all variables
-
4.6. Functions
-
-
4.6.1. Name functions that - return a boolean as a question.
- -
4.6.2. Always specify a return - type for a function.
- -
4.6.3. Minimize function calls - when iterating by using variables
- -
4.6.4. Pass and Return by Const - Reference
- -
4.6.5. Pass and Return by - Value
- -
4.6.6. Names of include - files
- -
4.6.7. Provide multiple - inclusion protection
- -
4.6.8. Use `extern "C"` when - appropriate
- -
4.6.9. Where Possible, Use - Forward Struct Declaration Instead of Includes
+
4.6.1. Name functions that return a boolean as a question.
+
4.6.2. Always specify a return type for a function.
+
4.6.3. Minimize function calls when iterating by using variables
+
4.6.4. Pass and Return by Const Reference
+
4.6.5. Pass and Return by Value
+
4.6.6. Names of include files
+
4.6.7. Provide multiple inclusion protection
+
4.6.8. Use `extern "C"` when appropriate
+
4.6.9. Where Possible, Use Forward Struct Declaration Instead of + Includes
- -
4.7. General Coding - Practices
- +
4.7. General Coding Practices
-
4.7.1. Turn on - warnings
- -
4.7.2. Provide a default case - for all switch statements
- -
4.7.3. Try to avoid falling - through cases in a switch statement.
- -
4.7.4. Don't mix size_t and - other types
- -
4.7.5. Declare each variable - and struct on its own line.
- -
4.7.6. Use malloc/zalloc - sparingly
- -
4.7.7. The Programmer Who Uses - 'malloc' is Responsible for Ensuring 'free'
- -
4.7.8. Add loaders to the - `file_list' structure and in order
- -
4.7.9. "Uncertain" new code - and/or changes to existing code, use XXX
+
4.7.1. Turn on warnings
+
4.7.2. Provide a default case for all switch statements
+
4.7.3. Try to avoid falling through cases in a switch statement.
+
4.7.4. Don't mix size_t and other types
+
4.7.5. Declare each variable and struct on its own line.
+
4.7.6. Use malloc/zalloc sparingly
+
4.7.7. The Programmer Who Uses 'malloc' is Responsible for Ensuring + 'free'
+
4.7.8. Add loaders to the `file_list' structure and in order
+
4.7.9. "Uncertain" new code and/or changes to existing code, use + XXX
- -
4.8. Addendum: Template for files - and function comment blocks:
+
4.8. Addendum: Template for files and function comment blocks:
-
5. Testing Guidelines
-
-
5.1. Testplan for - releases
- -
5.2. Test - reports
+
5.1. Testplan for releases
+
5.2. Fuzzing Privoxy
-
6. Releasing a New Version
-
-
6.1. Version - numbers
- -
6.2. Before the - Release: Freeze
- -
6.3. Building and - Releasing the Packages
- +
6.1. Version numbers
+
6.2. Before the Release
+
6.3. Building and Releasing the Packages
-
6.3.1. Note on - Privoxy Packaging
- -
6.3.2. Source Tarball
- -
6.3.3. SuSE, - Conectiva or Red Hat RPM
- -
6.3.4. OS/2
- -
6.3.5. Solaris
- -
6.3.6. Windows
- -
6.3.7. Debian
- -
6.3.8. Mac OS - X
- -
6.3.9. FreeBSD
+
6.3.1. Note on Privoxy Packaging
+
6.3.2. Source Tarball
+
6.3.3. SuSE, Conectiva or Red Hat RPM
+
6.3.4. OS/2
+
6.3.5. Solaris
+
6.3.6. Windows
+
6.3.7. Debian
+
6.3.8. Mac OS X
+
6.3.9. FreeBSD
- -
6.4. Uploading and - Releasing Your Package
- -
6.5. After the - Release
+
6.4. Uploading and Releasing Your Package
+
6.5. After the Release
-
7. Update the Webserver
-