[haiku-development] Re: Coding style conflicting with API

  • From: Jonathan Schleifer <js-haiku-development@xxxxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Sun, 18 Nov 2012 13:41:36 +0100

Am 18.11.2012 um 13:19 schrieb Ingo Weinhold:

> Using the k* style for constants doesn't have much to do with the 
> all-upper-case style looking aged. I believe the convention stems from the 
> OpenTracker coding style, which our current coding style has been derived 
> from. I guess the purpose of the different style for constants is that they 
> can be discriminated from macros. The k* indicates constant, just as s* 
> indicates static and f* attributes.

Is this coding style already set in stone, or can we still adjust this to make 
an exception for constants that are part of an API?

> This has little to do with the public API. We can't use kConstant for public 
> constants, since they wouldn't be in any reserved namespace.

We could use kBSomeConstant, to further improve ugliness, of course ;).

> We'll either have to come up with a new namespace or stick with B_*. No 
> decision has been made in this respect yet.

I'd stick with B_* and even use uppercase constants to have some consistency. 
Any coding style is better than the mix of different coding styles. If this 
weren't Haiku but any other project, I would have instantly stopped reading the 
code after seeing the file quoted before and said "This code is crap, they 
can't even match the coding style in the same code block. No need to waste my 
time with something that can't even keep the coding style in one block.". But, 
luckily, this is Haiku ;).

> There are other namespace issues, BTW. All C functions and structures pollute 
> the public namespace, so they really should be renamed.

Are there some coming from BeOS that have no prefix?


Other related posts: