Archived

This topic is now archived and is closed to further replies.

Houdini

Different naming conventions for multiple libraries issue

Recommended Posts

Houdini    266
I''m designing a new core library to be used in creating games, but I''ve ran into a design issue I''m not certain how to deal with. I want to use C++ stream classes and STL containers/iterators. The problem that arises, however, is that the function naming convention for these classes are different than what I''m using in my own classes. What makes things worse, is not only do I use these classes but I also derive a bunch of new classes from these old ones (ie, database record containers, new streams, etc). So now I''m stuck with a bunch of "3rd party" classes that have a different naming convention, PLUS a bunch of my classes that inherit those different naming conventions. How do you handle this? Do you just stick with using 2 or 3 different naming conventions all over your code, or do you write wrapper classes, or perhaps use the Adapter pattern, to conform them to your standard? - Houdini

Share this post


Link to post
Share on other sites
Void    126
Why waste time with a wrapper that just changes the naming convention?

The only reason why I would write a wrapper layer is to get exception safety. (especially with C libraries)

Share this post


Link to post
Share on other sites
Houdini    266
quote:

Why waste time with a wrapper that just changes the naming convention?



One of the most important things you can do for a large project, is to create a naming standard. It would be total chaos if you have 5 programmers all naming their functions differently (ie, do_this(), DoThis(), doThis(), DO_THIS(), dothis(), etc). Nobody would remember what naming style each function uses, thus you''d be continually checking the function declaration before using that function.

However, I''m still up in the air on whether this is worth it, at least for streams and STL. Writting my own wrapper classes for streams means that I can''t use cout when trying to print a user defined class (my classes would have an >> operator for my wrapper OStream class, and not one for the normal ostream class).

And obviously you can''t use those new streams with programs that have already been written, but you could if you used the normal streams (ie, I could redirect cout in another program to use my WinDebugStream as long as it derived from the normal ostream, and not my wrapper OStream class).

Because of this huge downfall, I''m still undecided on whether to use wrappers to keep naming styles uniform...

quote:

The only reason why I would write a wrapper layer is to get exception safety.



I could think of another reason. To convert a classes interface into one you can use. For example, to make a game that uses both Direct3D and OpenGL the easiest way is to write a pure virtual generic graphics class and create wrapper classes for both Direct3D and OpenGL to use this same interface. This way you can switch between API''s by changing just one line of code.


- Houdini

Share this post


Link to post
Share on other sites
LilBudyWizer    491
I don''t really see the problem. What is the point in hiding the fact that you are using the STL? Would someone that knows the STL really appreciate having to remember that this is really that instead. If it is a library then who knows what the naming convention used by the programmer calling it is much less what other APIs they might have used as well and what the naming conventions of those are. Simply use a naming convention that makes it clear in their code that when they call your code that is what they are doing. Oh yeah, this comes from that library. That is what matters. Everything blending together into one big blur isn''t the best of all possible worlds.

Share this post


Link to post
Share on other sites
Oluseyi    2115
If you insist on using your own conventions, typedef the declarations and be done with it:

class MyFunkyClass;
// hide MSVC 255 character debug output limit warning on STL type names:
#pragma warning( disable : 4786 )
#include <vector>
typedef ostream OStream;
typedef vector<MyFunkyClass> MyFunkyClassVector;
#pragma warning( default : 4786 )


[EDIT} Standards compliance...



I wanna work for Microsoft!

Edited by - Oluseyi on November 7, 2001 5:32:37 PM

Share this post


Link to post
Share on other sites
Houdini    266
Oluseyi, using typedef doesn''t really solve my problem as the functions are still all lowercase and I capitalize the first letter of all words in my functions.

LilBudyWizer, I see your point and I''d agree with you if those libraries classes stayed in those libraries.

But a problem arises, for example, when I decide to create a database recordset class. This class would allow you to call query the database for a bunch of records, and iterate through those records. It makes total sense to derive Recordset from STL''s list class and use STL''s iterators to iterate between records.

