Coding Standard, Naming Conventions and Good Programming Practices

Views:
 
     
 

Presentation Description

Get all the information on Coding Standard, Naming Conventions and Good Programming Practices, a perfect guide for beginners or developers.

Comments

Presentation Transcript

slide 1:

iFour Consultancy Coding standard Naming conventions and Good programming practices https://www.ifourtechnolab.com/

slide 2:

Naming conventions  Pascal Casing : First character of all words in uppercase and other characters are small  Use Pascal casing for Class names and Method names  Camel Casing : First character of all words except the first word are Upper Case and other characters are lower case  Use Camel casing for variables and method parameters https://www.ifourtechnolab.com/

slide 3:

Naming conventions  Use the prefix “I” with Camel Casing for interfaces Example: IEmployee  Do not use Hungarian notation to name variables. https://www.ifourtechnolab.com/

slide 4:

Naming conventions  Don’t use abbreviations for variable declaration Use meaningful or descriptive words  Do not use single character variable names like i n s etc. One exception in this case : variables used for iterations in loops: https://www.ifourtechnolab.com/

slide 5:

Naming conventions  Use predefined type names instead of system types like Int32 Boolean String etc  Do not use underscores _ for local variable names  Exception : you can prefix private static variables with an underscore https://www.ifourtechnolab.com/

slide 6:

Design conventions  Use appropriate prefix for the UI elements Control Prefix Label lbl TextBox txt Button btn Hyperlink hlk DropDownList ddl CheckBox chk CheckBoxList cbl ListBox lst Image img RadioButton rdb Table tbl Panel Pnl GridView gv https://www.ifourtechnolab.com/

slide 7:

Good programming practices  Avoid writing very long methods  A method should have 1-25 lines of code. If a method has more than 25 lines of code re-factor into separate methods  Method name should tell what it does. Don’t use misleading names. If the method name is obvious there is no need of explaining what the method does Good : Not Good :  Do not have more than one class in a single file https://www.ifourtechnolab.com/

slide 8:

Code readability  A method should do only one operation  Do not combine more than one operation in a single method Good : https://www.ifourtechnolab.com/

slide 9:

Code readability A method should do only one operation  Do not combine more than one operation in a single method Not Good :  Do not hardcode strings use resource files  Do not write comments for every line of code and every variable declared https://www.ifourtechnolab.com/

slide 10:

Good programming practices  Use enum wherever required  Do not use numbers or strings to indicate different values https://www.ifourtechnolab.com/

slide 11:

Good programming practices  Use enum wherever required  Do not use numbers or strings to indicate different values https://www.ifourtechnolab.com/

slide 12:

Good programming practices  Always use String.Compare or String.Equals for string comparison. This will ensure the string will match even if the string being compared has a different case  Use string.IsNullOrEmpty instead of “” or null https://www.ifourtechnolab.com/

slide 13:

Good programming practices  Use region to group related pieces of code together. If you use proper grouping using region the page should like this when all definitions are collapsed  Keep private member variables properties and methods in the top of the file and public members in bottom https://www.ifourtechnolab.com/

slide 14:

Good programming practices  Always check for unexpected values Example : if you are using parameter with 2 possible values then never assume that if one does not match then only possibility is the other value https://www.ifourtechnolab.com/

slide 15:

Good programming practices  Use blank line to separate logical group of codes https://www.ifourtechnolab.com/

slide 16:

Good programming practices  Never hardcode a path or drive name in code  Get the application path programmatically and use relative path  Avoid having very large files. If a single file has more than 1000 lines of code it is a good candidate for refactoring. Split them logically into two or more classes  Avoid Passing too many parameters to a method if method having more the 5-6 parameters then good to define a class or structure https://www.ifourtechnolab.com/

slide 17:

Exception handling  Always use to try-catch block for exception handling and Never do a catch exception and do nothing  If you hide an exception you will never know if the exception occurred or not. In the case of exceptions give a user friendly message but log the actual error with all possible details about the error https://www.ifourtechnolab.com/

slide 18:

Commenting conventions  Comment should be always same level as the code : Use Ctrl+K+D for Format document  Use // or /// for comments. Avoid using / … / https://www.ifourtechnolab.com/

slide 19:

Avoid nested looping  Avoid Deep Nesting : Too many levels of nesting can make code harder to read and follow https://www.ifourtechnolab.com/

slide 20:

Code reusability  Avoid repeated code : The same code should not be repeated more than twice create method or function for that https://www.ifourtechnolab.com/

slide 21:

Naming convention in ASP.NET MVC Application  Controller : Its name must end with ‘controller’ word. E.g. PersonController EmployeeController  Generally all controllers should be kept inside /Controllers folder of the project  Model : Model name should be similar to the database table name not mandatory. For example if the database table name is "Person" then the model name should be "PersonDetail“  Generally all models are kept inside the /Models folder of the project.  Views : There should be a view folder inside /Views folder corresponding to each controller. Like for PersonController there should be a folder /Views/Person. https://www.ifourtechnolab.com/

slide 22:

Naming convention for Controller Actions  Here is the table of suggested standard names for controller actions: Controller Action Type URL Description Index GET Employee/Index Displays a list of employees Detail GET Employee/Details/ 1 Displays a single employee detail with an Id of 1 Create or Add GET Employee/Create Displays a form for creating employee Save or Insert POST Employee/Save Insert a record into the database Edit GET Employee/Edit/1 Displays form for editing an existing employee Update POST Employee/Update Update an existing record Destroy GET Employee/Destroy /1 Delete an existing record https://www.ifourtechnolab.com/

slide 23:

 https://msdn.microsoft.com/en-us/library/ff926074.aspx  https://www.codeproject.com/Articles/8971/C-Coding-Standards-and-Best-Programming- Practices  http://www.dofactory.com/reference/csharp-coding-standards References https://www.ifourtechnolab.com/

slide 24:

Thank You.. https://www.ifourtechnolab.com/

authorStream Live Help