10 Simple Rules For Best Programming Practices/Tricks

Have you ever 🤔 thought about how do you write code after spending many years in programming? Yes! I know all of us of think that we write efficient and readable code. But I mean really we do? The goal of this article is to list out a few good programming practices that I think everyone should start using them. Let’s take a look at these:

1. Don’t ignore the Exception

Exception, what exception It won’t be serious. Honestly, I can ignore it. This is not a winning strategy for solid code. In fact, it is just laziness. You’re not saving time if you ignore error; you’re storing up potential problems for your future.

No handling exceptions can lead to:

• Brittle code: Code that’s filled with exciting, hard-to-find bugs.
• Poor structure: If there are errors from your code that are tedious to deal with continually, you probably have a poor interface.

There is a number of common excuses, which of the following you agree with:

• It’s extra work, and I have a deadline coming up.
• Exception handling clutters up the flow of the code, making it harder to read, and harder to spot the “normal” flow of execution.
• It’s only a toy program, and needn’t be written to a production-worthy level.

2. Don’t just Restructuring

The restructuring will not always guarantee that the new code will be better–or even as good as–the previous attempt. I’ve seen several failed restructuring attempt. If something isn’t broken, why fix it? That’s the style or the structure of the code does not meet your personal preference is not a valid reason for restructuring. Thinking you could do a better job than the previous programmer is not a valid reason either.

3. Pay attention to Performance

Not paying attention to performance is also a mistake that most programmers can easily make. We can no longer rely on ever-increasing processor clock and user network speed to improve application performance. At a time of writing the code, experienced programmers already know how the performance of this function is, and where is the bottleneck. When performance is a problem in an application, sometimes the data structures and algorithms aren’t the right places to look for improvements. Response time depends most strongly on the database calls are usually executed sequentially in a single thread. Their individual latencies accumulate, contributing to the overall response time.

By the way, I wrote an article on Basic Tips For Application Performance Optimization go and check it out.

4. One-liner Solution

We all know that writing a single line code, it looks awesome. But sometimes we write efficient, elegant piece of code with combinators of function & regular expressions that turn 8 or maybe 10 lines of code into a single line.

val launchMissileStatus = missile.getLaunchMissileObject(
            prepareConfiguration().getConfig().confidId,
            getSecureSSHKey(getAdmin().adminId),
            getConnectivityManager()
        ).setLaunchPlaceName(getSomeTargetPlace().placeName)
            .launchcMissile()
        if (launchMissileStatus)
            println("Missile successfully launched")

Unfortunately, it does not always result in readable code, and that’s generally the important thing. Make your code readable and easy to debug.

5. Names should be Logical

The next time you read some code, stop and think for a moment. Is this easy or hard to read? Is naming inconsistent or illogical? As long as the names add some kind of information that the rest of the code doesn’t convey, other developers will have an easier time reading your code. The reason that naming is so important is that the names can give a general idea of what the code does.

My University Sir (Abdul Wahab), often used to say that naming of function and variables should be logical and it gives you the whole meaning of what they would do in the program. 

6. Personal attachment is not Good

Personal preference and ego shouldn’t get in the way. If someone comments on your code don’t take it personally, you should stand solid on the ground and explain him/her why you wrote it. If it needs improvement that’s only a reflection of code.

7. First integrate, then test, and then give Up

Many times, when a programmer introduces a third party library, framework, interface, or service their favorite thing is to integrate directly with its own code. What is the result? Suddenly I can’t use it. I can’t run it. I don’t know where the problem is, I can’t tell if it is third party library problem or my own problem. So, you always need to run the official demo first and then find a way to add your business logic to it.

8. Collect requirements before writing Code

The good habit of writing code should be to go through all the details of the requirements in the head and get the details out. Not everything you learn has to be about technology. Learn the domain you’re working in so you can better understand the requirements and help solve the business problem. Learning how to be more productive–how to work better–is another good option. The more you involve in understand the requirements and solve the business problem; the more chances to get promoted.

The Programmers do not set system requirements; the customer does.

9. Do write unit Test

Writing unit test provides evidence about how easy the code unit is to unit test. It helps reveal the presence of development qualities you’d like the code to exhibit, such as low coupling and high cohesion. Many programmers can’t understand the value of a unit test. It doesn’t matter when the code is refactored and the demand changes, you can’t cry out! Good unit testing, your logic will be clear.

A good unit test provides evidence about the code’s behavior.

10. Refuse to write bad code

Many freelancers like (me) have pressure from our clients to make quick changes to an application. You’ve tried to tell your client about the consequences, but they insist on sticking to the deadline or perhaps there’s an urgent bug that can’t wait for you to come up with a clean solution. That’s why it’s important to be versatile as a programmer and to be able to write poorly code as well as good code. After writing the poor code most programmers will preserve bad code, fearing that starting a new will require significantly more efforts than just going back to the beginning. In last I just want to say that, in the future, you can revisit that poor code and payback to technical debt.

I hope you enjoyed this programming practices article! Anything that I missed let me know via comments. I’ll be very grateful if you share the article with the community.

Thank you for being here and keep reading…