# Which naming style for my C Library?

This topic is 430 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I am writing a open source single header C library and want to nail down the naming conventions.
Right now i have a mixed version, but i am not sure of people want to like this style, so i wanted to ask you if this is a good and readable style.

// ABC = Library Namespace

// Preprocessor defines:
#define ABC_MY_DEFINE_X

// Constants
#define ABC_MY_CONSTANT 42

// Macros:
#define ABC_MyMacro(a, b)

// Custom types
#if !defined(abc_global)
#define abc_global static
#define abc_inline inline
#define abc_internal static
#endif

#if !defined(abc_u64)
typedef unsigned long long abc_u64;
...
#endif

// Structs
typedef struct abc_MyAwesomeStruct {
abc_u64 someValue;
} abc_MyAwesomeStruct;

// Enums
typedef enum abc_MySpecialType {
abc_MySpecialType_First,
abc_MySpecialType_Second,
abc_MySpecialType_Third,
} abc_MySpecialType;

// Inline functions
abc_inline abc_f32 abcSquaredF32(abc_f32 value) {
abc_f32 result = value * value;
return (result);
}

// Exported Functions
abc_extern void abcMyAwesomeFunction(abc_u32 x, abc_u32 whatever);

// Function for internal use only
abc_internal void __abcMyInternalFunction(abc_u32 x, abc_u32 *ptr);

// Global variables for internal use only
abc_global abc_u32 whatEverValue = 0;


Also i use custom typedefs for integer and decimal types, is this okay? or should i use <stdint.h> only ?
Would be mapping the custom type to a stdint.h type a better way to go?

What i dont want is normal C naming conventions where everything except defines are lowercase + underscore.

I would use abc_MyAwesomeFunction, because its consistent to everything else.

What do you think? Edited by Finalspace

##### Share on other sites
Any* convention is fine as long as you are consistent.

*With a few exceptions

##### Share on other sites

I agree, as long as you're consistent it'll be fine.

##### Share on other sites

Looks like it's on me to be the annoying guy.

Also i use custom typedefs for integer and decimal types, is this okay? or should i use only ? Would be mapping the custom type to a stdint.h type a better way to go?

Just use the <stdint.h> definitions. They are nice, they are clean, they are understood everywhere. It's annoying extra definitions, especially because you have to memorize the new names, and second because you (the user) never know if that name that the library developer gave is equivalent with what he/she think. For example, some libraries have 'xyzFloat', but actually it's a 'double'. Or 'xyzNumber', and who the hell will know what that is. You have to look in the headers to make sure. Also, syntax highlighters have special highlighting for 'int32_t', 'uint32_t', etc.

I've noticed an increasing awareness, for some reason, of the types defined in <stdint.h> that wasn't there before.

What i dont want is normal C naming conventions where everything except defines are lowercase + underscore. Its so much nicer to read abcMyAwesomeFunction instead of abc_my_awesome_function.

Most C libraries will use that convention you mention you don't like. If I was a C# programmer, I would use camel-case, because it's everywhere in C#, but it would look off in C. I rarelly see camel-case style in C, and the few exceptions are from people that programmed in C# or C++ before (example).

I would use abc_MyAwesomeFunction, because its consistent to everything else.

I assume you are talking about the prefix. Prefix is good.

Continuing about typedefs. Some C programmers hate the use of typedef with structs and enums, others use it always, others are more flexible. I'm on the flexible side. If it's a game API, I will use. It's a non-critical kind of software and I want to make easier for my lazy user to declare a variable. If I'm writing a scientific software, I won't use typedef with struct or enum, as I'm worried about readability and reproducibility, and I don't give a fu*k if the other person think it's annoying to type "struct type_name variable_name;", I care about the damn readability and reproducibility. So, imo, it's double standard here.

Macros. Yeah, all upper-case. Macros imitating functions? I don't know if I love or I hate them. But, be careful when implementing them. Sometimes, their wrong implementation will cause the syntax that you put in them to not properly "match" the syntax of the location where the user called them. I don't have a example in hands, I just remember when I was once using one macro of one of those single-header libraries and I was getting compilation error because of how the syntax was written in the macro.

Edited by felipefsdev

##### Share on other sites

ust use the <stdint.h> definitions. They are nice, they are clean, they are understood everywhere. It's annoying extra definitions, especially because you have to memorize the new names, and second because you (the user) never know if that name that the library developer gave is equivalent with what he/she think. For example, some libraries have 'xyzFloat', but actually it's a 'double'. Or 'xyzNumber', and who the hell will know what that is. You have to look in the headers to make sure. Also, syntax highlighters have special highlighting for 'int32_t', 'uint32_t', etc.

I've noticed an increasing awareness, for some reason, of the types defined in <stdint.h> that wasn't there before.

That example about xyzFloat: If someone defines a float but uses a double as real type, its simply stupid.
But i agree to use standard types in a library.

But what about types which do not exists in the standard (Bool as 32 bit for example)?
typedef int32_t abc_b32;

Most C libraries will use that convention you mention you don't like. If I was a C# programmer, I would use camel-case, because it's everywhere in C#, but it would look off in C. I rarelly see camel-case style in C, and the few exceptions are from people that programmed in C# or C++ before (example).

That may be true, because i mostly code in object oriented languages, but i still dont like the lowercase style.
And what about SDL? SDL is C and has SDL_ as prefix and all names are camelcase as well.

