So, I watched as my colleague complained a bit about a project he has inherited from someone who is, shall we say, not very experienced as a programmer (intern left to his own devices on a project).At one point there was duplicate code, about 7-8 lines of code duplicated (so 14-16 lines total) in a method of say 70-80 lines of code. We were discussing the code, and he spotted a way to refactor this to remove the duplication by simply altering the structure a bit.I said great, and then we should also move the code out to a separate method so the large method gets a little more readable.He said 'no, I would never create a method for just 7-8 lines of code'.Performance issues aside, what are your input on this? Do you lean against using more methods (which in c# pads code with about 3 lines) or larger methods, when that particular code will probably not be used anywhere else? So it is purely a readability issue, not a code-reuse one.Cheers :)
Refactoring into lots of methods - is this considered clean or not?
refactoring;readability;methods
The LoC in a method is a completely pointless measure. The important things are separation of concerns and code duplication. A method should only do one thing, and that one thing should be expressed in its name. Other things should be left to other methods.The problems arising from code duplication cannot be overestimated (in other words, they are always bigger than you think). And that alone will justify even methods with 1 line of code.On the other hand, a method that populates a big form with details from a big data object can easily have 50 or more lines of code, but without a single conditional statement. Why would you want to break that down into smaller pieces if there is no functional requirement (or code duplication)?