+972 52-548-6969
Coding Standard - Names
Names should be in ASCII and are limited to [a-zA-Z0-9_]. Anything else, is a heretic attempt to cause me, personally, problems.
So speaks the guy who had to convince a company that building a platform on Hebrew# is not a good idea. In addition to that, those names should be in English, consistently spelled and have a uniform coding style. I don't care what, just that it is consistent and uniform.
Nevertheless, Hungarian notation should be left to those who dreams of the coup of the pwsz and its friend, cbSize.
Transcripting variables names is also a sin, and it punishable by crucifixion at your social reform site of choice.
Using names (subject to the above mentioned char limits) from latin-script based languages is allowed, assuming that the work is completely local. Sorry, but I rarely can help with code that looks like:
ILympho loco = new Alieniloquium();
If the developer speaks more than one language, though, a single language should be used across the entire code base. To do otherwise is to court disaster.
Again, I can't really understand code that goes like this:
Employee divka = Employees.GetByMispar(15);
Those are the things that I have found useful. The above applies to types, members, variables, parameters, tables, columns and file names.
Comments
I prefer "chkSize".
Ah, let me guess, 'offshored' code from India, right? No disrespect to my brothers from India who crank out some great code, it's just that there seems to have been a big surge back in the day of start-up offshore code companies cranking out horrendous code. I guess it's a matter of numbers. If there are horrible coders in the U.S., for example, and we have 270 million people, it only stands to reason that in a country of 1 billion people, there's just going to be that many more bad (and good!) coders.
It always seemed that the U.S. company's efforts to safe tons of money always cost them 5x more when they had to pay to have it rewritten again. I can't tell you how many offshore rescue projects i worked on and promptly paid my mortgage down considerably.
"Transcripting variables names is also a sin, and it punishable by crucifixion at your social reform site of choice."
I'm betting that'll be in someone's sig by next week. :-)
Sometimes, when there's no correct English translation, transliteration is a must. Hate to admit it, but I've come across a couple of examples in the past.
Almost 100% agree ... except ... I name ASP.NET controls with the equivalent of hungarian notation ... purely because they are on a planet of their own anyway, and it really helps to know what type of control they are from the code behind.
cbShouldTheUserBeAbleToDoThis is a very good CheckBox name ... boolShouldTheUser is a very bad variable name :)
Working on a local project with other developers more comfortably natural in another language, it's turned out that the project is split by language lines.
It's great actually! It's mostly crystallized into a scheme in which the domain specific bits are in the native (dutch) language, and the modular components in english, along with (of course) the platform itself. The nice thing is that it's instantly obvious what code belongs to, actually making it easier to read than if it were monolingual. It's like there's an extra level of hinting going on as to what the purpose of the code is.
It's inconceivable the domain-specific code - intrinsically tied to particular dutch organisations - would ever be used in another context, and anyone editing it thus is assured of needing to communicate with dutch people (and almost assured of needing to be able to speak dutch).
Originally I tried to convince my fellow project members to stick to one language, but in retrospect, this mixture works quite well.
I disagree. I rather call my entities what they are in the real world. No need to abuse of unicode characters so it isn't a problem.
It sometimes goes weird and you end up spelling a method name wich is composed of english + domain language but you get the idea instantly
What's wrong with Hungarian notation? I use a single character prefix to denote the type in my variables.
"iAmount" is an integer. Why would I just name that variable "amount"?
Anyone reading the code then has to either have (and be using) a IDE that can provide type information, or they have to find where the variable is declared to find out if "amount" is a decimal, or an integer, or a float or what?
What is wrong with that?
Chris, why is this needed?
Do you really have so many variables that finding them in the var decl is so onerous? Do you really ever have iAmount, fAmount, dAmount ?
Do you write methods so long that the var decl part is lost?
This is dead weight information, in my opinion
"Do you really have so many variables that finding them in the var decl is so onerous?"
Usually not. And most times finding the variable definitions is no problem, but why bother? If you have a variable named "amount" you will have to go find the type, if you have it as "iAmount" then you will never have to go looking.
"Do you write methods so long that the var decl part is lost?"
Usually not. But there are times when methods are longer than 1 screen length. Some people have lower resolution screens, and some people like higher font sizes, and some methods just don't make sense being broken up simply because they are 50 lines long.
Also, what about instance variables? Those are almost never near where you are coding, and they can even be in another file.
While I wouldn't name variables pwszVarName or strSomeString, I don't think a 1 character prefix is too much dead weight, so long as it adds value, and as long as you have to look for the type def (even if it is just 5 lines up), that 1 character will add value.
Why? It is some number, I don't care what, if I do, I move my focus three centimeters up and find it.
I regularly works with 16 points font, so I have little screen estate, the result are smaller methods, most of the time, but I have never had this problem.
If it is an instance variable, I can look it up in intellisense, or simply hover over that, or do a ctrl+b on top of that, etc.
I think it clutters the variable name and doesn't add any value
Relying on intellisense seems wrong to me, and it doesn't save you if you have printed out the code for a code review or are using Notepad2 or something for your editor.
I think for it to not add any value, you would have to say that any time that is wasted in "type confusion" (including any bugs that popup as a result of assuming a variable is a wrong type) is less than time saved by having less cluttered variable names.
When I am looking at someone elses code, I enjoy not having to lookup types and I think more to the point, we reduce careless errors of people thinking amount is an int and it is really a decimal or something similar.
I think we can just agree to disagree on this. I wouldn't have a big problem if a developer was not using hungarian, but personally, I tend to appreciate it for non-public variable names.
BTW, IIRC Microsoft agrees with you on this point, in a recent switch from all their suggestion in the past to use Hungarian (probably for vbscript).
Comment preview