Naming conventions
The Igloo Coder has been blogging about naming conventions and I want to put in my two cents worth.
I do like the book he cited, Framework Design Guidelines by Krzysztof Cwalina and Brad Abrams, and when I first got it, I read probably 75% of the book within 24 hours. So I find myself emulating the standards they have laid out in that book.
The primary reason I do this is because I am nearly always writing .NET code. And so essentially, I am extending their framework through inheritance, you might say. Here is an example I ran across in a code-review I was asked to do on the spot, in front of a group of developers who were having productivity issues.
Public Class clsCorpException
Inherits ApplicationException
Public Sub New(ByVal asBuf As String, ByVal aoEx As Exception)
MyBase.New(asBuf, aoEx)
End Sub
<...>
End Class
Besides the Hungarian notation, which I do not think adds significant value in general, the biggest problem with this code is the parameter names for the constructor. Since we are inheriting from ApplicationException, why wouldn't you use message and innerException as parameter names, so that the Intellisense is exactly the same as the base class constructor, since the parameters have exactly the same meaning? Their answer was because it wouldn't match their corporate naming convention.
To me, this group is losing velocity right at the get-go. I call it the "magic dunce cap" or "secret decoder ring" that so often exists in the big corporate IT departments - that body of knowledge that every developer must learn to adhere to the corporate standard. To me, there should be inheritance at the developer knowledge level too - if you hire someone who has knowledge of the .NET Framework, if your corporate frameworks adopt the same standards and conventions, the new guy can more easily consume the corporate framework with less initial training.
Sometimes I wonder if the "secret decoder ring" idea is meant to make those people who have the corporate knowledge more valuable somehow. Actually, in a way I think it increases the corporate risk - those people are too hard to replace if the time comes for that - the learning curve for new hires becomes a barrier for firing/hiring.
The Igloo coder has also chosen SCREAMING_CAPS as his convention for constants, so that he knows what they are when he is using them. Same with Hungarian notation for private variables. I disagree with both of those, because I think it is the compiler's job to understand the type-safety and read/write. I use the camelCasing and PascalCasing notations, where PascalCasing is used for anything publicly exposed (class names, method names, public constants) with the exception of method arguments which use camelCasing. Everything private uses camelCasing, and to distinguish local variables from class variables, I prefix the class variables with the underscore.
Do we, as developers consuming a class, really need to know the difference between a read-only field or property and a constant?
Namespace Constants
Public Class TestValues
Public Const UserId As String = "Test_User"
Public Const PasswordClear As String = "Password"
Public ReadOnly Property PasswordHash As String
Get
Return Hasher.Hash(PasswordClear)
End Get
End Property
End Class
End Namespace
I also notice many bad habits where names are over-qualified - particularly Enums
Public Enum PrintState
PrintStateOk
PrintStateRetry
PrintStateFailed
PrintStateCanceled
End Enum
There's more I could write about this - I actually started writing this post in July and set it aside until now - I think I'll just post this and add more ideas later.
Mike