Merging Conventions to Aid Readability thus Reducing Development Time
When programming in a mixed-language environment,
the naming conventions, formatting conventions, documentation conventions, and other conventions,
can be optimised for overall consistency and readability.
This may mean going against convention for one or more of the languages that’s part of the mix.
For Example…
in many classical Object Oriented and procedural languages,
routine names have an initial capital letter (PascalCase).
The convention in JavaScript is for routine names to have an initial lower case letter (camelCase),
unless the routine is a constructor (intended to be used with the new prefix).
When a constructor is invoked without the new prefix,
the constructors this will be bound to the global object,
rather than where it should be…
The functions execution context.
When invoked with the new prefix as it should be,
the function object will be created with a hidden link to the value of the functions prototype,
and the functions this value will be bound to the function object (where it should be).
Because this convention has a very important reason,
your team may decide to carry that convention across the other languages you use.
Refactor or Document Short, Hard to Read Names
I don’t know how many times I see code that uses very short names which make readability difficult.
What’s worse, is that so often there are many different names that mean the same thing sprinkled across the project/s.
Short, hard to read, pronounce, or understand names are rarely needed with the programming languages of today.
Use easily and quickly readable names where ever possible.
If you have to use short names or abbreviations, keep them consistent.
Translation tables are good for this.
You can have a commented translation table at the beginning of a file,
or at the project level if the names are wider spread.
Names should be specific to the domain your working in, rather than to the programming language.
Meaningful Loop Index Names
If your loop is more than a couple of lines long or you have nested loops,
make your loop index name something meaningful,
rather than i, j, k etc.
Additional Thoughts
- Code is read many more times than it is written.
Make sure the names you choose favour read-time over write-time convenience. - If you have names that are general or vague enough to be used for multiple purposes,
refactor your code, maybe create additional entities that have more specific names. - Don’t leave the meaning of the name to guess work.
This taxes the programmers mind unnecessarily.
There are better uses of our cycles. - Agree on and adopt a set of coding standards and guidelines.
It’s more important to have standards than to not have them because you can’t agree on the “right” way.
They will save wasted time and arguments during coding, and code reviewing.
Binarymist 