Continuing about typedefs. Some C programmers hate the use of typedef with structs and enums, others use it always, others are more flexible. I'm on the flexible side. If it's a game API, I will use. It's a non-critical kind of software and I want to make easier for my lazy user to declare a variable. If I'm writing a scientific software, I won't use typedef with struct or enum, as I'm worried about readability and reproducibility, and I don't give a fu*k if the other person think it's annoying to type "struct type_name variable_name;", I care about the damn readability and reproducibility. So, imo, it's double standard here.

I hate typedefs, but using struct in C without typedef is not valid, isnt it?

This gives me a compile error in VC++ 2015 - in C Compiler not C++:
struct MyStruct {
uint32_t value;
};

But this works:
typedef struct MyStruct {uint32_t value;} MyStruct;Also enums have the same problem, it requires typedef as well in C.ust use the <stdint.h> definitions. They are nice, they are clean, they are understood everywhere. It's annoying extra definitions, especially because you have to memorize the new names, and second because you (the user) never know if that name that the library developer gave is equivalent with what he/she think. For example, some libraries have 'xyzFloat', but actually it's a 'double'. Or 'xyzNumber', and who the hell will know what that is. You have to look in the headers to make sure. Also, syntax highlighters have special highlighting for 'int32_t', 'uint32_t', etc.I've noticed an increasing awareness, for some reason, of the types defined in <stdint.h> that wasn't there before.That example about xyzFloat: If someone defines a float but uses a double as real type, its simply stupid.But i agree to use standard types in a library.But what about types which do not exists in the standard (Bool as 32 bit for example)?typedef int32_t abc_b32;  Most C libraries will use that convention you mention you don't like. If I was a C# programmer, I would use camel-case, because it's everywhere in C#, but it would look off in C. I rarelly see camel-case style in C, and the few exceptions are from people that programmed in C# or C++ before (example).That may be true, because i mostly code in object oriented languages, but i still dont like the lowercase style.And what about SDL? SDL is C and has SDL_ as prefix and all names are camelcase as well. Continuing about typedefs. Some C programmers hate the use of typedef with structs and enums, others use it always, others are more flexible. I'm on the flexible side. If it's a game API, I will use. It's a non-critical kind of software and I want to make easier for my lazy user to declare a variable. If I'm writing a scientific software, I won't use typedef with struct or enum, as I'm worried about readability and reproducibility, and I don't give a fu*k if the other person think it's annoying to type "struct type_name variable_name;", I care about the damn readability and reproducibility. So, imo, it's double standard here.I hate typedefs, but using struct in C without typedef is not valid, isnt it?This gives me a compile error in VC++ 2015 - in C Compiler not C++:struct MyStruct { uint32_t value; }; But this works:typedef struct MyStruct { uint32_t value; } MyStruct; Also enums have the same problem, it requires typedef as well.ust use the <stdint.h> definitions. They are nice, they are clean, they are understood everywhere. It's annoying extra definitions, especially because you have to memorize the new names, and second because you (the user) never know if that name that the library developer gave is equivalent with what he/she think. For example, some libraries have 'xyzFloat', but actually it's a 'double'. Or 'xyzNumber', and who the hell will know what that is. You have to look in the headers to make sure. Also, syntax highlighters have special highlighting for 'int32_t', 'uint32_t', etc.I've noticed an increasing awareness, for some reason, of the types defined in <stdint.h> that wasn't there before.That example about xyzFloat: If someone defines a float but uses a double as real type, its simply stupid.But i agree to use standard types in a library.But what about types which do not exists in the standard (Bool as 32 bit for example)?typedef int32_t abc_b32; Most C libraries will use that convention you mention you don't like. If I was a C# programmer, I would use camel-case, because it's everywhere in C#, but it would look off in C. I rarelly see camel-case style in C, and the few exceptions are from people that programmed in C# or C++ before (example).That may be true, because i mostly code in object oriented languages, but i still dont like the lowercase style.And what about SDL? SDL is C and has SDL_ as prefix and all names are camelcase as well.Continuing about typedefs. Some C programmers hate the use of typedef with structs and enums, others use it always, others are more flexible. I'm on the flexible side. If it's a game API, I will use. It's a non-critical kind of software and I want to make easier for my lazy user to declare a variable. If I'm writing a scientific software, I won't use typedef with struct or enum, as I'm worried about readability and reproducibility, and I don't give a fu*k if the other person think it's annoying to type "struct type_name variable_name;", I care about the damn readability and reproducibility. So, imo, it's double standard here.I hate typedefs, but using struct in C without typedef is not valid, isnt it?This gives me a compile error in VC++ 2015 - in C Compiler not C++:struct MyStruct { uint32_t value; }; But this works:typedef struct MyStruct { uint32_t value; } MyStruct; Also enums have the same problem, it requires typedef as well.-> Weird forum bug while saving... 
 1 
 Share this post Link to post Share on other sites 
 
 
 nemequ    147 nemequ Member 147 Posted May 12, 2017 // Custom types#if !defined(abc_global)#define abc_global static#define abc_inline inline#define abc_internal static#endif"single-header library" is a bit ambiguous; is it a library with 1 or more C files and a single header, or is the entire library contained in the header? Assuming the latter, all your functions should be static, and maybe some should be inline too (but keep in mind "inline" is a C99 thing, so if you want to support C89 you'll need to hide it behind an ifdef). If you omit the "static" you're likely to end up with collisions if multiple files include your library. abc_internal is pretty misleading. Usually when people see "internal" they think something marked with __attribute__((visibility("hidden"))) (GCC-like compilers); i.e., usable by the entire library/executable (not just the current compilation unit), but the symbol isn't exposed publicly to other code. I'm not sure what "global" is supposed to indicate.#if !defined(abc_u64)typedef unsigned long long abc_u64;...#endifThat's wrong on a lot of platforms. uint64_t is unsigned long long on Windows and OS X, but it's usually unsigned long on other platforms. This is a particularly infuriating issue because they're *mostly* compatible (same size, alignment, etc.), so the compiler won't generally warn you, except for when it will (like when you're working with pointers to abc_u64 instead of an actual abc_u64). in general you should use just use stdint.h, as others have mentioned. It's really nice to be able to use a standard name instead of having to remember a different name for each API, which may or may not be compatible with what you expect. The major exception is if you need the library to work with versions of MSVC older than 2013, since Microsoft didn't actually ship stdint.h (or a lot of other C99 features) until then. If that's the case, you should typedef your type to unsigned __int64 on MSVC, not unsigned long long. Unfortunately a lot of people stick to ancient versionsâ€¦ I routinely encounter people using 8.0 (circa 2005) and older. How much patience you have for them is up to you; mine is just about worn out. For everyone else it's usually pretty safe to assume stdint.h is available, but you can always check __STDC_VERSION__ and possibly the compiler version and/or libc version. If that's still not enough, the best solution I know of is to use limits.h to try to find a type with MIN/MAX values equal to what you expect, but that opens you back up to the issue of incompatible types. What i dont want is normal C naming conventions where everything except defines are lowercase + underscore. Its so much nicer to read abcMyAwesomeFunction instead of abc_my_awesome_function. I would use abc_MyAwesomeFunction, because its consistent to everything else. One very common convention (used by glib, among lots of others), is CamelCase for types, UPPER_CASE for macros, and lower_case_with_underscores for functions. So you would have#define ABC_FOO 1729 typedef struct { uint64_t value } AbcBar; void abc_baz(void); Mixing notations (i.e., abc_MyAwesomeFunction instead of AbcMyAwesomeFunction, or abc_FOO instead of ABC_FOO) is pretty uncommon (and, IMHO, very annoying). I hate typedefs, but using struct in C without typedef is not valid, isnt it? Sure it is, C just has different name spaces for different types of identifiers. You just need to do something likestruct MyStruct { uint32_t value; }; void my_struct_set_value(struct MyStruct* my_struct, uint32_t value) { my_struct->value = value; } Note the "struct MyStruct" instead of just "MyStruct" on the function. Personally, I prefer to create typedefs, but there is something to be said for avoiding them; it does help improve code readability a bit. When you see "struct Foo", "enum Bar", or "union Baz" you at least have a good idea of what to expect. That's especially true for "enum Bar" since by convention the values will start with "BAR_". The reason I prefer typedefs is consistency; you can't really create aliases for structs in C other than typedefs, so there are situations where you have no choice but to *not* have the struct/union/enum keyword. Those cases aren't all that common, but IMHO consistency is much more important than avoiding typedefs. 1 Share this post Link to post Share on other sites ferreiradaselva    379 ferreiradaselva Member 379 Posted May 12, 2017   I hate typedefs, but using struct in C without typedef is not valid, isnt it? It should work without typedefs. Maybe it's the situation that @nemequ mentioned. If you don't use typedef, you should write the "struct" in the variable declaration. Or, you are trying to declare one struct inside another without forward declaration. Can't know for sure without more code, but it should work.   That may be true, because i mostly code in object oriented languages, but i still dont like the lowercase style. And what about SDL? SDL is C and has SDL_ as prefix and all names are camelcase as well. Yeah, naming style is pretty much an optional opinion. The number of libraries using lowercase is greater than the ones using camelcase. The only few that I know that use camelcase are SDL, GLFW and Chipmunk. If your library is good, people will use it anyway.   It's a good point what @nemequ raised about visual studio. I don't use VS for a long time, but I've used libraries from other people that wrote their code in VS, and was supposedly compilable on other compilers (gcc, mingw, clang), but weren't and I had to patch modifications. 1 Share this post Link to post Share on other sites jpetrie    13212 jpetrie GDNet Emeritus 13212 Posted May 12, 2017 abc_internal void __abcMyInternalFunction(abc_u32 x, abc_u32 *ptr); Identifiers starting with an underscore followed by an uppercase letter, as well as identifiers starting with a double underscore, are reserved for the implementation as defined in section 7.1.3 of the C standard. Defining any such identifiers yourself yields undefined behavior. 0 Share this post Link to post Share on other sites ferrous    6159 ferrous Member 6159 Posted May 12, 2017 My two cents, a non all upper case macro would drive me bonkers. Macros can be evil, and I like to know when I'm using them over a function.   2 Share this post Link to post Share on other sites SBD    161 SBD Member 161 Posted May 13, 2017 (edited) Just a quick correction to this statement: The major exception is if you need the library to work with versions of MSVC older than 2013, since Microsoft didn't actually ship stdint.h (or a lot of other C99 features) until then stdint.h was first supported/supplied in Visual Studio 2010, so while Microsoft was behind the ball on this, it's been in there for some time now. Edited May 13, 2017 by SBD 0 Share this post Link to post Share on other sites 
 Prev 1 2 Next Page 1 of 2   Sign in to follow this   Followers 0 
 Go To Topic Listing General and Gameplay Programming Advertisement 
 Advertisement Popular Tags 2D 3D Advice Animation C# C++ Character Design DX11 Education GameMaker Gameplay General HTML5 Javascript Learning Marketing Mobile Music OpenGL Optimization PC Pixel Unity Unreal Popular Contributors Week Month Year All Time 1 Rutin 23 2 Hodgman 22 3 JoeJ 20 4 Scouting Ninja 16 5 lawnjelly 15 Show More Advertisement Popular Now 29 C++ Where can I find the source code for "Programming a Multiplayer FPS in DirectX"? By rjhwinner03Started Monday at 12:52 PM 41 How to react when people say my game looks like shit? By EddieKStarted Sunday at 04:30 PM 23 Combine 2 Physics objects By CacksStarted Saturday at 02:35 PM 13 C++ Simple trig problem driving me crazy By Guy Leonard ThomasStarted Friday at 08:46 PM 13 OpenGL vertices for rotation By MannyMoeStarted Thursday at 09:07 PM Forum Statistics Total Topics 631741 Total Posts 3001978 GameDev.net GameDev.net Articles GameDev.net Event Coverage GameDev.net Forums GameDev.net Blogs GameDev.net Gallery GameDev.net News GameDev.net Projects GDNet Chat All Activity Search In Everywhere This Forum This Topic More options... Find results that contain... All of my search term words Any of my search term words Find results in... Content titles and body Content titles only Home Forums Programming General and Gameplay Programming Which naming style for my C Library? 
 
 
 × Existing user? Sign In Sign Up Browse Back Articles & Tutorials Back All Categories Audio Business Game Design Industry Programming Visual Arts Columns Back GameDev Unboxed Event Coverage Back All Events Game Developers Conference Power Up Digital Games Conference GameDev.Market Links News Podcasts Back All Podcasts Game Dev Loadout Archive Community Back Beginners Back Beginners Group Beginners Forum Beginners Resources Blogs Calendar Chat Forums Back All Forums Audio Business Game Design Programming Visual Arts Community GameDev Challenges Affiliates Topical Workshops Gallery Groups Back For Beginners GameDev Challenges All Groups Projects Back All Projects Games Game Assets Game Mods Developer Tools Store Careers Back Contractors Hobby Projects Game Jobs Back Browse on GameDev.Jobs Post a Job Members Back Chat GDNet+ Membership Guidelines Leaderboard Online Users Awards Search Back All Activity My Activity Streams Back Latest Topics Featured Blogs Search var ipsDebug=false;var CKEDITOR_BASEPATH='//www.gamedev.net/applications/core/interface/ckeditor/ckeditor/';var ipsSettings={cookie_path:"/",cookie_prefix:"ips4_",cookie_ssl:true,upload_imgURL:"",message_imgURL:"",notification_imgURL:"",baseURL:"//www.gamedev.net/",jsURL:"//www.gamedev.net/applications/core/interface/js/js.php",csrfKey:"5f21e5c28da54d67bf3d624f30a0efcb",antiCache:"2a361a8a02",disableNotificationSounds:false,useCompiledFiles:true,links_external:true,memberID:0,analyticsProvider:"ga",viewProfiles:true,mapProvider:'google',mapApiKey:"AIzaSyAeT7tk3vnWWmbgVISkLpbhkQvekG19rHM",}; ips.setSetting('date_format',jQuery.parseJSON('"mm\/dd\/yy"'));ips.setSetting('date_first_day',jQuery.parseJSON('0'));ips.setSetting('remote_image_proxy',jQuery.parseJSON('1'));ips.setSetting('ipb_url_filter_option',jQuery.parseJSON('"none"'));ips.setSetting('url_filter_any_action',jQuery.parseJSON('"allow"'));ips.setSetting('bypass_profanity',jQuery.parseJSON('0'));ips.setSetting('emoji_style',jQuery.parseJSON('"native"'));ips.setSetting('emoji_shortcodes',jQuery.parseJSON('"1"'));ips.setSetting('emoji_ascii',jQuery.parseJSON('"1"'));ips.setSetting('emoji_cache',jQuery.parseJSON('"1"'));ips.setSetting('quickSearchDefault',jQuery.parseJSON('"all"'));ips.setSetting('quickSearchMinimum',jQuery.parseJSON('3'));ips.setSetting('quickSearchShowAdv',jQuery.parseJSON('true'));ips.setSetting('quickSearchIn',jQuery.parseJSON('"title"')); { "@context": "http://schema.org", "@type": "DiscussionForumPosting", "url": "https://www.gamedev.net/forums/topic/688626-which-naming-style-for-my-c-library/", "discussionUrl": "https://www.gamedev.net/forums/topic/688626-which-naming-style-for-my-c-library/", "name": "Which naming style for my C Library?", "headline": "Which naming style for my C Library?", "text": "I am writing a open source single header C library and want to nail down the naming conventions.Right now i have a mixed version, but i am not sure of people want to like this style, so i wanted to ask you if this is a good and readable style.\u00a0\n// ABC = Library Namespace\n \n// Preprocessor defines:\n#define ABC_MY_DEFINE_X\n\n// Constants\n#define ABC_MY_CONSTANT 42\n \n// Macros:\n#define ABC_MyMacro(a, b)\n\n// Custom types\n#if !defined(abc_global)\n#define abc_global static\n#define abc_inline inline\n#define abc_internal static\n#endif\n\n#if !defined(abc_u64)\ntypedef unsigned long long abc_u64;\n...\n#endif\n\n// Structs\ntypedef struct abc_MyAwesomeStruct {\n abc_u64 someValue;\n} abc_MyAwesomeStruct;\n\n// Enums\ntypedef enum abc_MySpecialType {\n abc_MySpecialType_First,\n abc_MySpecialType_Second,\n abc_MySpecialType_Third,\n} abc_MySpecialType;\n\n// Inline functions\nabc_inline abc_f32 abcSquaredF32(abc_f32 value) {\n abc_f32 result = value * value;\n return (result);\n}\n\n// Exported Functions\nabc_extern void abcMyAwesomeFunction(abc_u32 x, abc_u32 whatever);\n\n// Function for internal use only\nabc_internal void __abcMyInternalFunction(abc_u32 x, abc_u32 *ptr);\n\n// Global variables for internal use only\nabc_global abc_u32 whatEverValue = 0;\n\nAlso i use custom typedefs for integer and decimal types, is this okay? or should i use \u0026lt;stdint.h\u0026gt; only ?Would be mapping the custom type to a stdint.h type a better way to go?What i dont want is normal C naming conventions where everything except defines are lowercase + underscore.Its so much nicer to read abcMyAwesomeFunction instead of abc_my_awesome_function.I would use abc_MyAwesomeFunction, because its consistent to everything else.What do you think?", "dateCreated": "2017-05-12T06:10:25+0000", "datePublished": "2017-05-12T06:10:25+0000", "pageStart": 1, "pageEnd": 2, "image": "https://www.gamedev.net/uploads/profile/photo-thumb-197089.jpg", "author": { "@type": "Person", "name": "Finalspace", "image": "https://www.gamedev.net/uploads/profile/photo-thumb-197089.jpg", "url": "https://www.gamedev.net/profile/197089-finalspace/" }, "interactionStatistic": [ { "@type": "InteractionCounter", "interactionType": "http://schema.org/ViewAction", "userInteractionCount": 1362 }, { "@type": "InteractionCounter", "interactionType": "http://schema.org/CommentAction", "userInteractionCount": 15 }, { "@type": "InteractionCounter", "interactionType": "http://schema.org/FollowAction", "userInteractionCount": 15 } ], "comment": [ { "@type": "Comment", "url": "https://www.gamedev.net/forums/topic/688626-which-naming-style-for-my-c-library/?do=findComment\u0026comment=5342285", "author": { "@type": "Person", "name": "Finalspace", "image": "https://www.gamedev.net/uploads/profile/photo-thumb-197089.jpg", "url": "https://www.gamedev.net/profile/197089-finalspace/" }, "dateCreated": "2017-05-12T06:10:25+0000", "text": "I am writing a open source single header C library and want to nail down the naming conventions.Right now i have a mixed version, but i am not sure of people want to like this style, so i wanted to ask you if this is a good and readable style.\u00a0\n// ABC = Library Namespace\n \n// Preprocessor defines:\n#define ABC_MY_DEFINE_X\n\n// Constants\n#define ABC_MY_CONSTANT 42\n \n// Macros:\n#define ABC_MyMacro(a, b)\n\n// Custom types\n#if !defined(abc_global)\n#define abc_global static\n#define abc_inline inline\n#define abc_internal static\n#endif\n\n#if !defined(abc_u64)\ntypedef unsigned long long abc_u64;\n...\n#endif\n\n// Structs\ntypedef struct abc_MyAwesomeStruct {\n abc_u64 someValue;\n} abc_MyAwesomeStruct;\n\n// Enums\ntypedef enum abc_MySpecialType {\n abc_MySpecialType_First,\n abc_MySpecialType_Second,\n abc_MySpecialType_Third,\n} abc_MySpecialType;\n\n// Inline functions\nabc_inline abc_f32 abcSquaredF32(abc_f32 value) {\n abc_f32 result = value * value;\n return (result);\n}\n\n// Exported Functions\nabc_extern void abcMyAwesomeFunction(abc_u32 x, abc_u32 whatever);\n\n// Function for internal use only\nabc_internal void __abcMyInternalFunction(abc_u32 x, abc_u32 *ptr);\n\n// Global variables for internal use only\nabc_global abc_u32 whatEverValue = 0;\n\nAlso i use custom typedefs for integer and decimal types, is this okay? or should i use \u0026lt;stdint.h\u0026gt; only ?Would be mapping the custom type to a stdint.h type a better way to go?What i dont want is normal C naming conventions where everything except defines are lowercase + underscore.Its so much nicer to read abcMyAwesomeFunction instead of abc_my_awesome_function.I would use abc_MyAwesomeFunction, because its consistent to everything else.What do you think?", "mainEntityOfPage": "https://www.gamedev.net/forums/topic/688626-which-naming-style-for-my-c-library/" }, { "@type": "Comment", "url": "https://www.gamedev.net/forums/topic/688626-which-naming-style-for-my-c-library/?do=findComment\u0026comment=5342287", "author": { "@type": "Person", "name": "fastcall22", "image": "https://www.gamedev.net/uploads/monthly_2017_06/icon_300px_4bpp_crushed.thumb.png.9504131335f27da644ab6409b31a967f.png", "url": "https://www.gamedev.net/profile/135301-fastcall22/" }, "dateCreated": "2017-05-12T06:26:55+0000", "text": "Any* convention is fine as long as you are consistent.*With a few exceptions", "mainEntityOfPage": "https://www.gamedev.net/forums/topic/688626-which-naming-style-for-my-c-library/" }, { "@type": "Comment", "url": "https://www.gamedev.net/forums/topic/688626-which-naming-style-for-my-c-library/?do=findComment\u0026comment=5342290", "author": { "@type": "Person", "name": "evolutional", "image": "https://www.gamedev.net/uploads/profile/photo-26476.jpg", "url": "https://www.gamedev.net/profile/26476-evolutional/" }, "dateCreated": "2017-05-12T07:23:28+0000", "text": "I agree, as long as you\u0027re consistent it\u0027ll be fine.\u00a0", "mainEntityOfPage": "https://www.gamedev.net/forums/topic/688626-which-naming-style-for-my-c-library/" }, { "@type": "Comment", "url": "https://www.gamedev.net/forums/topic/688626-which-naming-style-for-my-c-library/?do=findComment\u0026comment=5342294", "author": { "@type": "Person", "name": "felipefsdev", "image": "https://www.gamedev.net/uploads/profile/photo-thumb-245740.png", "url": "https://www.gamedev.net/profile/245740-ferreiradaselva/" }, "dateCreated": "2017-05-12T08:35:29+0000", "text": "Looks like it\u0027s on me to be the annoying guy.\n\u00a0\n\u00a0\n\n\u00a0\nJust use the \u0026lt;stdint.h\u0026gt; definitions. They are nice, they are clean, they are understood everywhere. It\u0027s annoying extra definitions, especially because you have to memorize the new names, and second because you (the user) never know if that name that the library developer gave is equivalent with what he/she think. For example, some libraries have \u0027xyzFloat\u0027, but actually it\u0027s a \u0027double\u0027. Or \u0027xyzNumber\u0027, and who the hell will know what that is. You have to look in the headers to make sure. Also, syntax highlighters have special highlighting for \u0027int32_t\u0027, \u0027uint32_t\u0027, etc.\nI\u0027ve noticed an increasing awareness, for some reason, of the types defined in \u0026lt;stdint.h\u0026gt; that wasn\u0027t there before.\u00a0\n\u00a0\n\u00a0\n\nMost C libraries will use that convention you mention you don\u0027t like. If I was a C# programmer, I would use camel-case, because it\u0027s everywhere in C#, but it would look off in C. I rarelly see camel-case style in C, and the few exceptions are from people that programmed in C# or C++ before (example).\n\u00a0\n\u00a0\n\n\u00a0\nI assume you are talking about the prefix. Prefix is good.\n\u00a0\nContinuing about typedefs. Some C programmers hate the use of typedef with structs and enums, others use it always, others are more flexible. I\u0027m on the flexible side. If it\u0027s a game API, I will use. It\u0027s a non-critical kind of software and I want to make easier for my lazy user to declare a variable. If I\u0027m writing a scientific software, I won\u0027t use typedef with struct or enum, as I\u0027m worried about readability and reproducibility, and I don\u0027t give a fu*k if the other person think it\u0027s annoying to type \"struct type_name variable_name;\", I care about the damn\u00a0readability and\u00a0reproducibility. So, imo, it\u0027s double standard here.\n\u00a0\nMacros. Yeah, all upper-case. Macros\u00a0imitating functions? I don\u0027t know if I love or I hate them. But, be careful when implementing them. Sometimes, their wrong implementation will cause the syntax that you put in them to not properly \"match\" the syntax of the location where the user called them. I don\u0027t have a example in hands, I just remember when I was once using one macro of one of those single-header libraries and I was getting compilation error because of how the syntax was written in the macro.\n", "mainEntityOfPage": "https://www.gamedev.net/forums/topic/688626-which-naming-style-for-my-c-library/" }, { "@type": "Comment", "url": "https://www.gamedev.net/forums/topic/688626-which-naming-style-for-my-c-library/?do=findComment\u0026comment=5342306", "author": { "@type": "Person", "name": "Finalspace", "image": "https://www.gamedev.net/uploads/profile/photo-thumb-197089.jpg", "url": "https://www.gamedev.net/profile/197089-finalspace/" }, "dateCreated": "2017-05-12T10:57:30+0000", "text": "That example about xyzFloat: If someone defines a float but uses a double as real type, its simply stupid.But i agree to use standard types in a library.But what about types which do not exists in the standard (Bool as 32 bit for example)?typedef int32_t abc_b32;\nThat may be true, because i mostly code in object oriented languages, but i still dont like the lowercase style.And what about SDL? SDL is C and has SDL_ as prefix and all names are camelcase as well.I hate typedefs, but using struct in C without typedef is not valid, isnt it?This gives me a compile error in VC++ 2015 - in C Compiler not C++:struct MyStruct {\nuint32_t value;\n};\nBut this works:typedef struct MyStruct {uint32_t value;} MyStruct;Also enums have the same problem, it requires typedef as well in C.That example about xyzFloat: If someone defines a float but uses a double as real type, its simply stupid.But i agree to use standard types in a library.But what about types which do not exists in the standard (Bool as 32 bit for example)?\ntypedef int32_t abc_b32;\n\u00a0That may be true, because i mostly code in object oriented languages, but i still dont like the lowercase style.And what about SDL? SDL is C and has SDL_ as prefix and all names are camelcase as well.\u00a0I hate typedefs, but using struct in C without typedef is not valid, isnt it?This gives me a compile error in VC++ 2015 - in C Compiler not C++:\nstruct MyStruct {\nuint32_t value;\n};\nBut this works:\ntypedef struct MyStruct {\nuint32_t value;\n} MyStruct;\nAlso enums have the same problem, it requires typedef as well.That example about xyzFloat: If someone defines a float but uses a double as real type, its simply stupid.But i agree to use standard types in a library.But what about types which do not exists in the standard (Bool as 32 bit for example)?\ntypedef int32_t abc_b32;\n\nThat may be true, because i mostly code in object oriented languages, but i still dont like the lowercase style.And what about SDL? SDL is C and has SDL_ as prefix and all names are camelcase as well.I hate typedefs, but using struct in C without typedef is not valid, isnt it?This gives me a compile error in VC++ 2015 - in C Compiler not C++:\nstruct MyStruct {\nuint32_t value;\n};\nBut this works:\ntypedef struct MyStruct {\nuint32_t value;\n} MyStruct;\nAlso enums have the same problem, it requires typedef as well.-\u0026gt; Weird forum bug while saving...\n", "mainEntityOfPage": "https://www.gamedev.net/forums/topic/688626-which-naming-style-for-my-c-library/" }, { "@type": "Comment", "url": "https://www.gamedev.net/forums/topic/688626-which-naming-style-for-my-c-library/?do=findComment\u0026comment=5342356", "author": { "@type": "Person", "name": "nemequ", "image": "https://secure.gravatar.com/avatar/d46bf32204da4a8edefbeeaee969c794?d=https://www.gamedev.net/uploads/monthly_2017_08/N.png.5b1a78fa9cb155e2bdcaf29b4a0197e9.png", "url": "https://www.gamedev.net/profile/228731-nemequ/" }, "dateCreated": "2017-05-12T19:22:31+0000", "text": "// Custom types#if !defined(abc_global)#define abc_global static#define abc_inline inline#define abc_internal static#endif\"single-header library\" is a bit ambiguous; is it a library with 1 or more C files and a single header, or is the entire library contained in the header? Assuming the latter, all your functions should be static, and maybe some should be inline too (but keep in mind \"inline\" is a C99 thing, so if you want to support C89 you\u0027ll need to hide it behind an ifdef). If you omit the \"static\" you\u0027re likely to end up with collisions if multiple files include your library.\nabc_internal is pretty misleading. Usually when people see \"internal\" they think something marked with __attribute__((visibility(\"hidden\"))) (GCC-like compilers); i.e., usable by the entire library/executable (not just the current compilation unit), but the symbol isn\u0027t exposed publicly to other code. I\u0027m not sure what \"global\" is supposed to indicate.#if !defined(abc_u64)typedef unsigned long long abc_u64;...#endifThat\u0027s wrong on a lot of platforms. uint64_t is unsigned long long on Windows and OS X, but it\u0027s usually unsigned long on other platforms. This is a particularly infuriating issue because they\u0027re *mostly* compatible (same size, alignment, etc.), so the compiler won\u0027t generally warn you, except for when it will (like when you\u0027re working with pointers to abc_u64 instead of an actual abc_u64).\nin general you should use just use stdint.h, as others have mentioned. It\u0027s really nice to be able to use a standard name instead of having to remember a different name for each API, which may or may not be compatible with what you expect. The major exception is if you need the library to work with versions of MSVC older than 2013, since Microsoft didn\u0027t actually ship stdint.h (or a lot of other C99 features) until then. If that\u0027s the case, you should typedef your type to unsigned __int64 on MSVC, not unsigned long long. Unfortunately a lot of people stick to ancient versions\u00e2\u20ac\u00a6 I routinely encounter people using 8.0 (circa 2005) and older. How much patience you have for them is up to you; mine is just about worn out.\nFor everyone else it\u0027s usually pretty safe to assume stdint.h is available, but you can always check __STDC_VERSION__ and possibly the compiler version and/or libc version. If that\u0027s still not enough, the best solution I know of is to use limits.h to try to find a type with MIN/MAX values equal to what you expect, but that opens you back up to the issue of incompatible types.\n\nOne very common convention (used by glib, among lots of others), is CamelCase for types, UPPER_CASE for macros, and lower_case_with_underscores for functions. So you would have#define ABC_FOO 1729\ntypedef struct { uint64_t value } AbcBar;\nvoid abc_baz(void);\nMixing notations (i.e., abc_MyAwesomeFunction instead of AbcMyAwesomeFunction, or abc_FOO instead of ABC_FOO) is pretty uncommon (and, IMHO, very annoying).\n\nSure it is, C just has different name spaces for different types of identifiers. You just need to do something likestruct MyStruct { uint32_t value; };\nvoid my_struct_set_value(struct MyStruct* my_struct, uint32_t value) {\n my_struct-\u0026gt;value = value;\n}\nNote the \"struct MyStruct\" instead of just \"MyStruct\" on the function.\nPersonally, I prefer to create typedefs, but there is something to be said for avoiding them; it does help improve code readability a bit. When you see \"struct Foo\", \"enum Bar\", or \"union Baz\" you at least have a good idea of what to expect. That\u0027s especially true for \"enum Bar\" since by convention the values will start with \"BAR_\".\nThe reason I prefer typedefs is consistency; you can\u0027t really create aliases for structs in C other than typedefs, so there are situations where you have no choice but to *not* have the struct/union/enum keyword. Those cases aren\u0027t all that common, but IMHO consistency is much more important than avoiding typedefs.", "mainEntityOfPage": "https://www.gamedev.net/forums/topic/688626-which-naming-style-for-my-c-library/" }, { "@type": "Comment", "url": "https://www.gamedev.net/forums/topic/688626-which-naming-style-for-my-c-library/?do=findComment\u0026comment=5342359", "author": { "@type": "Person", "name": "felipefsdev", "image": "https://www.gamedev.net/uploads/profile/photo-thumb-245740.png", "url": "https://www.gamedev.net/profile/245740-ferreiradaselva/" }, "dateCreated": "2017-05-12T19:47:22+0000", "text": "It should work without typedefs. Maybe it\u0027s the situation that @nemequ mentioned. If you don\u0027t use typedef, you should write the \"struct\" in the variable declaration. Or, you are trying to declare one struct inside another without forward declaration. Can\u0027t know for sure without more code, but it should work.\n\u00a0\n\n\nYeah, naming style is pretty much an optional opinion. The number of libraries using lowercase is greater than the ones using camelcase. The only few that I know that use camelcase are SDL, GLFW and Chipmunk. If your library is good, people will use it anyway.\n\u00a0\nIt\u0027s a good point what @nemequ raised about visual studio. I don\u0027t use VS for a long time, but I\u0027ve used libraries from other people that wrote their code in VS, and was supposedly compilable on other compilers (gcc, mingw, clang), but weren\u0027t and I had to patch modifications.\n", "mainEntityOfPage": "https://www.gamedev.net/forums/topic/688626-which-naming-style-for-my-c-library/" }, { "@type": "Comment", "url": "https://www.gamedev.net/forums/topic/688626-which-naming-style-for-my-c-library/?do=findComment\u0026comment=5342360", "author": { "@type": "Person", "name": "Josh Petrie", "image": "https://www.gamedev.net/uploads/profile/photo-thumb-46720.jpeg", "url": "https://www.gamedev.net/profile/46720-josh-petrie/" }, "dateCreated": "2017-05-12T19:47:25+0000", "text": "Identifiers starting with an underscore followed by an uppercase letter, as well as identifiers starting with a double underscore, are reserved for the implementation as defined in section 7.1.3 of the C standard. Defining any such identifiers yourself yields undefined behavior.\n", "mainEntityOfPage": "https://www.gamedev.net/forums/topic/688626-which-naming-style-for-my-c-library/" }, { "@type": "Comment", "url": "https://www.gamedev.net/forums/topic/688626-which-naming-style-for-my-c-library/?do=findComment\u0026comment=5342370", "author": { "@type": "Person", "name": "ferrous", "image": "https://secure.gravatar.com/avatar/cf27ef625e1354a371938266ff8d7368?d=https://www.gamedev.net/uploads/monthly_2017_08/F.png.5cb0cb7b4caa54b3a8bbd9cc2d95045b.png", "url": "https://www.gamedev.net/profile/216013-ferrous/" }, "dateCreated": "2017-05-12T22:06:18+0000", "text": "My two cents, a non all upper case macro would drive me bonkers. Macros can be evil, and I like to know when I\u0027m using them over a function. \u00a0", "mainEntityOfPage": "https://www.gamedev.net/forums/topic/688626-which-naming-style-for-my-c-library/" }, { "@type": "Comment", "url": "https://www.gamedev.net/forums/topic/688626-which-naming-style-for-my-c-library/?do=findComment\u0026comment=5342380", "author": { "@type": "Person", "name": "SBD", "image": "https://secure.gravatar.com/avatar/16c0556f1636613d1d396b9ae71a3b1a?d=https://www.gamedev.net/uploads/monthly_2017_08/S.png.57544500a9ea58be0fd733bfbf8d7301.png", "url": "https://www.gamedev.net/profile/235081-sbd/" }, "dateCreated": "2017-05-13T01:24:19+0000", "text": "Just a quick correction to this statement:\n\nstdint.h was first supported/supplied in Visual Studio 2010, so while Microsoft was behind the ball on this, it\u0027s been in there for some time now.\n", "mainEntityOfPage": "https://www.gamedev.net/forums/topic/688626-which-naming-style-for-my-c-library/" } ] } { "@context": "http://www.schema.org", "@type": "WebSite", "name": "GameDev.net", "url": "https://www.gamedev.net/", "potentialAction": { "type": "SearchAction", "query-input": "required name=query", "target": "https://www.gamedev.net/search/?q={query}" }, "inLanguage": [ { "@type": "Language", "name": "English (USA)", "alternateName": "en-US" } ] } { "@context": "http://www.schema.org", "@type": "Organization", "name": "GameDev.net", "url": "https://www.gamedev.net/", "logo": "https://www.gamedev.net/uploads/themes/monthly_2017_04/gamedev-logo-2017-368x76.png.e986e41d566ff6c90485a5304985ed5f.png", "address": { "@type": "PostalAddress", "streetAddress": "", "addressLocality": null, "addressRegion": null, "postalCode": null, "addressCountry": null } } { "@context": "http://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "item": { "@id": "https://www.gamedev.net/forums/", "name": "Forums" } }, { "@type": "ListItem", "position": 2, "item": { "@id": "https://www.gamedev.net/forums/forum/4-programming/", "name": "Programming" } }, { "@type": "ListItem", "position": 3, "item": { "@id": "https://www.gamedev.net/forums/forum/9-general-and-gameplay-programming/", "name": "General and Gameplay Programming" } } ] } { "@context": "http://schema.org", "@type": "ContactPage", "url": "https://www.gamedev.net/contact/" } Important Information By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.   I accept We are the game development community. Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up! Sign me up!