How do you name your personal libraries?

Question

I'm pretty bad with naming things.

The only name I can every generically come up with is 'helper'. Say, if I have a header file that contains helping functions for manipulating paths, I tend to put it inside my "helper" directory and call it "path-helper.hpp" or something like that.

Obviouslly, that's a bad naming convention. :)

I want to have a consistent naming scheme for my folder (and namespace) which I can use to always refer to my own headers and libraries, but I have trouble finding names that are easy to type or remember (like boost)... so I end up calling some of them "helper" or "stdext" or whatnot, which isn't a great idea.

How do you find names for your libraries that are easy to remember and easy to type, and which aren't too generic (like "helper" or "std" or "stdext" or the like)?

Any suggestions on how to go about doing this?

Answer 1

Try to group helper functions thematically and include the theme in the library name. A library name like "helper" may by too generic, but a name like "PathHelper", "FileIOHelper" says pretty much about what functions one can expect in that lib (personally, I prefer "...Utilities", but that's just a matter of personal taste). For example, I have lib names like "MathUtilities", "StringUtilities" "ConfigUtilities", "DBUtilities" and so on.

Of course, for bigger libraries in our team we use names without any generic term at the end. And to be honest, we have also a library called "Common" for some functions and classes which don't group well under a specific topic name. But we try to keep that lib small.

Answer 2

Generally, it's an organic process for me.

My namespaces tend to mirror my folder names, primarily because I think it's easier to find things that way.

Corporate projects generally have a company prefix in front of the namespace, and for personal projects I toggle between project-prefix.folder and just folder for the names.

The "main" folders tend to be obvious for their name, and are generally related to their function - "Foo". For larger projects, I'll break out the main folder to reflect the major programming paradigm I may be following. So for MVVM, I would have "Foo.View", "Foo.ViewModel", and "Foo.Model" as example names.

Invariably, helper functions that don't fit anywhere else start to creep into the project. I'll start with a "common" or "utilities" type folder to first land them. "Helpers", "Base", and "Core" would work just as well for an initial landing place.

I try to name my functions based upon the Subject and / or Action that they perform. So I could have a PathManager, PathChecker, etc... Oftentimes, I know I'll have several Actions related to a subject, so I'll name the class after the Subject and add methods as needed. A thesaurus can come in handy here.

I have found a high correlation between ease of naming an object and how well I can describe what the function is supposed to do. One of my personal checkpoints is that if I'm struggling to name something then that means I need to reflect upon what the function is actually supposed to be doing. Once I fix the functionality issues, the name comes easily.

As I gather more helper functions, I'll migrate them to their own folder and / or namespace. Whether they get a folder off of the root project or whether they get a sub-folder to the utility folder depends upon the nature and quantity of the functions.

Answer 3

Similarly to GlenH7, I tend to have a "-misc" library, where org is a three or four letter abbreviation for whoever my current employer happens to be.

Any new random functions get put there until enough of them have accumulated for a pattern to emerge. At that point, I group them together and pull out related functions into more-sensibly-named libraries, refactoring client code as needed.

Sometimes a bit of discipline has been required to keep the size of the library manageable, but these days my *-misc libraries tend to stay pretty small.

(I also always have a "devauto" and a "testauto" library that contain "meta-level" functions intended to support development and test automation).

Answer 4

If it were me, I would just have a path library(well more likely it would be a filesystem library that contained a path component). It would provide the exact interface I need to get the job done. Sure 90% of it would be a thin wrapper around boost.filesystem or whatever language filesystem lib there was, but my code would only ever see this nice consistent library. No trying to remember if that function was in X, X-helper, X-utils, or X-ext. If X needs help then it is time to go fix X, not invent new random locations for code.

Answer 5

I'm also very bad at this. My pragmatic approach is to use enrich the name by date and/or project and/or location till I come up with a reasonable name.

I know for another person it's impossible to read, but myself I can quickly recognize them. And most of these libraries end up single use anyway for me.