Good OO naming scheme for c

Question

I find a lot of functions that are o-style in c (nothing contains fancy macros or function pointers, just struct + functions that take this type of structure as the first argument. Is my_func_my_type a good circuit for such things? If I use this should I try to be consistent? what if one of my function names becomes> 20 characters?> 25? Do I have to stick to the style, even then?

Also what is a good naming scheme for constructors / initializers / destructors? Is there something beter, then new_my_type, init_my_type, free_my_type?

PS Is there a good name for this / self ptr or should I just name the first parameter of the OO function, as in a regular function (to_init, some_guy, ect.)

Answer 1

I would personally use a scheme compatible with most C libraries that put the library name as a function prefix. Which would give, for example, void MyObject_MyFunction . For building / demolition, you can stay the same and use MyObject_Construct , MyObject_Destroy . I would say that a name doesn't really matter if you stay consistent.

Answer 2

"good" is a bit subjective, but I think that the easiest way is to choose a specific scheme (including the name of the structure in the method) and strictly follow it. Indeed, I try to avoid long function names, although if the function is so complex that it needs such a long name, it is probably time to reorganize it, divide it into subfunctions, etc. I also do not use underlining, but it is a matter of taste. An example of what is used here:

 typedef struct Discriminator { //members } Discriminator; DiscriminatorConstruct( Discriminator* p ); DiscriminatorDestruct( Discriminator* p ); DiscriminatorFunctionA( Discriminator* p, int arg1, int arg2 ); 

Answer 3

Due to the lack of one in the C world, C ++ provides a useful use case for naming its functions:

 [[namespace::...]struct::]function 

In C, there is nothing like namespaces, but you can just think of them and model them as prefixes shared by related structures. For readability, this helps visually separate the individual naming components. If you like to use underscores in your functions, you can consider two underscores as a separator, otherwise one is possible. (Technically, two underscores can be reserved for implementation, but I have never seen a single implementation identifier, which was not an underscore prefix, imposed a double underscore inside).

Keeping names close to C ++ also helps programmers cover both languages, and translate the code back and forth if necessary. Similarly, C ++ terminology can be accepted: a constructor, a destructor, perhaps a new one and delete (although these names may become incorrect if the C code is ported to C ++, but continues to use free / malloc).

IMHO, consistent and understandable naming saves more trouble than long identifiers, but if something gets pain, look for a localized workaround like a macro, a built-in wrapper function, a function pointer, etc.