.NET中的编码风格:是否重构为新方法？

Question

如您所知,在.NET代码隐藏风格中,我们已经使用了很多函数来容纳那些_Click函数,_SelectedIndexChanged函数等等.在我们的团队中有一些开发人员在.NET函数中创建函数,例:

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()
{
}

并且上面列出的函数仅在该函数中使用一次,并且不在页面中的任何其他位置使用,或者从解决方案的其他部分调用.

他们表示,通过对代码进行分组并将其提取到其他子功能中,可以使代码更加整洁.我可以理解子函数是否在代码中反复使用,但如果它只使用一次,那么我认为将它们提取到子函数中并不是一个好主意,因为代码越来越大更大,当你查看页面并尝试理解逻辑或通过逐行浏览来调试时,它会让你感到困惑,从主函数跳转到子函数再到主函数再到子函数.

我知道当你编写旧的ASP或ColdFusion风格时,这种分组方法会更好,但我不确定这种风格是否适合.NET.

问题是:在开发.NET时哪个更好,将类似的逻辑分组为更好的子方法(尽管它们只使用一次),或者只是将它们放在main函数中并在逻辑开头添加//解释更好？

希望我的问题很清楚.

谢谢.

更新:感谢大家到目前为止的答案和输入.

它只是我们已经把所有的逻辑和东西都放到了一个函数中(之前我们只有2-3个开发人员),突然间我们成长为拥有7-8个开发人员的团队,每个人都有自己的风格.

我认为最好开始制定指南,这就是为什么我觉得有必要提出这个问题.

Answer 1

忽略业务逻辑是否应该位于代码后面的问题（它不应该，但这是另一个问题的主题），我想说，将代码重构到最逻辑的级别是一个好主意感觉。将所有功能都放在一个功能中会使任何人都更难将整个功能牢记在心。将其分解为子方法有助于以许多难以量化的方式进行。

我认为你真正的问题是你将代码放在后面的代码中，并且你不想让后面的代码变得混乱......好吧，然后将该业务逻辑提取到业务类中。

是的，您需要定义标准编码指南，即使不是作为一套书面规则，至少也作为您团队的共识。如果你让每个人聚集在一起并让他们就一种风格达成一致，那么你就成功了一半。但要意识到，他们选择的风格可能也不是您想要的。