Give all entities (classes, objects, functions, variables etc. - but begin from DB tables and their fields!) meaningful, descriptive, self-explanatory names which will produce easily understandable code with no (or minimum) need in comments.
Use the words "per" and "by" - they really simplify a developer's life! A variable's name cowsPerFarm is better than totalCows, and a function name RetrieveCityByCountry tell us more than RetrieveCity, especially if it doesn't have parameters which supply the "by what" information. These words also really simplify writing and reading of financial calculations!
Don't use abstract words like "actual" and "total" in database fields and variables names - they will madden you forcing to spend extra time trying to understand what is "actual", what is "not actual" and "total" for which grouping level it is. Is totalCows field total per barn? per farm? per village? per province? per country? per the Universe? If, for example, per farm, then how will you name the total per village? It's also "total"! These words are meaningless without the context which is obvious when a data architect is creating the table ("it's easy - it's total per what I am thinking about just now!"), but foggy later - sometimes it's very difficult to see that context looking at a variable surrounded by hundreds lines of code. So, don't write simply "total" - write "total PER WHAT"!
Only exact definitions that produce no (or minimum) questions, even if that results in longer names!
*** BAD code: ***
- Code: Select all
totalSalary = actualSalary * totalHours;
*** GOOD code: ***
- Code: Select all
salaryPerDay = salaryPerHour * hoursPerDay;
If you don't create DB objects, print out this aricle and pin it in the cubicle of the data architect.
- Site Admin
- Posts: 111
- Joined: 19 Feb 2013, 20:33
Return to Art of Naming
Who is online
Users browsing this forum: No registered users and 1 guest