Posts

Showing posts from April, 2014

Naming Convention - Coding (Part 6)

The following points applies for all the sections that follows: Never use all caps. Only use Pascal or camel casing. Never use Hungarian Notation. Again, avoid using abbreviations unless the name is too long (exceptions: common abbreviations, medical abbreviations, banking abbreviations, etc…). Avoid abbreviations longer than 5 characters. Use uppercase for 2 letter abbreviation and Pascal case for longer ones.               // Example CountryEU CountryGcc Never add redundant or meaningless prefixes and suffixes . // Bad Practice             public enum LanguageEnum             public class   CEmployee public struct ChangeStruct Never include the class name in the property name . // Bad Practice             Customer .customerName // Good Practice             Customer .name Always prefix Boolean variables and properties with either Can , Is or Has. Classes or Structs Use Pascal casing only. Use a noun or noun phrase for

Naming Convention - Data Sources (Part 5)

Naming convention is a set of rules for choosing the character sequence to be used for identifiers which denote variables, types, functions, and other entities in code and documentation. Reasons for using a naming convention * : Reduce the effort needed to read and understand code, in addition to enhancing clarity in cases of potential ambiguity. Enhance code appearance (for example, by disallowing overly long names or unclear abbreviations) in a way to enhance the aesthetic and professional appearance of work product. Help formalizing expectations and promote consistency within a development team. Help avoiding "naming collisions" that might occur when the work product of different organizations is combined. Provides a meaningful data to be used in project handovers which require submission of program code and all relevant documentation. Although code is largely hidden from the view of most business users, well-chosen identifiers make it significantly easier f