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

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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