s4:libcli/rap: the caller should get talloc children from call->ndr_pull_{param,data}

[kai/samba.git] / README.Coding

diff --git a/README.Coding b/README.Coding
index b1ac2fe6666c48429e66c3dac74d45ae522c39e5..8416290861026cd262916f2e8df2872644999516 100644 (file)
--- a/README.Coding
+++ b/README.Coding
@@ -16,11 +16,19 @@ style should never outweigh coding itself and so the guidelines
 described here are hopefully easy enough to follow as they are very
 common and supported by tools and editors.
 
 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 prog_guide4.txt, is the Linux kernel
+The basic style for C code, 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, with a few
 exceptions as mentioned below.
 
 coding style (See Documentation/CodingStyle in the kernel source tree). This
 closely matches what most Samba developers use already anyways, with a few
 exceptions as mentioned below.
 

+The coding style for Python code is documented in PEP8,
+http://www.python.org/pep/pep8 (with spaces). 
+If you have ever worked on another free software Python project, you are
+probably already familiar with it.
+
+We try to stay compatible with Python 2.4, so please don't rely on any
+features that were introduced later, such as the "with" statement.
+

 But to save you the trouble of reading the Linux kernel style guide, here
 are the highlights.
 
 But to save you the trouble of reading the Linux kernel style guide, here
 are the highlights.
 


@@ -94,11 +102,12 @@ Comments
 --------
 
 Comments should always use the standard C syntax.  C++
 --------
 
 Comments should always use the standard C syntax.  C++

-style comments are not currently allowed. The lines before
-a comment should be empty. If the comment directly belongs
-to the following code, there should be no empty line after
-the comment. In case the comment contains a summary of
-mutliple following code blogs.
+style comments are not currently allowed.
+
+The lines before a comment should be empty. If the comment directly
+belongs to the following code, there should be no empty line
+after the comment, except if the comment contains a summary
+of multiple following code blocks.

 
 This is good:
 
 
 This is good: