Coding Standards from Day 1

Is today your first day at your job? Worried about the coding practices? Do not hesitate to ask for coding standards document if not provided before starting your work. We often talk about coding standards because by following consistent coding standards helps in the overall quality of the software. As the team grows larger, these standards become more important for the consistency of code and uniformity of work.

I will list some of the coding standards that might be useful for your coding and code review.

Readability

Read, Read and Read!
Read your own code when you are finished with your program. If you are able to read after sometime and remember what exactly your If and else is doing, then Congratulations you are doing a good job and can support your users or customers without giving extra time in remembering what you actually did or asking your supervisor what was the business flow.

• There is no need to write obvious comments instead just add comments for complex logic only.
• Avoid writing deep nested code.
• Remember DRY Principle. Don’t-Repeat-Yourself. Your code logic should not be repeat again and again. Instead you can make a function to fulfill your need and call it whenever you need it.
• Do not forget YAGNI Principle. You-Aren’t-Gonna-Need-It. In short, write code for your present need, don’t think you might need that piece of code in the future.
• Remove unnecessary commented code from your project.
• Use proper English or you can install any available utility in your project to check spelling mistakes. Like in MS Visual Studio you can download any spell checker by using Nuget Package Manager.

Naming Conventions

Using descriptive and consistent naming conventions should not be overlooked. Variation and Inconsistent may lead to confusion and inefficient code and of course loss of time.

• PascalCase for Namespaces, Class Names, Function Names and Properties.
• camelCase for the function’s arguments and the local variables.
• Use noun phrases when naming a class.
• Use verb when naming a function.
• Use prefixes for interfaces like IEmailManager.
• Don’t mix your project namespaces with C# namespaces.
• Use descriptive variable names and try to bind it with business meaning.
• Avoid using Hungarian notation or any other type of identification in variables as data types are self-explanatory. You can hover on the variable and the IDE will tell you the datatype of that variable.

For example when naming a class for user account management:
UsrAccntMngr should never be used! (sigh)
UserAccountManager is the correct way! (at least for me)
— By the way, I just added 6 more characters and see how cool is my class name now.

Layout Conventions

Layout conventions are used to format classes of the project.

• Write one statement per line.
• Limit line length and bring it to another line so that you do need to scroll right to read the code.
• Consistent Indentation throughout the classes.
• Declare all variables in the start of the function.
• If class has any static variable, write in the start of the class.
• Keep all your enumerations together in a separate file.
• Keep one thing (class or interface) per file and give the same name to the file. Yes, it makes a larger project, but it is easier to find things.

This is not all and can be modified as per your needs and your team requirements. Pick some points, make a standard approach and share it with your co-workers.

I’ll be very grateful if others can share their ideas and good practices which they follow in comments.