In object-oriented programming, there is of course no exact rule on the maximum length of a method , but I still found these two quotes somewhat contradicting each other, so I would like to hear what you think.In Clean Code: A Handbook of Agile Software Craftsmanship, Robert Martin says:The 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 not be 100 lines long. Functions should hardly ever be 20 lines  long.and he gives an example from Java code he sees from Kent Beck:Every function in his program was just two, or three, or four lines  long. Each was transparently obvious. Each told a story. And each led  you to the next in a compelling order. Thats how short your functions  should be!This sounds great, but on the other hand, in Code Complete, Steve McConnell says something very different:The routine should be allowed to grow organically up to 100-200 lines,  decades of evidence say that routines of such length no more error  prone then shorter routines.And he gives a reference to a study that says routines 65 lines or long are cheaper to develop.  So while there are diverging opinions about the matter, is there a functional best-practice for you?
What is the ideal length of a method for you?
design;object oriented;coding style
Functions should normally be short, between 5-15 lines is my personal rule of thumb when coding in Java or C#. This is a good size for several reasons:It fits easily on your screen without scrollingIt's about the conceptual size that you can hold in your headIt's meaningful enough to require a function in its own right (as a standalone, meaningful chunk of logic)A function smaller than 5 lines is a hint that you are perhaps breaking the code up too much (which makes it harder to read / understand if you need to navigate between functions). Either that or your're forgetting your special cases / error handling!But I don't think it is helpful to set an absolute rule, as there will always be valid exceptions / reasons to diverge from the rule:A one-line accessor function that performs a type cast is clearly acceptable in some situations.There are some very short but useful functions (e.g. swap as mentioned by user unknown) that clearly need less than 5 lines. Not a big deal, a few 3 line functions don't do any harm to your code base.A 100-line function that is a single large switch statement might be acceptable if it is extremely clear what is being done. This code can be conceptually very simple even if it requires a lot of lines to describe the different cases. Sometimes it is suggested that this should be refactored into separate classes and implemented using inheritance / polymorphism but IMHO this is taking OOP too far - I'd rather have one big 40-way switch statement than 40 new classes to deal with.A complex function might have a lot of state variables that would get very messy if passed between different functions as parameters. In this case you could reasonably make an argument that the code is simpler and easier to follow if you keep everything in a single large function (although as Mark rightly points out this could also be a candidate for turning into a class to encapsulate both the logic and state)Sometimes smaller or larger functions have performance advantages (perhaps because of inlining or JIT reasons as Frank mentions). This is highly implementation dependent, but it can make a difference - make sure you benchmark!So basically, use common sense, stick to small function sizes in most instances but don't be dogmatic about it if you have a genuinely good reason to make an unusually big function.