At 02:20 PM 8/5/2008 -0500, Whil Hentzen wrote: >So I'm working on this gig with a customer. The customer's rep is one of ... >One of their pet peeves regards method length. Somewhere they read in a >book that methods shouldn't be longer than 20 characters. I've got this ... >About 150 lines, maybe. Pretty straightforward. My associate wants me to >break this down into tiny methods, so the main method looks like so: ...
Over the years, I've worked with a lot of code written by others and, of course, a lot of code I've written myself. Early on I was a pretty staunch adherent to the "max LOC" per method/function concept. In my case, the target limit was 100. But what I've found out is - "Cohesion should trump size." In other words, if a certain set of logic it highly cohesive, it is much better to keep it together in a single routine for maintenance purposes. Of course, if you're not worried about maintenance effort.... (don't laugh, I've seen some developers that flat out said they didn't care). I think my largest routine that I've got in production right now is around 500 lines. Another thing I've found is that the code that is the absolutely most difficult to debug/maintain is the code that breaks a set of cohesive logic across several methods/routines (my own code included in that analysis... heh). Code that is very low in cohesion, but crammed into a single huge routine actually isn't that difficult to maintain, but, as someone already pointed out, it limited it's reusability. The real key is figuring out how cohesive the code actually is. There may be books out there that talk about it, but what I've seen is; a) code tends to be cohesive if the logic dictates a general sequence of events where function/logic of later code needs to know, or is dependent on, earlier code, b) code that is "general purpose", such as utility functions, functions that perform various operations on database tables (mostly independent of table structure/content) are often not cohesive. A business rule that has a lot of calculations in it, progressing in sequence, etc could be highly cohesive. But then a "summary report update" function, that is supposed to populate a summary table based on several calculations using different tables probably is not highly cohesive (e.g. populating 1 column in the summary table is not "dependent" on populating others, etc.) I think the rule of 20 lines (I presume you meant lines instead of characters..... I don't think I have any routine less that 20 characters), is much too small. Sure some routines will easily fit into that, but when you have a restriction that low it will end up causing a lot of unnecessary "mental effort" to keep worrying about it. And when you go back to review it, you'll probably be spending a lot of time flipping between pages/windows trying to follow the flow. I think 100 is reasonable, and perhaps 50 would be OK. Also note that the language used has a fairly direct impact on what could be considered reasonable. For example, what might take 100 lines in C# may take 40 in VFP. So that's something to think about too. But as you say, the guy may be locked in (a lot like I was) to his number. You can't do much in that case other than try to keep the most cohesive code together where possible. -Charlie _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/[EMAIL PROTECTED] ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
