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

  • From: Ingo Weinhold <ingo_weinhold@xxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Sun, 18 Nov 2012 13:19:27 +0100

On 11/18/2012 12:58 PM, Jonathan Schleifer wrote:
Am 18.11.2012 um 12:43 schrieb pulkomandy:

Yes. Uppercase looks very 1980, and Be didn't do everything right.
So, all R5 constants stay with B_, and all new constants use k.

How does uppercase look 1980? And lot's of other APIs use uppercase for 
constants as well - to be honest, I can't think of any that uses kSomeConstant. 
Wouldn't it be way better to keep it consistent with the BeAPI then?

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.

The API will be broken in R2, and far beyond just renaming constants.
For now we'll have to live with the style mix for this.

So the constants will be changed definitely?

What would one do then if you want to write code that works with R1 and R2?

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'll either have to come up with a new namespace or stick with B_*. No decision has been made in this respect yet.

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

CU, Ingo


Other related posts: