Clean Code: LOC in method

[Ganesh Bhambure]

For clean code we have to write small methods.
Please any body tells how many max Loc for a method is consider as sign of good coding ?Any idea or pointer regarding this.

Hope !!I am not asking foolish one

[Alaa Nassef]

The default of State of Flow's metrics plugin is the maximum of 15 lines of code per method.

[Ganesh Bhambure]

hi Alaa,
thanks for replying and for useful link.

maximum of 15 lines of code per method.

But, is it Ok to create new method after every 15 line.

what do you think ?

[Alaa Nassef]

No, this is not the point . You should try to keep your methods as simple as possible, so that anyone who reads them can easily understand what each method does. Putting a maximum of 15 LOC per method is to ensure that your methods are relatively simple. Normally, when you have a large method, it can be split up into smaller more atomic methods, but if it can't be split, then be it.

[Ilja Preuss]

In my opinion, the typical method should be much smaller than 15 lines. I like one to five lines. Of course there are some that simply are bigger, not because they are complex, but because they have a big, simple switch statement or something similar.

[arulk pillai]

Having the API handy and using third party utility packages like Apache Commons, etc can help you replace a number of lines of code with just one line. For example StringUtils.isEmpty(...) that will check for both null and empty string.

[Ilja Preuss]

Originally posted by arulk pillai:
Having the API handy and using third party utility packages like Apache Commons, etc can help you replace a number of lines of code with just one line. For example StringUtils.isEmpty(...) that will check for both null and empty string.

And remember that you can write your own utility methods, too. That's probably how Apache Commons came into being in the first place...

[Ganesh Bhambure]

Originally posted by Ilja Preuss:
In my opinion, the typical method should be much smaller than 15 lines. I like one to five lines. Of course there are some that simply are bigger, not because they are complex, but because they have a big, simple switch statement or something similar.

Hi All,
But I think is it not possible to have each method of 5 lines.
Since each methods having its own significance so group related statement must be in same method so it is not acceptable to restrict method to 5-15 lines, for every cast.
Also while dividing methods into sub method we have consider cost of calling many method.
What do you think.
[ September 25, 2008: Message edited by: Ganesh Bhambure ]

[Jeff Langr]

We learn about high cohesion and low coupling as the most important indicators of a proper OO design. Yet we always seem to resist high cohesion at the method level.

Why do we resist? Well, performance is often a primary concern, and I think that's because performance numbers are easy (and entertaining) for programmer geeks to quantify. But the reality in Java is that the overhead of method calls rarely creates a problem.

To answer the prior poster, 5-15 lines is not a restriction but a guideline. There is no magic number. There are sometimes exceptions, but they should be very infrequent. For someone wrestling with the idea of fewer lines, a good guideline to start with is "fewer lines per method than you have today." Take what you have and see if you can shrink it just a bit.

Once you start seeing how easy it is to break apart longer methods, and seeing the net result, it often will start you on the path to enlightenment. Shorter methods can generate many beneficial results.

[Robert Martin]

Originally posted by Ganesh Bhambure:
For clean code we have to write small methods.
Please any body tells how many max Loc for a method is consider as sign of good coding ?Any idea or pointer regarding this.

Hope !!I am not asking foolish one

In the Clean Code book I make the point that a function should be less than 20 lines of code -- probably a lot less. Personally I like my functions to be 4 or 5 lines. I tolerate 10 line functions. I wince at functions longer than that.

Sometimes a function must be longer. Long switch statements (which should be avoided in any case) can sometimes be longer. The reality is that function length follows a power law. The vast majority of functions should be very small, but a very few will be >20 lines of code.

See Keith Braithwaite's remarkable study on this:
http://peripateticaxiom.blogspot.com/2006/05/complexity-and-test-first-0.html

[Ilja Preuss]

Originally posted by Ganesh Bhambure:

Since each methods having its own significance so group related statement must be in same method so it is not acceptable to restrict method to 5-15 lines, for every cast.

