General Guidelines for Good Programming | Part-3

General Guidelines for Good Programming

In this post, we are going to look into some general guidelines for programming. These points are gathered from the book Code Complete.

Personal Character

Programming isn’t only about coding, it efines your character. Your employer can’t force you to be a good programmer; a lot of times your employer isn’t even in a position to judge whether you’re good. If you want to be great, you’re responsible for making yourself great. It’s a matter of your personal character.

If you’re working in a competitive software market, half of what you now need to know to do your job will be out of date in three years. If you’re not learning, you’re turning into a dinosaur.

True guru-level programmers write code that’s crystal-clear, and they document it, too. They don’t want to waste their valuable gray cells reconstructing the logic of a section of code that they
could have read in a one-sentence comment.

“Making a mistake is no sin. Failing to learn from a mistake is”

Update Yourself

If you read even one good programming book every two months, roughly 35 pages a week, you’ll soon have a firm grasp on the industry and distinguish yourself from nearly everyone
around you.

Try Alternatives

In debugging, it can be mighty satisfying to track down the error that has been annoying you for four hours, but it’s often better to give up on the error after a certain amount of time with no progress—say 15 minutes. Let your subconscious chew on the problem for a while. Try to think of an alternative approach that would circumvent the problem altogether. Rewrite the troublesome section of code from scratch. Come back to it later when your mind is fresh.

Limited Brain Capacity

The people who are best at programming are the people who realize how small their brains are. They are humble. Keeping routines short reduces the load on your brain.Writing programs in terms of the problem domain rather than in terms of lowlevel implementation details reduces your mental workload. Steps to reduce mental workload,

• Decomposing a problem using designs makes it simple to understand.
• Using conventions makes it easy to read and review. Ex: Using camel case for methods and all lower case for packages.
• Dividing a system into subsystems.
• Avoiding deep inheritance hierarchies.
• Avoiding deep nesting of loops.
• Using clear, self-explanatory variable names.
• Minimizing the number of parameters passed to a routine

Curiosity

Read about problem solving. Use what others have already written for you. Don’t try to reinvent the wheel. For Ex: You can use built-in ‘substring’ function in java, instead of writing your own.
Develop a desire to know what expert programmers think about your code. Find some good programmers who’ll give you their criticism. It can be your manager or your colleague. Write short programmers and see how it works before working on actual code.

Read the Documentation

Documentation contains the keys to the castle, and it’s worth spending time reading it. Stop searching elsewhere for information that’s readily available in documentation. Almost all the languages and tools have proper documentation which can solve your problems. Skim the documentation every couple of months.

These are the points that I have gathered from the Book ‘Code Complete’ written by Steve McConnell. Every Software Engineer Should read this book at least once. It contains lots of guides with real-time usage which can make you a better programmer.

You can buy the book using the below link:

General Guidelines Series

General Guidelines for Good Programming-Part 4

General Guidelines For Good Programming Part 1

General Guidelines for Good Programming Part 2