X-Git-Url: http://git.samba.org/?a=blobdiff_plain;f=README.Coding;h=956a733a4ce77e7d4b7dd4ceec0dd6449bc3a323;hb=a93c9e23f932c753d32302d153fe172746ee1181;hp=b1ac2fe6666c48429e66c3dac74d45ae522c39e5;hpb=1c2ff4563d0fd7e1d00117eef051f5554daaba14;p=obnox%2Fsamba%2Fsamba-obnox.git diff --git a/README.Coding b/README.Coding index b1ac2fe6666..956a733a4ce 100644 --- 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. -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. +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. @@ -94,11 +102,12 @@ Comments -------- 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: @@ -358,3 +367,13 @@ Bad Example: ret = some_function_my_name(get_some_name()); ... +Control-Flow changing macros +---------------------------- + +Macros like NT_STATUS_NOT_OK_RETURN that change control flow +(return/goto/etc) from within the macro are considered bad, because +they look like function calls that never change control flow. Please +do not use them in new code. + +The only exception is the test code that depends repeated use of calls +like CHECK_STATUS, CHECK_VAL and others.