Things that you can learn from others programming mistakes

Generally, musicians compose a piece and listen to it carefully when his orchestra plays it to find out the bad notes. Similarly code review is all about going to through the code written by your team and trying to find out the bad practices or approaches involved which lead to unexpected behaviour.

Last 10 days I was involved in a project doing code reviews — helping the client maintain better coding standards.

This project on which I worked basically is built by a team of three good salesforce developers. The timelines were insanely crazy and the developers did their best to ship the product on time. Knowing the developers personally, given some more time am 100% positive they would have contributed better code.

As a result of quick deliverables there were many things that needed a heads-up.

In this post I will try to mention few important take aways you can consider. These are going to be a combination of both general and architectural tips.  I tried my level best to put it short and condense it down to just a few of them.

These are the general ones ..

1. Always have better and consistent naming conventions to your ClassNames, methodNames and variableNames.

It’s not always about finishing things before the deadlines. We also need to think of other developers who will be working on that project at a later point of time.

If he is someone who knows where you stay, he is going to come to your place and beat you up! 🤣

• Start the classname with capital letter and have the first letter of every word in capital letters. Something like this .. AccountController, UserUtils and etc.

Try avoid having the class names in the following manner

• accountcontroller
• accountController
• account_Controller

However, nothing wrong in having the above mentioned naming conventions, but it's suggested to avoid these variants.

• Start the method with a small letter and have first letter of every word in capital letters(Camel Casing). Same is the case with variables too.

• It’s suggested to have all the Constant variables in UPPERCASE where words are separated by underscore character (“_”). Make sure to use final modifier with constant variables. Something like this.

public final String SECURITY_TOKEN = "...........";

2.  Do not always use public Access Specifier for Classes. Expose them only required. Default Access Specifier is private and leave it alone that way.

3.  Code should be refactored to make sure it’s easily understandable rather than trying to stuff everything in one method am make it one big fat method.

That way its becomes lot more easy for other developers to understand and debug it.

When you are searching for something in your private room it becomes lot more easy for you to get hold of it when its properly organised, isn’t it. Same principle applies to programming too.

Move all the frequently used utility methods to Utility Classes

Try moving all the business logic which is not the main goal of the application to helper methods in Helper Classes.

4.  Always add comments.

I make it a point to write the code(break/refactor the code) in such a way that comments are not required in the first place.

But I always add comments.

So the gist is, write the code as if you dont need comments but always have them.

At the same time avoid the most obvious comments.

These are the general things that I wanted you to consider and in the next post I will mention the technical or architectural considerations you need to take.