[Open-scap] OVAL API Source
Steve Grubb
sgrubb at redhat.com
Tue Mar 3 22:26:00 UTC 2009
On Tuesday 03 March 2009 03:15:20 pm Dennis Dimant wrote:
> Up to this point, contributions from this group have not particularly
> adhered to one global coding style.
The coding style people submit really seems to be what kind of projects you've
been working on lately.
> If the Red Hat group has a document that they would like to nominate for
> this purpose, that'd be great. Otherwise, I can compile a list of
> recommendations.
I don't think we have a document. But I have some suggestions for C. These are
not _all_ hard requirements and we can be flexible. Python, perl, and C++
bindings can all be coded in a way that is very much in line with the typical
style of those languages. Most of us at Red Hat have some familiarity with
the Linux kernel. Its programming style is widely accepted. You can read
about it here:
http://www.linuxjournal.com/article/5780
But just to name a few things for C: defines & enums all caps, function names
and variables lowercase with underscore separating words. Function & variable
names should reflect what they do. No one letter variables unless its for
iteration or indexing and is obvious in use. typedef is OK to use, should end
with _t to designate that its a type. I personally don't like to see
typedef'ed pointers, I'd rather see a pointer to a typedef. IOW, pointer_t
src is bad, pointer_t *src is better.
Tabs should be 8 chars. I think we can come up with some indent settings to
make the indentation and curly braces style consistent.
The following would not be in the kernel style guide:
Any functions or variables that show up as public symbols should be name
spaced with a prefix so as not to conflict with common names in applications.
(What that prefix would be is open to discussion.) Internal functions shared
between obj files should have private bindings to prevent LD_PRELOAD
overriding of functions.
Library functions shall not call abort, but shall return error codes. Asserts
may be used but we should call out in the docs how to enable them for debug
mode. IOW, the default should be that NDEBUG is defined as if a production
build is being done.
Test cases would be nice so that "make check" runs the test cases.
-Steve
More information about the Open-scap-list
mailing list