Coding style in .NET: whether to refactor into new method or not?

As you aware, in .NET code-behind style, we already use a lot of function to accommodate those _Click function, _SelectedIndexChanged function etc etc. In our team there are some developer that make a function in the middle of .NET function, for example:

public void Button_Click(object sender, EventArgs e)
{
    some logic here..
    some logic there..

    DoSomething();
    DoSomethingThere();

    another logic here..

    DoOtherSomething();
} 

private void DoSomething()
{
}

private void DoSomethingThere()
{
}

private void DoOtherSomething()
{
}

public void DropDown_SelectedIndexChanged()
{
}

public void OtherButton_Click()
{
}

and the function listed above is only used once in that function and not used anywhere else in the page, or called from other part of the solution.

They said it make the code more tidier by grouping them and extract them into additional sub-function. I can understand if the sub-function is use over and over again in the code, but if it is only use once, then I think it is not really a good idea to extract them into sub-function, as the code getting bigger and bigger, when you look into the page and trying to understand the logic or to debug by skimming through line by line, it will make you confused by jumping from main function to the sub-function then to main function and to sub-function again.

I know this kind of grouping by method is better when you writing old ASP or ColdFusion style, but I am not sure if this kind of style is better for .NET or not.

Question is: which is better when you developing .NET, is grouping similar logic into a sub-method better (although they only use once), or just put them together inside main function and add //explanation here on the start of the logic is better?

Hope my question is clear enough.

Thanks.

UPDATE: Thanks all for the answer and input so far.

Its just that we have been putting all logic and stuff into 1 function (we only have 2-3 developers before), and suddenly we growing into the team with 7-8 developers, and everyone have their own style.

I thinks its better to start building a guidelines, thats why I feel the need to ask the question.

Ignoring the question of whether or not business logic should be in the code behind (it shouldn't, but that's a topic for another question), I'd say that it's a good idea refactor code down to the most logical level that it makes sense. Leaving it all in one function makes it much harder for anyone to keep the entire function in their head. Breaking it out into sub-methods helps in a number of harder to quantify ways.

I think your real problem here is that you're putting your code in the code behind, and you don't want to muddy up your code behind.. well, then extract that business logic out into business classes.

Yes, you need to define standard coding guidelines, if not as a written set of rules, at least as a consensus of your team. If you get everyone to gether and get them to agree on a style, then you're halfway there. But just realize, the style they choose may not be what YOU want either.

Everyone has their own coding style, and as long as it isn't too terrible then you should just let it be, learn to live with it. There is nothing worse in a team than a code nazi, and there are probably team members who don't like your style.

While you don't personally like it, and it does mean a few more functions in the page, where is the real harm in the approach taken? I personally wouldn't have done it that way, but as long as the code works and it isn't either really fugly or messy then it isn't the end of the world.

Personally, I'd probably go for some sort of Model-View-Controller (or similar) pattern when writing code like this.

However, as another poster mentioned, it is definately a question of personal preference and style.

Breaking your code up into small units of work definately makes your code easier to unit test and debug. Depending on what your "DoSomething" functions do, you may even want to look at abstracting them out into logical layers (often seperated as class libraries in .Net) - for example: Data Access, Application Services, etc, etc

Breaking routines such as these into many smaller methods has at least two benefits.

(1) They can more easily be tested in isolation as discreet capabilities... More importantly

(2) compiler optimizations such as Method Inlining won't work once your methods reach a certain level of complexity and/or size... For that reason alone, I would choose to have many smaller methods.

(3) When you break things down into small chucks you may find you can make some routines static. This means that each class instance will be smaller at runtime and consequently you will spend less time in GC. This means some routines will be more performant as well.

Hmm I don't think it's good to join logic and methods in the GUI code, it can be excuse only on very simple project. Placing logics in the GUI is really not the good practice since you/your colleagues will need to maintain that code some time latter...

I'd suggest you always keep the right structure of your code, so it will be easies for you and others make changes, expand your project and etc, in easy way.

I suggest you create new class'es for logics + methods.

Your Project

• YourGUICode.cs
• Task1Processor.cs
• Task2Processor.cs
• TaskNProcessor.cs

and in your GUI code you can create an object of your task processor, pass parameters to some method and take ten result, display it in your gui.

Its all about read- and maintainability.

The compiler or runtime of the .NET Framework doesn´t care about one long method or multiple small methods to call (Okay there may be some minimal performance diffrences, but thats not the point here).

If you find a good name for the code to refactor out in a sub-method you should go this way and leave out the comment or explanation what the code does. Cause a good method name should indicate what goes on here.

I prefer to refactor long methods into smaller methods only for readability. Even when they are used only once.

Thanks all for the answer and input so far.

Its just that we have been putting all logic and stuff into 1 function (we only have 2-3 developers before), and suddenly we growing into the team with 7-8 developers, and everyone have their own style.

I thinks its better to start building a guidelines, thats why I feel the need to ask the question.

I think introducing functions is better. Really long methods have their own problems in readability and debugging. Esp when nesting goes too deep. Plus when stepping through code, once you are sure a function is correct, you can just step over it, instead of stepping through pperfectly fine lines of code

For the most part this tends to be a question of personal style so there probably isn't a right answer.

That said, there could be a number of reasons to refactor into separate methods. As you've mentioned re-use is probably the most compelling. There's also an argument for breaking large methods into smaller blocks - that a method should do only one thing. See Uncle Bob's theory of Clean Code.

Another reason for breaking up a method into smaller chunks would be for unit testing and/or implementing code contracts.

Read this Class Member Usage Guidelines and if you have a time, have a look on this book:

Programming .NET Components By Juval Lowy Publisher: O'Reilly. There is a whole section that talking about C# Coding Standard with good examples.

There's nothing 'wrong' with this style of coding if the code works, is easy to maintain and can be tested. Separate methods make testing and problem isolation easier.

There's a bigger question about overall design and the other answers mentioning Model-View-Controller etc are worthy of your time.