Naming/abbreviating convention
-
I had to write a document once explaining how to name variables, controls and so on. I was asked to write all the abbreviations and to create something to check if the names where correct. Well, my document was very short. No abbreviations at all. Control names will never be txt, btn, cbo etc. It is textbox, button, combobox, checkbox followed by the name that describes it. I used textbox instead of text because the textSomething is generally a string, while the textboxSomething is the textbox that will receive such string. The only thing that should be used (for that particular project) was to avoid sub-classing names. I don't care if it is a SpeedButton, SomeOtherKindOfButton or a simple Button. The names are always button. Some criticized that not having the right type makes thing hard. In my opinion, needing to know the exact type of the button makes thing hard. If you know there is a button to save, you should look for buttonSave. You don't need to care what kind of button it is (specially if that can change tomorrow).
Paulo Zemek wrote:
Control names will never be txt, btn, cbo etc. It is textbox, button, combobox, checkbox followed by the name that describes it.
I think that if this is documented and team members follow the guidelines it's perfectly fine. I don't really care if it's actually abbreviated or not, I think this is more of a taste thing. Because most people are used to the abbreviation, they shouldn't have problems when the controls are abbreviated, but I agree that having the full name eliminates the risk of confusion. The only disadvantage though, is when you have lines of code that have several control names in it, they usually get clumsy with long names.
Paulo Zemek wrote:
The only thing that should be used (for that particular project) was to avoid sub-classing names.
I don't agree with you here, because, you know, A button is a sub classed control. If you were to follow that all your controls would start with control prefix. But, sub classing in every case may not make sense. If it's a simple subclass, like adding a new property useful for you, then it might not make sense to subclass the name. But, if the behavior is significantly changed (or incremented), then it might make sense to subclass the name.
"To alcohol! The cause of, and solution to, all of life's problems" - Homer Simpson "Our heads are round so our thoughts can change direction." ― Francis Picabia
-
Apologies if this is in the wrong place. I was wondering if people could point me in the right direction with regards to naming and abbreviation conventions. For example, document = doc control = ctrl parameter = param to name a very very few. When you are dealing with people whose native tongue is not English, you tend to get a wide variety of abbreviations, as they don't consider syllables or etymology. The result is pages and pages of enigmatic code full of incomprehensible parameters and functions. It's not so bad if people got in the habit of commenting stuff, but, to whoever wrote the code the abbreviations are clearly obvious (i.e. no need to explain!). (I agree not EVERYTHING needs commenting, but that's only if the parameter/function names are crystal clearly obvious.) I was wondering if there was any resource to which I can point my colleagues to get a hint on how to come up with better parameter names.
Almost, but not quite, entirely unlike... me...
I once programmed in a language that was limited to six-character names in the symbol table. I don't do that anymore. I once programmed in a language where variables were conventionally a single character, maybe with some digits. I don't do that anymore. I once programmed in a language where all variable names that weren't parameters were global to the program. I don't do that anymore. In fact I haven't done any of these things since the mid-80s. Names need to be descriptive and use words - noun phrases. Names can be contextual on method, class, and namespace and not use big noun phrases. If you need a really big name to distinguish items, your current context has become crowded. Refactor something, then continue with short names made unambiguous by context - just like we do in outside life.