Refactoring - Functions

Rules:

- A function does only one goal, or a grouped goal created from sub goals.

- A set of instructions is formed into a function, if it achieves a certain job that can be of multiple or future use.

- Instructions that can not be grouped into one goal or job , are classified under compound functions, and should be partitioned into sub functions.

Functions should follow defined patterns, for example a function will be more manageable if has defined exit points, increasing the exit points by adding returns, will make the function harder to debug, maintain and fix.

Return types should be documented, for example if return type is Boolean, the values that will be returned belong to the following set : {True, False}, this is manageable.

But if the return type is of bigger set for example integer belonging to set {…,-3,-2,-1,0,1,2,3,4,…}, and the function logic we wrote calculates values that belong to a smaller set N of non-negatives.

We pattern our function ‘return type’ domain to the following:

- Positive as legal value
- 0
- -1 as Error occurred for example, or nothing found

The idea is to define boundaries for the return type domain, in order to remove ambiguity.


Variables and References // global to function

Info resultInfo { Success, Result, Error}

Try
{

Critical Code instructions

resultInfo.Result = {Code Result}

}
Catch(Exception ex)
{

resultInfo.Error = ex.Message

resultInfo.Success = false // Signal failure

Log(ex) // Log error

}
Finally
{

Recurring logic, clean up or concluding calculation

}

Return resultInfo