summaryrefslogtreecommitdiff
path: root/README.Coding
diff options
context:
space:
mode:
Diffstat (limited to 'README.Coding')
-rw-r--r--README.Coding67
1 files changed, 33 insertions, 34 deletions
diff --git a/README.Coding b/README.Coding
index 52ecf0e102..c1b6641a5a 100644
--- a/README.Coding
+++ b/README.Coding
@@ -1,6 +1,7 @@
-##
-## Coding conventions in the Samba 3 tree
-##
+Coding conventions in the Samba tree
+------------------------------------
+
+.. contents::
===========
Quick Start
@@ -14,15 +15,13 @@ style should never outweigh coding itself and so the the guidelines
described here are hopefully easy enough to follow as they are very
common and supported by tools and editors.
-The basic style, also mentioned in the SAMBA_4_0/prog_guide.txt is the
-Linux kernel coding style (See Documentation/CodingStyle in the kernel
-source tree). The closely matches what most Samba developers use already
-anyways.
+The basic style, also mentioned in prog_guide4.txt, is the Linux kernel coding
+style (See Documentation/CodingStyle in the kernel source tree). This closely
+matches what most Samba developers use already anyways.
But to save you the trouble of reading the Linux kernel style guide, here
are the highlights.
-
* Maximum Line Width is 80 Characters
The reason is not for people with low-res screens but rather sticking
to 80 columns prevents you from easily nesting more than one level of
@@ -59,14 +58,14 @@ Vi
--
(Thanks to SATOH Fumiyasu <fumiyas@osstech.jp> for these hints):
-For the basic vi editor including with all variants of *nix, add the
+For the basic vi editor including with all variants of \*nix, add the
following to $HOME/.exrc:
set tabstop=8
set shiftwidth=8
For Vim, the following settings in $HOME/.vimrc will also deal with
-displaying trailing whitespace:
+displaying trailing whitespace::
if has("syntax") && (&t_Co > 2 || has("gui_running"))
syntax on
@@ -91,7 +90,7 @@ FAQ & Statement Reference
Comments
--------
-Comments should always use the standard C syntax. I.e. /* ... */. C++
+Comments should always use the standard C syntax. C++
style comments are not currently allowed.
@@ -145,7 +144,7 @@ The exception to the ending rule is when the closing brace is followed by
another language keyword such as else or the closing while in a do..while
loop.
-Good examples:
+Good examples::
if (x == 1) {
printf("good\n");
@@ -162,7 +161,7 @@ Good examples:
printf("also good\n");
} while (1);
-Bad examples:
+Bad examples::
while (1)
{
@@ -173,33 +172,33 @@ Goto
----
While many people have been academically taught that goto's are fundamentally
-evil, then can greatly enhance readability and reduce memory leaks when used
+evil, they can greatly enhance readability and reduce memory leaks when used
as the single exit point from a function. But in no Samba world what so ever
is a goto outside of a function or block of code a good idea.
-Good Examples:
-
-int function foo(int y)
-{
- int *z = NULL;
- int ret = 0;
+Good Examples::
- if ( y < 10 ) {
- z = malloc(sizeof(int)*y);
- if (!z) {
- ret = 1;
- goto done;
+ int function foo(int y)
+ {
+ int *z = NULL;
+ int ret = 0;
+
+ if ( y < 10 ) {
+ z = malloc(sizeof(int)*y);
+ if (!z) {
+ ret = 1;
+ goto done;
+ }
}
- }
- print("Allocated %d elements.\n", y);
+ print("Allocated %d elements.\n", y);
- done:
- if (z)
- free(z);
+ done:
+ if (z)
+ free(z);
- return ret;
-}
+ return ret;
+ }
Checking Pointer Values
@@ -207,13 +206,13 @@ Checking Pointer Values
When invoking functions that return pointer values, either of the following
are acceptable. Use you best judgement and choose the more readable option.
-Remember that many other people will review it.
+Remember that many other people will review it.::
if ((x = malloc(sizeof(short)*10)) == NULL ) {
fprintf(stderr, "Unable to alloc memory!\n");
}
-or
+or::
x = malloc(sizeof(short)*10);
if (!x) {