Functions¶

Functions are the first line of organization in any program. So Keep that function should be understandable and readable.

Small!:The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that.

Do One Thing: FUNCTIONS SHOULD DO ONE THING . THEY SHOULD DO IT WELL . THEY SHOULD DO IT ONLY .

Sections within Functions : function is divided into sections such as declarations, initializations, and sieve.

One Level of Abstraction per Function: Mixing levels of abstraction within a function is always confusing. So do not do like that.

Reading Code from Top to Bottom: The StepDown Rule¶

We want every function to be followed by those at the next level of abstraction so that we can read the program, descending one level of abstraction at a time as we read down the list of functions. I call this The Step-down Rule.

Switch Statements: ¶

do not write more switch case ,instead of that use ABSTRACT FACTORY .

Use Descriptive Names :¶

Don’t be afraid to make a name long. A long descriptive name is better than a short enigmatic name. A long descriptive name is better than a long descriptive comment.

Function Arguments¶

arguments are zero arguments ,monodic arguments and two arguments and three arguments and soon. Do not use more than one argument as an argument.

Arguments are hard. So avoid more number of arguments in function call.

Common Monodic Forms¶

There are two very common reasons to pass a single argument into a function. asking a question about that argument, operating on that argument, transforming it into something else and returning it.

You should choose names that make the distinction clear, and always use the two forms in a consistent context.

Try to avoid any monodic functions that don’t follow these forms ,for Example StringBuffer transform(StringBuffer in) is better than void transform (StringBuffer out) , even if the implementation in the first case simply returns the input argument.

Flag Arguments:¶

Flag arguments are ugly. So don’t pass Boolean as argument.

Dyadic Functions: ¶

A function with two arguments is harder to understand than a monodic function.

For example, you might make the writeField method a member of outputStream so that you can say outputStream. writeField(name) .

Or you might make the outputStream a member variable of the current class so that you don’t have to pass it. Or you might extract a new class like FieldWriter that takes the outputStream in its constructor and has a write method.

Triads :¶

the function with three arguments are harder to understand than dyadic function.

We can not remember arguments order. So avoid triads .

Argument Objects ¶

Instead of taking more number of arguments. Reducing the number of arguments by creating objects . For example:

Circle makeCircle(double x, double y, double radius);
Circle makeCircle(Point center, double radius);

Argument Lists¶

Do not take more number of arguments instead of that take var arguments.

Verbs and Keywords¶

Choosing good names for a function can go a long way toward explaining the intent of the function and the order and intent of the arguments.

For example, assertEquals might be better written as assertExpectedEqualsActual(expected, actual) .

Have No Side Effects¶

Your function promises to do one thing, but it also does other hidden things. So do not write like that.

Output Arguments :¶

do not take output as an argument.

Command Query Separation¶

Do not write like this:

if (set("username", "unclebob"))...

Separate query and command like this :

if (attributeExists("username")) {
setAttribute("username", "unclebob");
...
}

Prefer Exceptions to Returning Error Codes

Extract Try/Catch Blocks: ¶

it is better to extract the bodies of the try and catch blocks out into functions of their own.

Error Handling Is One Thing :¶

Functions should do one thing. Error handing is one thing. So separate error handling code. If the try Keyword Exists in a function it should be a first statement and after catch also do not put other statements.

The Error.java Dependency Magnet¶

Do not write enum’s or return code for handling of errors. Instead of that take Exception.

Don’t Repeat Yourself;¶

Do not write similar code in multiple places Instead of that write once and reuse that code in multiple places.

Structured Programming ¶

function should have one entry and one exit. This means that here should only be one return statement in a function, no break or continue statements in a loop, and never, ever, any goto statements.

keep your functions small.

How Do You Write Functions Like This?¶

So then I massage and refine that code, splitting out functions, changing names, eliminating duplication. I shrink the methods and reorder them. Sometimes I break out whole classes, all the while keeping the tests passing.

Conclusion¶

your functions will be short, well named, and nicely organized.