Talk to friends, not to strangers.

There is a well-known heuristic called the Law of Demeter .

Law of Demeter says that a method f of a class C should only call the methods of these:
• C
• An object created by f
• An object passed as an argument to f
• An object held in an instance variable of C

The method should not invoke methods on objects that are returned by any of the
allowed functions. In other words, talk to friends, not to strangers

Sample Violation : final String outputDir = ctxt.getOptions().getScratchDir().getAbsolutePath();

If the code had been written as follows, then we probably wouldn’t be asking about Demeter violations.

final String outputDir = ctxt.options.scratchDir.absolutePath;

This issue would be a lot less confusing if data structures simply had public variables
and no functions, whereas objects had private variables and public functions

-- Clean Code by Robert Martin

Data Abstraction

Concrete Vehicle
public interface Vehicle {
double getFuelTankCapacityInGallons();
double getGallonsOfGasoline();
}

Abstract Vehicle
public interface Vehicle {
double getPercentFuelRemaining();
}

In both of the above cases the second option is preferable. We do not want to expose
the details of our data. Rather we want to express our data in abstract terms. This is not
merely accomplished by using interfaces and/or getters and setters. Serious thought needs
to be put into the best way to represent the data that an object contains. The worst option is
to blithely add getters and setters.


-- Robert Martin / Clean Code

More real example about how to write clean code

DO NOT DO THIS !

    // Check to see if the employee is eligible for full benefits
    if ((employee.flags & HOURLY_FLAG) &&
          (employee.age > 65))

PREFER THIS WAY

    if (employee.isEligibleForFullBenefits())

Note: Yes yes....I am planning to combine all good samplings about writing clean code under a unique Header in My Blog.

Interfaces and Implementations

Suppose that you are building an
ABSTRACT FACTORY for the creation of shapes. This factory will be an interface and will be implemented by a concrete class. What should you name them? IShapeFactory and ShapeFactory? I prefer to leave interfaces unadorned. The preceding I, so common in today’s legacy wads, is a distraction at best and too much information at worst. I don’t want my users knowing that I’m handing them an interface. I just want them to know that it’s a ShapeFactory. So if I must encode either the interface or the implementation, I choose the implementation. Calling it shapeFactoryImp, or even the hideous CShapeFactory, is preferable to encoding the interface.


In general programmers are pretty smart people. Smart people sometimes like to show off their smarts by demonstrating their mental juggling abilities. After all, if you can reliably remember that r is the lower-cased version of the url with the host and scheme removed, then you must clearly be very smart.
One difference between a smart programmer and a professional programmer is that the professional understands that clarity is king. Professionals use their powers for good and write code that others can understand.

   --Clean Code by Robert C. Martin