Naming and style (I)
Fortunately, there are many people using well defined naming and style conventions. But, through my professional life, I have got the doubtful privilege of bumping into many others that not.
I must say that this does not only happen at what we should call low tech profile environments, but also at top consulting firms. In my humble opinion, this is a result of the indiscriminate hiring during the .com fever (at least in Spain).
This is one of the essential factors to get quality code, and the first step of a chain where you can find Kent Beck's and Martin Fowler's refactoring, and the bigger the project or team, the higher importance it gets.
During the innumerable years that I have been coding, my style and naming conventions have been changing, adapting to the new environments and languages, and improving with the acquired knowledge. And I am sure they will keep changing like something alive.
Today I will speak just about naming. I will further speak about style, which is much more interesting. I will focus on the most extended environments nowadays: Java and .NET.
Class names
Both classes and interfaces fall into this category.
During many years I used prefixes to name classes and interfaces, putting a C or an I before, respectively. In fact, .NET still uses this convention for interfaces, while Java makes no distinction. I think that the I has no value, and thus I have stopped using it. I think that interfaces are our face to the world outside (good practice: coding to interfaces), and their potential users don't care about the fact that it's an interface or a class, so the I adds unnecessary data and thus it just makes the style worse. However, it can be advisable to use it with .NET to keep coherence with the environment.
As a rule, class or interface names must be composed by one or more representative words, fully written unless they are well known abbreviations, properly capitalized at their first letter, and without underscores or other artifacts between them. Sample: DataObject.
As an extension, I think that it's a good practice to add the pattern name at the end, if the class follows one. Example: DataObjectFactory.
Public method and property names
My advice is to use the rules that the style guides give for the different environments.
For example, with Java the name is built the same way as already explained for classes, but with the first word in lower case. Example: provideSomeInfo().
With .NET the name is built exactly as for a class. Example: ProvideSomeInfo().
Private or protected method and property names
My advice here is the same as before, and follows the same pattern as public methods and properties.
Along many years I have used my own variation of Charles Simonyi's Hungarian Notation, from my C/C++ heritage, but certainly, more pure object oriented languages like Java or C# make it almost useless. Anyway it can be a good issue to discuss.
Some basic rules
It is essential that names are always representative of the method or variable role. Please, don't be afraid to write more, it will pay you when you have to came back a couple of months later.
This can only be bypassed for counters, used in loops, but restricted to those traditionally used in mathematics: i, j, k, m, n. And with that precise order. This is very important to keep coherence and prevent errors at intricate inner loops (which should not happen, but that's a matter of style).
I must say that this does not only happen at what we should call low tech profile environments, but also at top consulting firms. In my humble opinion, this is a result of the indiscriminate hiring during the .com fever (at least in Spain).
This is one of the essential factors to get quality code, and the first step of a chain where you can find Kent Beck's and Martin Fowler's refactoring, and the bigger the project or team, the higher importance it gets.
During the innumerable years that I have been coding, my style and naming conventions have been changing, adapting to the new environments and languages, and improving with the acquired knowledge. And I am sure they will keep changing like something alive.
Today I will speak just about naming. I will further speak about style, which is much more interesting. I will focus on the most extended environments nowadays: Java and .NET.
Class names
Both classes and interfaces fall into this category.
During many years I used prefixes to name classes and interfaces, putting a C or an I before, respectively. In fact, .NET still uses this convention for interfaces, while Java makes no distinction. I think that the I has no value, and thus I have stopped using it. I think that interfaces are our face to the world outside (good practice: coding to interfaces), and their potential users don't care about the fact that it's an interface or a class, so the I adds unnecessary data and thus it just makes the style worse. However, it can be advisable to use it with .NET to keep coherence with the environment.
As a rule, class or interface names must be composed by one or more representative words, fully written unless they are well known abbreviations, properly capitalized at their first letter, and without underscores or other artifacts between them. Sample: DataObject.
As an extension, I think that it's a good practice to add the pattern name at the end, if the class follows one. Example: DataObjectFactory.
Public method and property names
My advice is to use the rules that the style guides give for the different environments.
For example, with Java the name is built the same way as already explained for classes, but with the first word in lower case. Example: provideSomeInfo().
With .NET the name is built exactly as for a class. Example: ProvideSomeInfo().
Private or protected method and property names
My advice here is the same as before, and follows the same pattern as public methods and properties.
Along many years I have used my own variation of Charles Simonyi's Hungarian Notation, from my C/C++ heritage, but certainly, more pure object oriented languages like Java or C# make it almost useless. Anyway it can be a good issue to discuss.
Some basic rules
It is essential that names are always representative of the method or variable role. Please, don't be afraid to write more, it will pay you when you have to came back a couple of months later.
This can only be bypassed for counters, used in loops, but restricted to those traditionally used in mathematics: i, j, k, m, n. And with that precise order. This is very important to keep coherence and prevent errors at intricate inner loops (which should not happen, but that's a matter of style).
0 Comments:
Post a Comment
<< Home