Assertive Programming

 If you believe that something can never happen in your code, use assertions to ensure that. Never go with assumptions only.

"This code won't be used 30 years from now, so two-digit dates are fine."
"This application will never be used abroad, so why internationalize it?"

Always avoid this kind of self-deception.

In C and C++, we have assert macros which check a boolean condition. Here is an example:

void writeString(char *string) {
   assert(string != NULL);
   ...
}

This assert statement checks for a null string before executing the code inside the method. The execution stops when it encounters a null string.

While using assertions, make sure that they don’t make any side effects. The conditions passed to assertions may sometimes create side effects. Never put code that has to be executed as a part of the program into an assert statement.

Asserts shouldn’t be used for real error handling. Assertions check for things that should never happen.

Leave Assertions Turned On

Some people have a misunderstanding that assertions will become overhead after testing and deploying to production, and hence they should be turned off in production. The real problems start in production, not while developing or testing. Always leave the assertions turned on.

Turning off assertions when you deliver a program to production is like crossing a high wire without a net because you once made it across in practice. There's dramatic value, but it's hard to get life insurance.



- summary of Assertive Programming, from The Pragmatic Programmer: from Journeyman to Master

Dead Programs Tell No Lies

Sometimes other people can easily find what’s not right with us, even before we realize it. It is true with other people’s code too. If something goes wrong in our code, sometimes it is a library routine that catches it first. In normal case, it is easy to fall into the "it can't happen" mentality.

But pragmatic programmers always code defensively. We always look for rogue pointers in other parts of the program. We always check that the correct versions of shared libraries were actually loaded.

All errors give you information. You could convince yourself that the error can't happen, and choose to ignore it. Instead, Pragmatic Programmers tell themselves that if there is an error, something very, very bad has happened.

Crash, Don’t Trash

It is always better to crash immediately after finding a problem than going wrong indefinitely. One example for this is Java. It throws an exception when something wrong happens. If that exception is not handled properly, the execution stops. In languages like C, which doesn’t not support exceptions, we can make use of macros.

When our code discovers that something that was supposed to be impossible happened, our program is no longer viable. Terminate it as soon as possible. A dead program normally does a lot less damage than a crippled one.

- summary of Dead Programs Tell No Lies, from The Pragmatic Programmer: from Journeyman to Master

Design By Contract (Part 1)

A contract defines the rights and responsibilities of a person, as well as those of the other party. Each party respects their commitments and everyone benefits. We can use the same concept to make software modules interact.

The concept of Design by Contract was developed by Bertrand Meyer, for the language Eiffel.

Every methods in a software system does something. Before doing that, the routine may have some expectations. Meyer describes these expectations and claims as follows:

• Preconditions - The requirements for the routine. It defines what must be true for the routine to be called.
• Postconditions - What the routine guaranteed to do. This defines the state of the world when the routine finishes its tasks
• Class invariants - A class ensures that this condition is always true from the perspective of a caller. By the time the routine exits and control returns to the caller, the invariant must be true.

- summary of Design by Contract, from The Pragmatic Programmer: from Journeyman to Master

Pragmatic Paranoia

While driving, everyone personally thinks that they are the only good driver on Earth. We find all other drivers violating the rules. Then we start driving defensively. We look out for trouble before it happens. We always expect the unexpected.

The situation is similar in software world. We constantly encounter code written by other programmers - code that might not live up to our high standards. We check for errors or bad data.

But pragmatic programmers are always a step ahead.

They don't trust themselves, either!

No one writes perfect code. There is nothing called perfect software. We all should accept this fact. Pragmatic programmers code in defenses against their own mistakes.

Here, we’ll discuss about the defensive measures we take while coding.


- summary of Pragmatic Paranoia (introduction), from The Pragmatic Programmer: from Journeyman to Master

The Art of Simplicity (Part 1)

It was for the first time, that we were visiting Technopark, Trivandrum. That’s one of the main reasons as to why we reached a little late. Dr. Venkat Subramaniam had already started delivering his keynote on The Art of Simplicity. Here, I am extracting some key points from it (I am directly jumping into the topic since I missed the first few minutes of the session!)...

Simplicity.. Being simple is always distraction-free. One example that we see and use in our day to day life is Google. Imagine, we are in the middle of a serious coding session. Suddenly, some confusion strikes our mind and we decide search for a better implementation or syntax. In the World of internet, there are a lot of things that can distract us. They tempt us to navigate away from our real goal, thereby, wasting a good share of our productive time.

This is where Google comes to help us. In the home page of Google, there is nothing to deviate us from our real intention. Just search, get what you want and leave! The real courage lies in developing such simple and elegant systems rather than complicating it with detailed designs or images.

Simple fails less. If at all it fails, it is always easy to find out the problem and cure it. Simple is always easy to understand.

Simple is always mutable. We neither have to change much, nor worry about anything else before changing it.

Here is a famous quote by Richard Feynman, an American theoretical physicist:

If you can't explain something to a first year student, then you haven't really understood it.

(to be continued...)



Thanks to +Vaishnavi M K and +Arun Prakash for your suggestions and proofreading.. :-)

Active Code Generators

Passive generators are used for convenience. But active generators are required if we want to follow the DRY principle. An active generator takes a single piece of information in one format and converts it into different formats. The generated code is disposable. The code is generated as needed by the generator. Whenever we find ourself trying to get two disparate environments to work together, we should consider using active code generators.

Active generators can be used in situations when we have multiple programming languages in a single application. In order to communicate, each code base will need some information in common, like data structures, message formats etc. Sometimes, we can parse the information out of the source files of one language and use it to generate code in a second language.

Code generators need not be complex. Keep the input format simple, and the code generator becomes simple.

Code generators need not generate code.  

It can be used to generate any text that is required in our project.


- summary of Code Generators, from The Pragmatic Programmer: from Journeyman to Master

Passive Code Generators

Passive code generators saves typing. They generate a given output from a set of inputs. The generated output is an independant source file. The origin of the file will be forgotten.

Passive code generators can be used for:

Creating new source files: While creating a new source file, some editors automatically add basic code, comments and other auto generated blocks to the file. This is done by using a passive code generator. They can be also used for generating source code control directives or copyright notices.

Performing conversions among programming languages: Passive code generators can be used for performing one time conversion of code from one programming language to another. The conversion need not be 100% accurate. We get to choose how much effort you put into the generator, compared with the energy we spend fixing up its output.

Producing lookup tables and other resources: Many of the earlier graphics systems were using precomputed tables, instead of calculating the trigonometric values, for sine and cosine values. These lookup tables were generated using passive code generators.

- summary of Code Generators, from The Pragmatic Programmer: from Journeyman to Master