winforms .Net Regarding use of small methods
I work on developing application using winforms in C#. While developing, I want to use many small methods e.g. resetPerticularCombo(), so the code remains as clean as possible. But the problem is making methods for 3-5 lines of code could lead to too many method calls, I have heard that while compiling Visual Studio 2008 takes care of this thing using code inlining.
My query is that, should I rely on this feature and go ahead with the usage of small helper methods or I should use inlining myself?
You shouldn't worry about having large number of method calls until you've proved that it's a problem. It's very unlikely (IMO) that this will actually cause an issue, and if it gives you more readable code, that's the most important thing.
But test the performance all the time to see whether it's acceptable. Find out where the bottleneck in your code is, whether by profiling or other techniques, and consider micro-optimizing just at the points where it'll make the most difference.
In my experience micro-optimizing at the "use fewer methods" sort of level is almost always pointless compared with higher level changes (e.g. going from a list lookup to a dictionary lookup, etc).
I agree to Jon Skeet.
Concerning Enterprise Applications I can tell you the following
I'm leading a small developer team ( 5 Developers) . We 've an application with about 500k loc.
We always try to find the most particular concern a method should have. So we got a lot of small, and "selfexplaining" methods. As a result we have a many many methods and this never lead to an issue.
Most of the time the bottlenecks are in accessing ressources like SQL Server, Files, etc... Or a lack of asynchronity.
Also i've you have a perfomance you could profile it using ants profilder.
I also like these "rules" of optimization I found sometime ago on the web
FirstRuleOfOptimization - Don't.
SecondRuleOfOptimization - Don't... yet. P
ThirdRuleOfOptimization - ProfileBeforeOptimizing
If your developing a timecritical software (Graphic or driver related) then this things can make the point, but then I wouldn't be sure if .net were the best environment to do that
Lots of small routines is fine, as other answers already say, but remember to consider refactoring similar routines, for readability and maintenance (and not specifically for performance).
resetPerticularCombo() and resetAnotherCombo() may be worth converting to resetCombo(PerticularCombo) and resetCombo(AnotherCombo), if the routines are otherwise the same.
With anonymous lambdas, this can even be used to consolidate other similar algorithms: (potentailly bad example, but to continue using the OP's code) ProcessCombo(PerticularCombo, (c)=>c.Reset()) and ProcessCombo(PerticularCombo, (c)=>c.SelectFirst())
I'm a VB.NET programmer and this code has been entered directly into SO without any syntax checking.