Coding Standards and Best Practices

Coding Standards and Best Practices

ProgrammingWelcome to the wonderful world of software development. Prepare yourself for an exciting and thrilling journey filled with code, rules, and more code. And did I mention there are rules?

If you are someone who is familiar with coding, then the concept of coding standards is nothing new to you. You may be a strong supporter of these guidelines or a freedom fighter who believe that code is a form of expression. Whatever the case may be, it doesn’t hurt to look at some of the best practices when it comes to write a good piece of code.
It’s worth mentioning that while coding standards exist – they exist in many variations and often are merely guidelines that don’t have to be followed. Unless you want to write good code, then you probably should stick to some form of standards.

Write comments and documentation

Perhaps one of the first things you learn as a developer is to comment your code. At first it may seem like a waste of time, following the mentality of ‘If they are a developer too – they can understand it’. While it is true some of the time, commenting your code and providing proper documentation will guide the other developers through the algorithm and logic that you implemented. But don’t get carried away and comment every line of code! Obvious code should be left as is.

Write readable yet efficient code

Readable codes are easy to follow, yet use optimal space and time. When writing code you may often want to write it in as little lines as possible. Perhaps you can write an entire method or function in one line, but that only makes it harder to read and understand.

Use helper methods

It’s good practice to keep code concise and succinct. A method should only implement what it needs to do. If a part of your implementation does something else, put it in a separate method and call that within your method.

If avoidable, do NOT hard-code!

The only things that should be hard-coded are constants. That’s it.

Write test cases. Don’t forget the edge cases: 0s, empty strings/lists, nulls, etc.

This way you know what your method does, what it takes and what it should return. You will know when it should work or when it should fail. A function should always be based on test cases; not tests on functions.

Write readable yet efficient code.Conform to the coding standards of your current project

“DISCIPLINED PERSONAL PRACTICES CAN REDUCE DEFECT INTRODUCTION RATES BY UP TO 75 PERCENT”

Every project/company has their own coding standards. Some might prefer one style over the other when it comes to things such as naming conventions, file structure and spacing.
There are IDEs where you can set the preferred style, which will auto-correct you when you save. It is easier to read and, therefore understand, when all the files of the projects use the same style, naming convention, spacing, etc.

Use your IDE’s drop-down menu

Not so much a standard, but a good practice, these are very helpful and will help you make less coding errors. For example:
If you want to rename a variable or a method, just use the “refactor” option of your IDE and it will change all the calls to that method/variable name. You don’t have to change them one by one which will make your code prone to error/failure.
If you want to create getter/setter methods of all your private variables, just use “create getter/setter” and the IDE will automatically create the methods for you.

APIs are handy

“CURRENT SOFTWARE PROJECTS SPEND ABOUT 40 TO 50 PERCENT OF THEIR EFFORT ON AVOIDABLE REWORK”

Before implementing a method, make sure they’re not available for you to use. You don’t have to code if you can just import the functionality. It makes a developer’s life super easy.
The famous saying is “Don’t reinvent the wheel” and it stands true in many cases. However, you should always consider the implications of importing a library, especially if it is third party. Aside from possible licensing issues, you may just be bloating your codebase. If all you need is a method that converts temperatures, you don’t have to import a library that does that and a hundred other things.

Pair programming/code review

“PEER REVIEWS CATCH 60 PERCENT OF THE DEFECTS”

These are very helpful when it comes to refactoring your code. Others might see better implementation to optimize your code or just make your code more elegant. It also ensures that developers adhere to standards and the work is double checked. In addition to all that, it is a wonderful way for developers to learn from each other.

BACKUP AND SAVE YOUR WORK OFTEN

Enough said. Dead battery, blackout, software glitch, fire, nuclear disaster – all of these may result in loss of data. Making sure you save often and back up your code on some kind of version control system is a simple way to ensure that your code stays safe.

Coding standards and best practices is a huge topic – one that can go on for many pages. In fact, if you ever wish to read up on Java coding standards, Oracle has just that. Application of these standards and practices also varies by application – whether you are working on a huge corporate project or helping your little brother with homework. Based on many factors, it is ultimately up to you to make sure that the code you develop is good code.

 

About the Author

Avatar
Denis Kharlamov is a Software Developer at Aversan. He has been working in an eHealth domain for almost two years, performing software testing and verification. Outside of Aversan, Denis enjoys a variety of different activities such as hiking, swimming, software & web design and development, playing video games and of course sleeping.

Disclaimer: Any views or opinions presented in this blog post are solely those of the author and do not necessarily represent those of Aversan Inc.

Sources

http://www.cs.umd.edu/projects/SoftEng/ESEG/papers/82.78.pdf

 

Share with friends

Leave a comment

Your email address will not be published. Required fields are marked *

You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Back to Top