How to Balance Resources?

Most of the time, the resource usage in a system follows a specific pattern: we allocate resources, use them and then deallocate it. But many developers have no consistent plan for dealing with resource allocation. So, here is a simple tip:

Finish What You Start…

This means that the routine or object which allocate the resources is also responsible for deallocating it.

Nested Allocation

When the routines require more than one resource, consider the following two suggestions:

1. Deallocate resources in the opposite order in which we allocate them. If one resource contains reference to another, this will ensure that no orphaned resources are there in the system.
2. When we allocate the same set of resources at different places, always allocate them in the same order. This will reduce the possibility of deadlocks happening in the system.

Objects and Exceptions

Classes can be used for allocating and deallocating resources. We can encapsulate resources in a class. When we need a particular resource type, instantiate an object of that class. When an object is created, the constructor allocates the resources. When the object goes out of scope, or is reclaimed by the garbage collector, the object's destructor then deallocates the wrapped resource.

This approach is particularly useful while working with languages like C++.



- summary of How to Balance Resources, from The Pragmatic Programmer: from Journeyman to Master

When to use Exceptions?

Checking for errors at every part may lead to developing ugly code. That is where exceptions come into handy. But the problem with exception is, we need to have a clear idea of when to use them. Exceptions should be reserved only for unexpected events.

For example, consider this scenario. If our code is trying to open a file for reading and that file does not exist, should we raise an exception? It depends. If the file should have been there, but we cannot find them, then it is exceptional. But imagine that we have only the filename. We don’t know where exactly the file is and we cannot find them, then an error return will be more appropriate.

Programs that use exceptions as a part of their normal processing suffer from readability and maintainability problems. These programs break encapsulation as their methods and their callers are tightly coupled via exception handling.

Use Exceptions for Exceptional Problems



- summary of When to use Exceptions, from The Pragmatic Programmer: from Journeyman to Master

The Art of Simplicity (Part 2)

Most of the time, we never realize why some concepts are simple until we think about them. Just consider this example. Have you ever wondered why manholes are round in shape? We could have made them in many other shapes, say squares or real artistic ones.

Not many people had an answer when Venkat asked this question to the audience. For shapes other than round, there is a greater chance for its lid to fall into the hole. But with a round lid, we don’t face this problem. It can also be easily moved by rolling. Also, at the end of a long tiring day, the workman doesn't have to worry in which direction the lid has to be placed to close the hole properly. See how a very simple design helped in solving many issues that could have happened.

Have you ever given a thought why Mona Lisa is considered to be a masterpiece? Along with the fact that it was painted by the famous artist, Leonardo Da Vinci, it is simplicity that always attracts people towards it.

The essence of this keynote was this: Never complicate things too much.

He concluded the session with a very nice story based on Richard Feynman’s quote...

• • • 

Once, I was giving lectures to a bunch of students in the college. I was teaching the same stuff from past one decade. But, for the first time, something strange happened. All the students had nothing to say, after an hour long lecture , other than-

“Sir, we didn't understand anything!”

I was puzzled. I didn't know what had happened. I went back home. I kept  thinking and thinking about it. Then, I went back to read the same topic.

Slowly and surprisingly, I started understanding better. I uncovered many aspects and by the end of  that night, I got a clear picture about the entire concept.

Next day, I went to the same class and started with the same lecture, but with a new insight. Within five to ten minutes, I could make out that every student understood the concept clearly. All students were happy and they exclaimed-

“Sir, why couldn't we understand this yesterday? It is really very easy. ”

“It is simple. I hadn't really understood what I was teaching till yesterday. But now I know.”

• • • 

- summary of the keynote, The Art of Simplicity, by Dr. Venkat Subramaniam (Agile Kerala 2013)


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

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