Writing Good Functions/Methods

The number of lines in the code is referred to as the length of the code. The code may contain methods, classes, interfaces, and packages. The length of the methods/classes should not be too long. In such cases, split the lengthy methods and classes into smaller ones.

Methods

Writing smaller methods help in understanding the code better and makes debugging easily. The best methods are considered to be from 10 to 20 lines (maximum). Having more than 20-30 lines will be considered bad code. The maximum method length again may vary depending on the Project. But better to Keep It Simple and Short (KISS).

Minimize Your Code

Don’t write three lines of code if the same thing can be done with only one line. It means that before adding some block of code you need to think about the best approach you can apply to this piece of code. 

Let’s consider an example:

boolean hasCreditCard(User user) {

    if (user.hasCard) {

        return true;

    } else {

        return false;

    }

}

At first look, this method seems to be normal, but it can be simplified:

boolean hasCreditCard(User user) {

    return user.hasCard;

}

One job per method

The method should do one job. It should not be doing more than one job. 

Example: 

void fun(int number)

{

       int fact=1;

      for(int i=1; i<=number ; i++)

      {

            fact=fact*i;

      }

     System.out.println(“factorial of  “+number+” =”+fact);

      int sum=1;

      for(int i=1; i<=number ; i++)

      {

            sum=sum +i;

      }

     System.out.println(“Sum of natural Number upto  “+number+” =”+sum);

The above code is doing two jobs one to find out the factorial of a given number and the second one is to find the sum of natural numbers.   

This can be refactored (modified) into two functions call them whenever required.

 int factorialOfNaturalNumber (int number)

  {

       int factorial=1;

      for(int i=1; i<=number ; i++)

      {

            factorial = factorial *i;

      }

      return factorial;

  }

  int sumOfNaturalNumber(int number)

  {     int sum=0;

   

      for(int i=1; i<=number ; i++)

      {

            sum=sum +i;

      }

     return sum;     

  } 

Call the functions/methods where ever you want.

Example.

int factorial = factoirialOfNaturalNumber(10);

int sum  =  sumOfNaturalNumber(100);

Use Descriptive Names. 

The function name withdrawAmount is better than withdraw.

Half the battle to achieving that principle is choosing good names for small functions that do one thing. The smaller and more focused a function is, the easier it is to choose a descriptive name.

Don’t be afraid to make a name long. A long descriptive name is better than a short enigmatic name and a long descriptive comment. Use a naming convention that allows multiple words to be easily read in the function names, and then make use of those multiple words to give the function a name that says what it does.

Method Arguments

The ideal number of arguments for a method is zero (niladic). Next comes one (monadic), followed closely by two (dyadic). Three arguments (triadic) should be avoided where possible. More than three (polyadic) require very special justification—and therefore shouldn’t be used anyway.

  • Passing a Boolean value into a function is a very terrible practice
  • Functions should have a minimum number of arguments. For good code maximum of 3 variables are sufficient. More arguments will make code complex.

Here is an example with more number of arguments

// bad code

 func(int a, int b, int c, int d, int e, int f)

can be divided into smaller functions depending on the functionality

// good code

func1(int a, int b, int c)

..

.

func2(int d, int e, int f)

.

.

Blocks and Indenting 

  • The functions should not be large enough to hold nested structures. Therefore, the indent level of a function should not be greater than one or two. This, of course, makes the functions easier to read and understand.
  • Not only does this keep the enclosing function small, but it also adds documentary value because the function called within the block can have a nicely descriptive name.
  • The functions should not be too large to hold nested structures.
  • The indent level of a function should not be greater than one or two. This, of course, makes the functions easier to read and understand.

// bad code

for( int i=1; i<=number1; i++) {

    for( int j=1; j<=number2;j++)   {    

         if(cond2)  {

            for(int k=1;k<=number3;k++) {

                 if(cond3) {

                 }

            }

       }

    }

}

Avoid such complex code. Break down the nested code into smaller functions and call the functions. 

// good code

for( int i=1; i<=number1; i++)

{

    for( int j=1; j<=number2;j++) {   

        function1()

    }

}

function1()

{

   if(cond2){

      function2()

    }

}

function2()

{

   for(int k=1;k<=number3;k++){

         if(cond3) {

         }

    }

}

Key points

  • The length of Functions/Methods should be small. 
  • Functions/Methods should do only one thing and they should do it well.
  • Functions/Methods should have meaningful names.
  • Functions/Methods should have proper blocks and indentation.
Did this answer your question? Thanks for the feedback There was a problem submitting your feedback. Please try again later.

Still need help? Contact Us Contact Us