When I see methods that are fifteen lines or longer, the lines are almost invariably already clustered into groups - either by indentation, or by empty lines between them, perhaps even line comments. Typically, those clusters are quite easy to give names to (especially if they are already commented), telling what the clusters do. Use those names for the methods you extract the lines to. Voila!

[Ganesh Bhambure]

Hi Ilja,

When I see methods that are fifteen lines or longer, the lines are almost invariably already clustered into groups - either by indentation, or by empty lines between them, perhaps even line comments.

Yes , thats true.
So if long method having such group or cluster it is better to divide them into separate method. Now I get the point . Totally agree with you.

Thank You

[Ganesh Bhambure]

Hi Robert,
thanks for replying.
I got the significance of small method to make code clean.

See Keith Braithwaite's remarkable study on this:
http://peripateticaxiom.blogspot.com/2006/05/complexity-and-test-first-0.html

But this ,article is too hard to understand for me.

[Kuladip Yadav]

Hi Robert,

Personally I like my functions to be 4 or 5 lines.

But that lead to thousands methods in single class.

Is it then clean code ? Also calling number of method will completly destroy
abstraction of you code. isn't it ?

[Ilja Preuss]

Originally posted by Kuldeep Yadav:
But that lead to thousands methods in single class.

Don't stop with just extracting small methods. Also look out for new classes to create to move the methods too. This will lead to many small classes with a few small methods in it. Which is a good thing.

Also calling number of method will completly destroy abstraction of you code. isn't it ?

Quite to the contrary - if done right, you will get *better* abstractions. The class that did some big thing beforehand and also contained all the concrete details of how to do all the steps now contains only the abstract description of how to do the big thing, and delegates all the concrete details of how to do the smaller steps to more focused smaller classes.

[Jeff Langr]

Originally posted by Kuldeep Yadav:
But that lead to thousands methods in single class.

That's what would seem to happen, indeed. In practice it doesn't happen.

As I piece apart methods, I start to recognize that many of the small methods belong elsewhere. One-to-three line methods become small reusable chunks of code that might be part of a string utility class, or a collection utility class, and so on. I end up with small, single-purpose classes that are easily testable, reusable, and closed to most changes.

Reuse has been one of the promises from the dawn of OO. Cohesion has been one of the two fundamental guidelines for OO design. Yet most programmers steadfastly reject these goals by insisting on longer methods and classes.

Clean Code provides some good examples of what striving for high cohesion looks like.

Jeff

[Alaa Nassef]

Originally posted by Robert Martin:
The vast majority of functions should be very small, but a very few will be >20 lines of code.

And I've dealt with a method (in code provided by an external company) that had 1050 lines of code (850 after removing comments, white spaces, etc.)

[Robert Martin]

Originally posted by Kuldeep Yadav:
Hi Robert,



But that lead to thousands methods in single class.

Is it then clean code ? Also calling number of method will completly destroy
abstraction of you code. isn't it ?

First, you'd better not have thousands of methods in a single class. If you do, your classes are too big. Classes should have a few dozen methods, and less than a dozen variables.

Secondly, no, it doesn't destroy abstraction to have lots of little methods. Indeed, it greatly enhances abstraction. The reason is simple. When you have big methods you will almost certainly find stretches of duplicated (or nearly duplicated) code. When you break those methods into many smaller metods, you consolidate that duplicate code into single small methods. Code size can actually shrink significantly!

But that's only part of the issue. The real issue is that when you break big methods up into smaller ones, you are _organizing_ your code. You are creating places to put things, and then putting them away properly.

Remember when your mother would tell you to clean your room? You thought the big messy pile of clothes and toys was perfect because you knew where everything was. It was in your room in the big messy pile. Your mother showed you how to put everythign away in the right drawers, shelves, and closets.

Big functions are like dirty rooms. They are big piles of functionality without sufficient organization. Clean your room and keep it clean. Break your small functions up into lots of little functions.