But now my own class (Recordset) has a different naming convention than my other classes. And now what happens when I want to add my own functions to Recordset, like a filter function. Do I keep with the derived classes naming convention, and name it set_filter() or do I use my normal convention and name it SetFilter()?

Sigh. It sucks when my own classes have mixed naming conventions but I guess there isn''t a neat way around it except to use wrappers, which the more that I think about it, I''d rather not do.


- Houdini

Share this post


Link to post
Share on other sites
Oluseyi    2115
quote:
Original post by Houdini
Oluseyi, using typedef doesn''t really solve my problem as the functions are still all lowercase and I capitalize the first letter of all words in my functions.

Okay... I still don''t see the big deal, but here goes nothing:

quote:
...a problem arises, for example, when I decide to create a database recordset class. This class would allow you to call query the database for a bunch of records, and iterate through those records. It makes total sense to derive Recordset from STL''s list class and use STL''s iterators to iterate between records.

But now my own class (Recordset) has a different naming convention than my other classes. And now what happens when I want to add my own functions to Recordset, like a filter function. Do I keep with the derived classes naming convention, and name it set_filter() or do I use my normal convention and name it SetFilter()?


class Recordset : private list<type> // if you want specialization
// otherwise template <class T> class Recordset : private list<T>
{
public:
// declare your own functions (with your own conventions) here
private:
// inherited functions are private
};
//
template <class T> void Insert(T &data)
{
::insert(data);
}

Will this work? I haven''t tried it, but even if it does it involves a ton of work in declaring your own public versions of all functions you inherit as private (plus you''ll lose function objects/public objects and have to redefine them as well).



I wanna work for Microsoft!

Share this post


Link to post
Share on other sites
Void    126
quote:
Original post by Houdini
But a problem arises, for example, when I decide to create a database recordset class. This class would allow you to call query the database for a bunch of records, and iterate through those records. It makes total sense to derive Recordset from STL''s list class and use STL''s iterators to iterate between records.



Does it make total sense? Prefer aggregation( containment ) to inheritance.

From what I gather from your post, you want to do a wrappers (just to conform to your library convention. (Eg, a wrapper around std::string)

That is a waste of time.

If you are doing an interface, then it''s a different matter. (For example, an abstract graphics API layer). Those kind of wrappers are unavoidable.

Share this post


Link to post
Share on other sites
Shannon Barber    1681
I''d say that a RecordSet HasA list of records, and make it''s methods twiddle a private list. It sounds like you''re working with the ADO, so I''d say stick to thier naming conventions for the interface methods, your convetion for the implementation public and protected ones, and the STL for the implementation code.

You can inherit a class privately and "publish" (as the technique is called) some of the methods.

Magmai Kai Holmlor
- Not For Rent

Share this post


Link to post
Share on other sites
Houdini    266
Oluseyi, you hit the nail on the head. That''s exactly what the Adapter pattern is, privately inheriting from a class and creating new function names that call the private classes functions.

The only reason I hesitated with that approach is for streams. If I do that for streams then existing classes that implement the << and >> operators already expect an ostream not an OStream class. This is what was tripping me up.

But now I realize that while it''s OK to use Adapter pattern for 3rd party libs, it''s a bad idea to use them for streams because they are part of the C++ language, thus causing problems such as stated above.

I will use the Adapter pattern for STL but just derive normal classes from streams using my own naming technique for any new functions. This will result two function naming conventions for those derived classes, but since those classes are derived from streams which are part of the C++ language, programmers should be aware which functions are normal stream functions and which are new functions.

Void, I don''t believe it''s a waste of time. It doesn''t take much effort to do this, doesn''t result in any performance hit (use inline) and keeps all your classes using the same naming standards, which is very important in large projects.

Magmai, I disagree, I believe a Recordset IsA list of records. If I make it a HasA then I need to create methods for traversing and returning the individual records as well as creating my own iterator class for this. Doesn''t make sense when a list does this exact same thing.

You are right that I primarily work with ADO, but the recordset thing was really just an example, I wasn''t planning on actually creating such classes

Thanks for letting me bounce some ideas off you guys. I think I got a good idea on what I want to do now.


- Houdini

Share this post


Link to post
Share on other sites