Creating better methods

A good method should give you 3 important information.

1. Responsibility of method - Method should always have single and unique responsibility.
2. Input type of method - Method should accept specific argument number and types.
3. Return type of method - Method should return a particular type of value and not mix type.

Beside this there are some more important points need to be taken care of.

Length of method - This is very interesting part a lot of people have a lot of views on it.

My personal believe is the function/method definition length should have 5-10 lines as soft limit and 5-15 lines as hard limit.

However, if you would like to follow FORTH language’s principle, modules were hard-limited to an absolute maximum of 16 lines of 64 characters.

Another reference is Psychology Computer Programming by Gerald_Weinberg with the same principle as above.

Another good reference is Refactoring in Large software projects by Martin Lippert and Stephen Roock suggesting rule of 30

If an element consists of more than 30 subelements, it is highly probable that there is a serious problem:-

a) Methods should not have more than an average of 30 code lines (not counting line spaces and comments).

b) A class should contain an average of less than 30 methods, resulting in up to 900 lines of code.

c) A package shouldn’t contain more than 30 classes, thus comprising up to 27,000 code lines.

d) Subsystems with more than 30 packages should be avoided. Such a subsystem would count up to 900 classes with up to 810,000 lines of code.

e) A system with 30 subsystems would thus possess 27,000 classes and 24.3 million code lines.

1. Proper access specifier
2. Open for Overriding
3. Open for Overloading
4. Document Comment - It should describe the first 3 information I have described on top.
5. If it is an accessor, it should have same return type is same as the type of attribute. If it is a mutator, the input type is same as the type of attribute, if there is any extra operation, it can be extract to another method.
6. Unit Test - As the method has single responsibility/unit responsibility, now it is easier to write unit test :D

Note: I have not described about access specifier, overriding and overloading as there is already a lot of resource available on this and most people have knowledge of it.

Some snippet:-

get{Attribute}() // To retrieve the attribute value,*  must return the value with same return type as attribute

set{Attribute}($attribute) // To set the attribute value, * Could return null or current instance

is{Attribute}() //To check if the attribute is present or not, * Should return boolean

in{Attribute}Collection() // To check if it is present in specified collection, * Should return boolean

get{Attributes}Count() // Count the number of attribute, *Should return integer value

get{Attributes}Total() // Calculate total of attributes, *Should return integer/float depending on type of attribute

Note: Keep your eyes on my articles it will get updated frequently.