celix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pepijn Noltes <pepijnnol...@gmail.com>
Subject Re: coding guidelines
Date Tue, 02 Sep 2014 18:33:39 GMT
Hi All,

On Mon, Sep 1, 2014 at 9:18 PM, Alexander Broekhuis
<a.broekhuis@gmail.com> wrote:
> 2014-09-01 20:04 GMT+02:00 Bjoern Petri <bjoern.petri@sundevil.de>:
>> Hi everyone,
>> Some weeks ago, Jan mentioned that we are missing coding guidelines and I
>> think he has a point there. As I first approach to address this, I think it
>> would be a good idea to agree on a certain code style guide.
> I agree. Now there are more people involved I think it is needed as well.
>> As this is mostly a subjective matter and therefore difficult to decide, I
>> would propose that we might take a look what is out there,  choose a coding
>> style which is close to our already existing code and check whether we
>> can/should adjust this to our needs.
> While looking out there is good, I have been following a code style
> already. So perhaps we can use that as a starting point?
>> For example, the Apache httpd code styleguide
>> https://httpd.apache.org/dev/styleguide.html could be used by us as well?
>> What do you think?
> I do follow the Eclipse K&R style with one change, instead of tabs I use
> spaces. I do know most C/C++ developers prefer the opening brace on a new
> line, I even think officially K&R has this. But the Eclipse version does
> place it on the same line, which is what I prefer.

THe K&R style, as far as I know, only addresses formatting and
indentation.  I think clear documentation how we use an (sort of)
object oriented programming style (mapping OSGi classes), what the
guidelines are for services (e.g. using an opaque pointer as first
entry), the general use of opaque pointer, how/when we use typedefs
and how we handle errors and return values can be very helpful.
Although some parts are described in the documentation/design
documentation/mapping pages, I can understand that not everything is
directly clear for new developers.

I would be helpful I somebody could point out what aspect of "code
style" is least clear from just looking at the code, than we could
focus on documenting that. Because in my opinion the K&R style should
be clear just with the current code.

> Anyway, I'm open for other ideas, so let's see what others have to say.
> Whatever we choose, let's make sure when we decide on something, that we
> update all code and examples.


View raw message