General Guidelines for Good Programming-Part 4

General Guidelines for Good Programming:

These are general guidelines for good programming gathered from the book ‘Code Complete’ by Steve McConnel. It is a must-read book for programmers.

Process matters

The process is the way you plan and develop. You have to lay a solid foundation before you can begin building on it. If you rush to coding before the foundation is complete, it will be harder to make fundamental changes in the system’s architecture. The process you use determines how stable your requirements.  Requirements errors are far more costly than construction errors. Errors should be eliminated at the earliest stage as possible.

People will have an emotional investment in the design because they will have already written code for it. It’s hard to throw away a bad foundation once you’ve started building a house on it.

Premature optimization

Premature optimization is another kind of process error. Premature optimization wastes time because you spend time polishing sections of code that don’t need to be polished. You might polish code that you later throw away, and you might fail to throw away bad code because you’ve already spent time polishing it.

Reduce complexity

Top-level code shouldn’t be filled with details about files and stacks and queues and arrays and characters whose parents couldn’t think of better names for them than i, j, and k. Top-level code should describe the problem that’s being solved. It should be packed with descriptive class names and routine calls that indicate exactly what the program is doing.

At the top level of the program, you don’t need to know that the employee data comes as records or that it’s stored as a file.

Write code for people

When you or someone else says “This is really tricky code,” that’s a warning sign, usually of poor code. “Tricky code” is a code phrase for “bad code.”
If you think code is tricky, think about rewriting it so that it’s not. Any discomfort is a clue. If it’s hard for you, it will be even harder for the next programmers. Make it simpler.

Iterate, Repeatedly, Again and Again

Projects fail because they commit themselves to a solution before exploring alternatives. Iteration provides a way to learn about a product before you build it. Develop several prototypes for many alternative solutions before building the final product. A first attempt might produce a solution that works, but it’s unlikely to produce the best solution. Taking several repeated and different approaches produce insight into the problem that’s unlikely with a single approach.

“Team programming is more an exercise in communicating with people than in
communicating with a computer. Individual programming is more an exercise
in communicating with yourself than with a computer.”

These are the points that I have gathered from the Book ‘Code Complete’ written by Steve McConnell.  With post I end the series of General Guidelines. Really this book is amazing while reading. I have gathered all the points which seemed most important and made posts on that. Still, there is a lot to learn from this book. I personally recommend you to read this book atleast once.  Next, I have planned to read yet another best books of programming world, Clean Code.

You can buy the book using the below link:

General Guidelines Series 

1) General Guidelines For Good Programming Part 1

2) General Guidelines for Good Programming Part 2

3) General Guidelines for Good Programming | Part-3