Good Coding Practices

Following good coding practices in general would make your and your team members’ life easier. Here are a few tips for good coding. I personally follow these guidelines and now I’m sharing the same with you all.

  1. Identify your needs before starting your first line of code, and code accordingly. Avoid any unnecessary code or workarounds. When starting on a new program (or new module), making a prototype of your program before starting to code helps a lot. I’ve experienced this personally.
  2. Use proper names for variables, functions, classes, forms, enums etc.
    Use any variable naming convention (like camel-casing, hungarian notation etc.) you like but stick to it throughout the program.
    For variables, use good prefixes/suffixes. For functions use self-explaining names. A third person should be able to easily guess from function-name, what the function does.
  3. Each organization has its own coding standards. Follow coding standards as much as possible. Even if your organization doesn’t have one, or you program for yourself, define your own standards and stick to it.
  4. Avoid unnecessary code. Try to reuse your existing code.
  5. Make your code as much modular as possible.
  6. Keep your functions as short as possible. Lesser number of lines in your code implies lesser bugs, improved readability, easy debugging and many more advantages etc.
  7. Use consistent code throughout the application. When working on an existing project, or in a team, avoid your own coding style and adapt to how things have been done throughout the application.
  8. Reuse existing code wherever possible rather than designing your own from scratch as they might be already well tested.
  9. Neat code is as much necessary as good code. Indent your code properly, do not leave unnecessary blank lines, avoid too much coding where lesser would suffice etc.
  10. Use comments wherever necessary. Avoid unnecessary or too much commenting though. If you have put some comments as a reminder to yourself, ensure that you remove it after the task is complete. There should be no TODOs etc. in the finished code. Comments should be short, precise and meaningful.
  11. Look at your code from a third person’s angle who has never seen your code. He should be able to comprehend your code easily.
  12. Though not always, but most of the times, using OPTION STRICT ON saves you from innocent looking bad code.
  13. If you use any source control mechanisms (like SourceSafe, SVN etc.) and you are working in a team, use it very cautiously as it affects other users/systems.
    1. Never check-in any code that has compile errors or warnings. Other team members would have trouble debugging their codes.
    2. Always make a note of what files you are checking in and checking out.
    3. Don’t checkout any files unnecessarily as it makes the file unavailable to other team members who might be genuinely requiring to edit that file.
    4. Always get latest files from source control database when opening the Visual Studio for the first time each day and do a full rebuild.
    5. Before closing Visual Studio, always have a look at the checked out files (“Pending Checkins” box).
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: