Good VS Bad

What is bad code?

In simple way bad code is when a programmer or coder make program to get things done faster without thinking much about future changes and ignoring the possibility of other developers touching the code.

If you are a programmer, you have probably been significantly slowed down by someone else’s messy(bad) code, the degree of slow down caused from messy code can be significant, over one or two year teams were moving very fast at the beginning of a project can find themselves moving as snail’s. Every change they make to the code breaks two or three other parts of the code. No change is trivial. Every addition or modification to the system requires that the tangles, twists, and knots be “understood” so that more tangles, twists, and knots can be added. By the time and as the mess builds, the productivity of the team continues to decrease, asymptotically approaching zero.

There is a lot of real examples on how the bad code can affect on companies one of them that, in the late 80s there was a company, wrote a killer app. It was very popular, and lots of professionals bought and used it. But then the release cycles began to stretch. Bugs were not repaired from one release to the next. Load times grew and crashes increased. I remember the day I shut the product down in frustration and never used it again. The company went out of business a short time after that. Two decades later I met one of the early employees of that company and asked him what had happened. The answer confirmed my fears. They had rushed the product to market and had made a huge mess in the code. As they added more and more features, the code got worse and worse until they simply could not manage it any longer. It was the bad code that brought the company down.

Why does this happen to code? Why does good code rot so quickly into bad code?

We have a lot of explanations for it. As that the code has poor adaptation to change, The schedules that were too tight to do things right. bad plaining with managers about the schedules offcourse managers want good code but their main goal is to receive the project before deadline because that’s their job and it is our job as programmers to write an efficient code, this is similar to what if you were a doctor and had a patient who demanded that you stop all the silly hand-washing in preparation for surgery because it was taking too much time? Clearly the patient is the boss; and yet the doctor should absolutely refuse to respond. Why? Because the doctor knows more than the patient about the risks of disease and infection. It would be unprofessional (never mind criminal) for the doctor to respond with the patient. So too it is unprofessional for programmers to bend to the will of managers who don’t understand the risks of making messes.so the true professionals programmers know that this messy code will slow them down and by the time it will lead to miss the deadline so we will conclude that the only way to make the deadline—the only way to go fast—is to keep the code as clean as possible at all times.

What is good code?

There are probably as many definitions as there are programmers.so this is opinions of very well-known and deeply experienced programmers what they thought.

Bjarne Stroustrup, inventor of C++ and author of The C++ Programming Language

“I like my code to be elegant and efficient. The logic should be straightforward to make it hard for bugs to hide, the dependencies minimal to ease maintenance, error handling complete according to an articulated strategy, and performance close to optimal so as not to tempt people to make the code messy with unprincipled optimizations. Clean code does one thing well.”

Bjarne emphasis on the word “pleasing” he thinks that clean code is pleasing to read, reading it should make you smile. Bjarne also mentions “efficiency” twice he wants to emphasis on how important is the efficiency

Grady Booch, author of Object Oriented Analysis and Design with Applications

“Clean code is simple and direct. Clean code reads like well-written prose. Clean code never obscures the designer’s intent but rather is full of crisp abstractions and straightforward lines of control.”

He takes a readability perspective. I especially like his view that clean code should read like well-written prose

“Big” Dave Thomas, founder of OTI, godfather of the Eclipse strategy

“Clean code can be read, and enhanced by a developer other than its original author. It has unit and acceptance tests. It has meaningful names. It provides one way rather than many ways for doing one thing. It has minimal dependencies, which are explicitly defined, and provides a clear and minimal API. Code should be literate since depending on the language, not all necessary information can be expressed clearly in code alone.”

Dave asserts that clean code makes it easy for other people to enhance it. Dave emphasis on testing Code, without tests it is unclean. No matter how elegant it is, no matter how readable and accessible, if it has not tests, it be unclean. Dave uses the word minimal twice. apparently he values code that is small, rather than code that is large.

?

?

Michael Feathers, author of Working Effectively with Legacy Code

“I could list all of the qualities that I notice in clean code, but there is one overarching quality that leads to all of them. Clean code always looks like it was written by someone who cares. There is nothing obvious that you can do to make it better. All of those things were thought about by the code’s author, and if you try to imagine improvements, you’re led back to where you are, sitting in appreciation of the code someone left for you—code left by someone who cares deeply about the craft”

Michael concludes that clean code is code that has been taken care of. Someone has taken the time to keep it simple and orderly. They have paid appropriate attention to details. They have cared.

Ward Cunningham, inventor of Wiki, inventor of Fit, coinventor of eXtreme Programming. Motive force behind Design Patterns. Smalltalk and OO thought leader.

“You know you are working on clean code when each routine you read turns out to be pretty much what you expected. You can call it beautiful code when the code also makes it look like the language was made for the problem”

Ward expects that when you read clean code you won’t be surprised at all. Indeed, you won’t even expend much effort. You will read it, and it will be pretty much what you expected. It will be obvious, simple, and compelling. Each module will set the stage for the next. Each tells you how the next will be written. Programs that are that clean are well written, wards emphasis on beauty because it is not the language that makes programs appear simple. It is the programmer that make the language appear simple.

The boy scout rule

“Leave the campground cleaner than you found it”

If we all checked-in our code a little cleaner than when we checked it out, the code simply could not rot. The cleanup doesn’t have to be something big. Change one variable name for the better, break up one function that’s a little too large, clean up one composite if statement.