File/Project Naming

File and project naming has been a massive debate at work lately as we teach newer employees the greatness of OOP. On my way home, I had an epiphany, and so I just had to write it out. So here is the best file naming reason/description you will ever read:

Your file names should describe your work without the developer having to open it to figure out what it does. In OOP, you should define your parts/pieces first, and then your object in individual classes. For example, you may find a class for Driver, Vehicle, Liabilities, and then one for Quote that incorporate the previous three. The names are meaningful and you do not need to even see the code to understand what is in them.

Now that file naming is covered, how about project naming? In all honesty, I am less concerned with project names than file names. But, they are important none-the-less. Your projects should describe your collection of classes in as few words as you can muster together. For example, the above files might be under the project name “QuoteEngine”. Why? Cause they are the pieces that allow a quote to process and are likely to include the methods for actually submitting a quote as well.

Should your projects include acronyms such as DABL (Data Access/Business Layer)? I personally do not think so. If you have to physically describe it is the (Data Access/Business Layer) then your tiers are not neatly organized enough and you need to separate them better, or better define your classes to help resemble which layer you are in.

Well that is my two cents for the evening.