From: Robert Klemme Date: 2006-05-10T00:38:38+09:00 Subject: Re: Method Size - Best Practices 2006/5/9, ara.t.howard@noaa.gov : > On Tue, 9 May 2006, Pistos Christou wrote: > > > Eric Hodel wrote: > >> My unit tests typically tell me which line my errors are on. You > >> probably haven't written enough tests for your code or aren't writing > >> small enough chunks of code. > >> > >> The biggest change writing tests has done for my coding is to give me > >> smaller more descriptive methods rather than large methods that do > >> too much. A method that is more than 10 lines long is probably > >> wrong. A method that is more than 25 is most definitely wrong. > > > > Poll (for everyone, not just Eric): What is good or acceptable method > > size in your opinion? On what factors does your range depend? > > > > Pistos > > i think this is a bit silly really, i have several image processing programs > that are 5000 lines of code. the longest method is around 100 lines and > alreadys calls 20 other methods. breaking it down further would simply > obfusicate the code. the size of methods it going to be related to the > complexity of the task at hand. rather that thinking in arbitrarily limited > terms like '10 lines' or '20' i think it's best to always strive to write less > code and the make is clear first and fast second. most of the time this will > result in relatively short methods since nearly everyone ends up writing ones > that are too long. however it's not always the case and the key here is > 'relatively' - breaking a 10,000 line libraray into 1000 methods just to > acheive some 10 line goal is just going to make your library impossible to use > : at a certain point the pursuit of abstraction in code leads to obfusication, > the artfulness is in finding that line in your application. > > 2 cts. 4 cents now. Kind regards robert PS: Luckily Ruby methods tend to be shorter anyway. -- Have a look: http://www.flickr.com/photos/fussel-foto/