Some books or master told us this principle: Equal or less than 15 lines per method(function), and the perfect is under(or equal) 8 lines.
Does the principle make sense for most conditions?
There are many cases break the principle in Windows OSX Android UNIX SDKs, so how to deal with the principle?
What are the exceptions for this principle?
Is it worth to take a lot of time to refactor exist code to fit this principle?
How about call another method just at 15th line?(kidding)
I hear "rules" like this all the time, but it's all to easy to try too hard to adhere to these types of rules.
I've seen code where functions are broken into illogical blocks simply to keep functions short.
I'd say that common sense is the best rule.
No one is ever going to be able to come up with a number that works in every situation. If you find a logical block of statements that can be refactored into a new method, do it and you should find your method lengths as reasonable as possible.
If you can't, but you notice that methods are getting unreasonably long, take it not as a sign you should raze them down to an arbitrary number of lines, but that maybe something else needs to be refactored, for example, maybe the class as a whole has too much responsibility.
Edit: SJuan76 also brings up an excellent point:
Q: When is 15 lines of code not really 15 lines of code?
A: When it's 15 lines of logging values/trival input validation/(etc.)
That's one of the biggest pitfalls of using lines of code as a metric, even if it's a narrow case like this. Lines of code don't convert/equate to any useful measure of "work". In one environment 10 lines might just be enough to configure an error logger, in another, 2 lines might be enough, I'd say in both cases would merit one method.
