variable, a simple suggestion to C/C++ beginner
-
I read many posts on this forum, I have a simple suggestion to C/C++ beginner: use variable properly. assume you have a varable, which is called MyUser. is name of the variable good? my answer is "No". a variable includes 2 parts: type and meaning. MyUser only includes second part: meaning, but doesn't show type of the variable. good idea for defining the variable depends on its type, you should add type as prefix for the variable, E.g. char*pszMyUser; //prefix psz=a Pointer of Zero based String char**ppszMyUser; //ppsz=a pointer to a Pointer of Zero based String int iMyUser; //i=integer, some people use "n" or "u" SYSTEMTIME tmMyUser; //tm=SYSTEMTIME there are no rules for defining name of prefix, but please respect public usage, E.g, people always use psz for char*, so we should not use other names. =================================== there are many advantages if you use variable with prefix, for example, you can update your code easily when program grows large or after one or more years. your code is also readable for others. =================================== if you have 2 or more C/C++ samples for study, you have to choose one as start sample. first, test their performance, second, see which samples use prefix properly - the one which doesn't use prefix is not good normally. =================================== if you have a class defined in this way: class myfile { public: LPTSTR filename; BOOL dirty; int data; }; I suggest you change it as: class myfile { public: LPTSTR pszFileName; BOOL bDirty; //b=boolean int iData; }; ======================== today is sunday. believe me or not, it is up to you.
A nice tool for optimizing your Microsoft html-help contents. Includeh10
-
I read many posts on this forum, I have a simple suggestion to C/C++ beginner: use variable properly. assume you have a varable, which is called MyUser. is name of the variable good? my answer is "No". a variable includes 2 parts: type and meaning. MyUser only includes second part: meaning, but doesn't show type of the variable. good idea for defining the variable depends on its type, you should add type as prefix for the variable, E.g. char*pszMyUser; //prefix psz=a Pointer of Zero based String char**ppszMyUser; //ppsz=a pointer to a Pointer of Zero based String int iMyUser; //i=integer, some people use "n" or "u" SYSTEMTIME tmMyUser; //tm=SYSTEMTIME there are no rules for defining name of prefix, but please respect public usage, E.g, people always use psz for char*, so we should not use other names. =================================== there are many advantages if you use variable with prefix, for example, you can update your code easily when program grows large or after one or more years. your code is also readable for others. =================================== if you have 2 or more C/C++ samples for study, you have to choose one as start sample. first, test their performance, second, see which samples use prefix properly - the one which doesn't use prefix is not good normally. =================================== if you have a class defined in this way: class myfile { public: LPTSTR filename; BOOL dirty; int data; }; I suggest you change it as: class myfile { public: LPTSTR pszFileName; BOOL bDirty; //b=boolean int iData; }; ======================== today is sunday. believe me or not, it is up to you.
A nice tool for optimizing your Microsoft html-help contents. Includeh10
includeh10 wrote:
a variable includes 2 parts: type and meaning.
This gets into a long religion war of type-naming, but off-hand I would disagree completely. Although it provides the programmer with instant information, it reduces future use, inheritance, polymorphism, and makes your job harder when you upgrade to future versions forcing full rewrites rather than minor changes to your code. on the debate of hungarian notation[^] _________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
includeh10 wrote:
a variable includes 2 parts: type and meaning.
This gets into a long religion war of type-naming, but off-hand I would disagree completely. Although it provides the programmer with instant information, it reduces future use, inheritance, polymorphism, and makes your job harder when you upgrade to future versions forcing full rewrites rather than minor changes to your code. on the debate of hungarian notation[^] _________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
For a slightly different take see this. I agree that hungarian can be bad if used wrongly - But if used as described in the link I gave I think hungarian prefixes are a good thing. For example a "p" to name a pointer is usefull and will not pose any problems in the future. And if you do, say, change the pointer to a reference, you would have to visit every use of it anyway so no problem. Steve
-
For a slightly different take see this. I agree that hungarian can be bad if used wrongly - But if used as described in the link I gave I think hungarian prefixes are a good thing. For example a "p" to name a pointer is usefull and will not pose any problems in the future. And if you do, say, change the pointer to a reference, you would have to visit every use of it anyway so no problem. Steve
Stephen Hewitt wrote:
For example a "p" to name a pointer is usefull and will not pose any problems in the future. And if you do, say, change the pointer to a reference, you would have to visit every use of it anyway so no problem.
I agree absolutely on the p designation of pointer and require it in my work (or ptr prefix). But the primary problem with hungarian notation is that it forces you to define two separate rules for naming conventions, one based on C/C++ types and one for your own types. if I make a variable for x as an integer it is iX, but if I make a vector matrix for multidimensional matrix definitions is it vX? usually no. You then start defining a set of rules exceptions if you will when you will use type designation and when you will not, two separate rules rather than one consistant one. Is mX a map X or a multimap X? is hX a hex string of X or a hash table? Thus you get into enlarging your naming convention to cover all things. myClass myClassUsageVariable; myClass *p_myClassUsageVariable; // or myClass mcUsageVariable; myClass *p_mcUsageVariable; // matches this? int iIterator; int *p_iIterator; // or int intIterator; int *p_intIterator; generally type conventions do not ask hungarian for user classes so then you have: myClass UsageVariable; int iIterator; and start drawing out a long line of rules on what should be combined into hungarian and what should not, two completely different naming conventions. Or worse you decide that everything should be listed in hungarian including class, namespace, orignator of the class, as well as type. Now your variable name is taking the place of documentation. (I have had someone try to request this) using namespace boost; // 3rd party library from boost shared_ptr boost_boost_sharedptr_pEarthProjection; Since boost has shared_ptr and scoped_ptr sp is not enough, so either you start enlarging your type definitions or removing them for all 3rd party and user defined work. Again, making two sets of naming conventions, which I consider worse. It also doesn't provide you with any more information that a proper IDE will. A professional tool will tell you the type, good documentation will tell you the type, auto documentation will tell you the type. But hungarian notation just makes life more difficult. I did say the subject opens up a religion war of types. I agree with the idea that hungarian notation actually reduces object oriented design and creates redundant overhead
-
Stephen Hewitt wrote:
For example a "p" to name a pointer is usefull and will not pose any problems in the future. And if you do, say, change the pointer to a reference, you would have to visit every use of it anyway so no problem.
I agree absolutely on the p designation of pointer and require it in my work (or ptr prefix). But the primary problem with hungarian notation is that it forces you to define two separate rules for naming conventions, one based on C/C++ types and one for your own types. if I make a variable for x as an integer it is iX, but if I make a vector matrix for multidimensional matrix definitions is it vX? usually no. You then start defining a set of rules exceptions if you will when you will use type designation and when you will not, two separate rules rather than one consistant one. Is mX a map X or a multimap X? is hX a hex string of X or a hash table? Thus you get into enlarging your naming convention to cover all things. myClass myClassUsageVariable; myClass *p_myClassUsageVariable; // or myClass mcUsageVariable; myClass *p_mcUsageVariable; // matches this? int iIterator; int *p_iIterator; // or int intIterator; int *p_intIterator; generally type conventions do not ask hungarian for user classes so then you have: myClass UsageVariable; int iIterator; and start drawing out a long line of rules on what should be combined into hungarian and what should not, two completely different naming conventions. Or worse you decide that everything should be listed in hungarian including class, namespace, orignator of the class, as well as type. Now your variable name is taking the place of documentation. (I have had someone try to request this) using namespace boost; // 3rd party library from boost shared_ptr boost_boost_sharedptr_pEarthProjection; Since boost has shared_ptr and scoped_ptr sp is not enough, so either you start enlarging your type definitions or removing them for all 3rd party and user defined work. Again, making two sets of naming conventions, which I consider worse. It also doesn't provide you with any more information that a proper IDE will. A professional tool will tell you the type, good documentation will tell you the type, auto documentation will tell you the type. But hungarian notation just makes life more difficult. I did say the subject opens up a religion war of types. I agree with the idea that hungarian notation actually reduces object oriented design and creates redundant overhead
I totally agree that some people go overboard with Hungarian notation, presumably in the belief that it will make their code easier to understand. Me, I have four rules: a pointer variable always starts with p, and a class member variable always starts with m_ and boolean variables always start with b (unless they are called ok or failed). Finally all (of the very few) global variables start with a g_ to highlight that they are global. (I once came across some code, perhaps 200 lines, where the 'programmer' (or idiot, more likely) had defined a global variable called i presumably to save having to define it in every function!) The first rule certainly helps save confusion, like, Is what I am passing to this function a pointer or a reference? The second rule's benefit comes largely from the fact that with complicated code it is easy to run out of variable names. By sticking a tag in front of a load of the variables, I create room for more. The g_ and m_ prefixes certainly help me stop worrying how the variable got its value. As for putting an i in front to show that the value is an integer, this is a waste of time at best. And I don't see the point in adding a prefix to strings to indicate that they are null terminated. How many strings are NOT null terminated? Besides, suppose I decide to define CString Name; and later in the interests of speed decide to redefine as char Name[100]; Should I rename Name as psName to show that it is now a pointer to a string? Or call it sName to show that it is an array which works as a string? No, just call it Name, capitalised here because it is an important variable, as distinct from name which is just some temporary name used very locally, a throw-away version. A name should describe the purpose or algorithmic behavior, not the implementation. The IDE will tell me about implementation. As a programmer looking at ancient code I wrote last month, I want to get an idea of what the code is meant to be doing, what its purpose is, and I do not want to be distracted by irrelevant low level details. Shraddhan If you want my advice, contact my secretary for a quotation first.