locked
Camel or Hungarian notation RRS feed

  • Question

  • Hello,

    Which is better? what is difference? 

    What are the syntax?

    Saturday, August 1, 2015 12:14 PM

Answers

    • From MSDN explanation, coding conventions served for those purposes:
    1. They create a consistent look to the code, so that readers can focus on content, not layout.
    2. They enable readers to understand the code more quickly by making assumptions based on previous experience.
    3. They facilitate copying, changing, and maintaining the code.
    4. They demonstrate C# best practices.

    The naming contraventions exist for one reason: Clean readability

    Whatever notation you prefer, you should be consistent with it throughout your project. Also you need to use the system that your team uses if you are working in a team project. There is a good saying, "Everybody can write code for computer to understand but only a few write good code that human can understand as well". 

    If your notations are clear and  consistent with your team, another team member just understand thing without spending too much time on it. Code readability is very important because it helps your project to be maintainable. 

    What is Hungarian notation: 

    In Hungarian notation, variable names start with their abbreviated types such as:

    TextBox txtCustomerName;
    
    string strCompanyName;

    Camel Notation:

    Variable names words are all Uppercase except for the first one:

    string companyName;

    Pascal Notation:

    It is similar to camel case but in that convention every word start with capital letters:

    string CompanyName;

    In c++, coders prefer or use Hungarian notation however, in .Net environment, coders prefer Camel notation mostly. Hungarian notations aim coders to remember what type is that variable. But in .Net environment, there can be hundreds of different class types and by adding an abbreviation in front of variables of those different classes would make no help a coder to remember or utilize. 

    You can find more information and examples in this link:

    http://www.akadia.com/services/naming_conventions.html

    • Marked as answer by Arash_89 Saturday, August 1, 2015 12:37 PM
    Saturday, August 1, 2015 12:35 PM

All replies

    • From MSDN explanation, coding conventions served for those purposes:
    1. They create a consistent look to the code, so that readers can focus on content, not layout.
    2. They enable readers to understand the code more quickly by making assumptions based on previous experience.
    3. They facilitate copying, changing, and maintaining the code.
    4. They demonstrate C# best practices.

    The naming contraventions exist for one reason: Clean readability

    Whatever notation you prefer, you should be consistent with it throughout your project. Also you need to use the system that your team uses if you are working in a team project. There is a good saying, "Everybody can write code for computer to understand but only a few write good code that human can understand as well". 

    If your notations are clear and  consistent with your team, another team member just understand thing without spending too much time on it. Code readability is very important because it helps your project to be maintainable. 

    What is Hungarian notation: 

    In Hungarian notation, variable names start with their abbreviated types such as:

    TextBox txtCustomerName;
    
    string strCompanyName;

    Camel Notation:

    Variable names words are all Uppercase except for the first one:

    string companyName;

    Pascal Notation:

    It is similar to camel case but in that convention every word start with capital letters:

    string CompanyName;

    In c++, coders prefer or use Hungarian notation however, in .Net environment, coders prefer Camel notation mostly. Hungarian notations aim coders to remember what type is that variable. But in .Net environment, there can be hundreds of different class types and by adding an abbreviation in front of variables of those different classes would make no help a coder to remember or utilize. 

    You can find more information and examples in this link:

    http://www.akadia.com/services/naming_conventions.html

    • Marked as answer by Arash_89 Saturday, August 1, 2015 12:37 PM
    Saturday, August 1, 2015 12:35 PM
  • Camel Notation- In this naming convention first character of all words, except the first word are Upper Case and other characters are lower case.

    Example: supplierCode

    Hungarian Notation - In this naming convention the variable name starts with group of small letter which indicate data type.

    Example: bLoop ( b indicates its a Boolean type), strFirstName, iNumberOfDays

    The benefit of not using hungarian notation is basically only avoidance of its disadvantages, best explained at Wikipedia  which has a list of advantages and disadvantages of the hungarian notation and can thus probably provide the most comprehensive answer to this question. The notable opinions are also a quite interesting read.

    . Some potential issues are:

    • The Hungarian notation is redundant when type-checking is done by the compiler. Compilers for languages providing type-checking ensure the usage of a variable is consistent with its type automatically; checks by eye are redundant and subject to human error.
    • All modern integrated development environments display variable types on demand, and automatically flag operations which use incompatible types, making the notation largely obsolete.
    • Hungarian Notation becomes confusing when it is used to represent several properties, as in <tt style="font-family:monospace, Courier;">a_crszkvc30LastNameCol</tt>: a constant reference argument, holding the contents of a database column <tt style="font-family:monospace, Courier;">LastName</tt> of type varchar(30) which is part of the table's primary key.
    • It may lead to inconsistency when code is modified or ported. If a variable's type is changed, either the decoration on the name of the variable will be inconsistent with the new type, or the variable's name must be changed. A particularly well known example is the standard WPARAM type, and the accompanying wParam formal parameter in many Windows system function declarations. The 'w' stands for 'word', where 'word' is the native word size of the platform's hardware architecture. It was originally a 16 bit type on 16-bit word architectures, but was changed to a 32-bit on 32-bit word architectures, or 64-bit type on 64-bit word architectures in later versions of the operating system while retaining its original name (its true underlying type is UINT_PTR, that is, an unsigned integer large enough to hold a pointer). The semantic impedance, and hence programmer confusion and inconsistency from platform-to-platform, is on the assumption that 'w' stands for 16-bit in those different environments.
    • Most of the time, knowing the use of a variable implies knowing its type. Furthermore, if the usage of a variable is not known, it cannot be deduced from its type.
    • Hungarian notation reduces the benefits of using code editors that support completion on variable names, for the programmer has to input the type specifier first, which is more likely to collide with other variables than when using other naming schemes.
    • It makes code less readable, by obfuscating the purpose of the variable with needless type and scoping prefixes.<sup id="cite_ref-4" style="line-height:1;font-size:11.1999998092651px;unicode-bidi:embed;">[4]</sup>
    • The additional type information can insufficiently replace more descriptive names. E.g. sDatabase does not tell the reader what it is. databaseName might be a more descriptive name.
    • When names are sufficiently descriptive, the additional type information can be redundant. E.g. firstName is most likely a string. So naming it sFirstName only adds clutter to the code.
    • It's harder to remember the names.
    • Multiple variables with different semantics can be used in a block of code with similar names: dwTmp, iTmp, fTmp, dTmp.

    You can read more at  Naming Conventions for .NET / C# Projects

    What is the benefit of not using Hungarian notation?


    Please mark as answer or vote as helpful if my reply does

    Saturday, August 1, 2015 12:37 PM