What's the score of your functions?

Any fool can write code that a computer can understand. Good programmers write code that humans can understand. - Martin Fowler

Functions are the basic building blocks of any programming language, but is your function clean and readable?

Below is the list of Rules/Qualities of a good function along with its score.See if your functions follows these rules and score yourself.

1.Small

• First rule of functions is that they should be small.
• The second rule of functions is that they should be smaller than that.
• Functions should hardly ever be 15 lines long.

2.Do One Thing

• FUNCTIONS SHOULD DO ONE THING. THEY SHOULD DO IT WELL. THEY SHOULD DO IT ONLY.
• Another way to know that function is doing more than "One Thing" is if you can extract another function from it with a name that is not merely a restatement of its implementation.

3.Descriptive Names

• Functions should have verb or verb phrase names like postPayment, deletePage.
• Don't be afraid to make a name long. A long descriptive name is better than a long descriptive comment.
• Choosing descriptive names will clarify the design of the module in your mind and help you improve it.It is not at all uncommon that hunting for a good name results in favorable restructuring of the code.

4.Ideal Function Arguments

• The ideal number of arguments for a function is zero(niladic).
• Next comes one(monadic).
• Followed closely by Two arguments(dyadic).
• More than three(polyadic) requires very special justification and then shouldn't be used anyway.

5.Have no Side Effects

• According to wikipedia, In computer science, an operation, function or expression is said to have a side effect if it modifies some state variable value(s) outside its local environment, that is to say has an observable effect besides returning a value (the main effect) to the invoker of the operation.
• Side Effects are lies. Your function promises to do one thing, but it also does other hidden things.

6.Command Query Separation

• Function should either do something or answer something, but not both.
• Either your function should change the state of an object, or it should return some information about that object.
• Doing both often leads to confusion.

7.Don't Repeat Yourself

• Duplication may be the root of all evil in software.
• Never write the same code twice, always create the reusable functions.

8.Blocks and Indenting

• This implies that the blocks with if statements, else statements, while statements and so on should be one line long. Probably that line should be a function call.

9.The Stepdown Rule

• We want the code to read liek a top-down narrative.
• 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.

10.Structured Programming

• Dijkstra said that every function and every block with in a function, should have one entry and one exit.
• Following these rules means that there should only be one return statement in a function, no break or continue statements in a loop and never,ever any goto statements.

How do you write a score 100 function ?

The first draft might be clumsy and disorganized, so do you wordsmith it and restructure it and refine it until it read the way you want it to read(100 score). Just keep refactoring the code until you hit the score 100.

Comment down your score and if you know more important function rules #discuss.

P.S: These rules are taken from the book The Clean Code by Robert C.Martin, I strongly recommend to read it, Its awesome.

This is a series from my JEDI-JOURNEY, where we become the JEDIs by reading tons of books, you too can tag along,

https://github.com/sksaifuddin/jedi-journey