How do you reconcile common C++ naming conventions with those of the libraries

Question

Most C++ naming conventions dictate the use of camelCaseIdentifiers: names that start with an uppercase letter for classes (Person, Booking

Answer 1

Fav quote::

The best thing about standards is that there are so many to choose from!

My suggestion would be to take the library's convention that occurs in your company's code most often (probably the C++ library, which I believe boost sticks to as well), and make that your standard. Otherwise, you might as well not have one at all.

Answer 2

In the projects I am working on I follow to code conventions for my project. When I call something other I use API of that library.

I also would add that wrapping of library is a bad idea (there are a lot of them in the code base I am working on) because it is usually done by the developer who solve his own problem and as a rule it is inappropriate for usage by all other developers. From the other side high quality wrapping is expensive.

Answer 3

I seem to recall reading a long time ago that they choose to make the standard library different from the recommended coding convention on purpose, to avoid naming collisions. I can't find any reference that mentions that now, however. I remember reading that you shouldn't use leading lowercase letters in type names because they were reserved for the standard libraries. I assume something similar is going on with the use of underscores. I really don't see multiple naming conventions as a problem, since it clearly separates the standard code from code in your project. I always code stuff in my projects using capital camel case for types and lower camel case for methods/members. My current workplace uses capital camel case for methods in addition to types, which irks me greatly. But, they also like Hungarian warts, which even MS has disowned :P

Answer 4

I tend to be a perfectionist when it comes to code style, and this has always bothered me. I wish there were a universal standard, but there isn't. In my professional career, I have found that as long as the programmers on an individual project are consistent, that is the best you can hope for.

Ultimately, I think it comes down to knowing from which library a method, object, or function comes from. If you know that, then it becomes easy enough to remember which convention is used by that library, assuming the project doesn't include a lot of libraries. I have tried adapting my own code to match that of the libraries I use, but it is always a moving target and just frustrating in the end.

Answer 5

Well, since we can't change the way the standard libraries are implemented, I guess we'll have to live with it. As for reconciling - while writing some Win32 API stuff a while ago, I tried naming my own methods in PascalCasing as it's done in the API, but it just didn't feel right. So I went back to naming my methods in camelCase. I agree it's a mess, but the other option is to adapt your style to every new framework or library you use, and then there's the issue that you mention of having more than one library using different conventions in a single project. So my advice is - stick to what feels right for your own methods and classes. Or - when in corporate environment - stick to your company's best practices and guidelines.

Answer 6

Why the need to reconcile? As long as the code compiles, and you can get work done, don't worry about it.