这是在编码风格跨语言问题。
我有很多的代码，有很长的代码块，有时数百行，里面if语句或for循环工作。 该代码是程序。
如下代码
if(condition){
//hundreds of lines of code
}else if{
//hundreds of lines of code
} else {
//hundreds of lines of code
}
我有麻烦浏览这个代码，如果我没有在一段时间看到它，因为我经常要来回滚动来检查我，我的还是我的发言的分支在一个循环中，或者是什么将循环迭代叫做。
我的预感是把代码排长片内功能，从报表或环内对分支机构中调用它们，所以循环，如果树是更短，因此更具有可读性。 我想创建是明智的代码仓库功能ofcourse，不只是削减了当前的代码随意。
但是，这是我的问题：是一个好主意？ 或者是不是一个坏的编码风格有几百行代码的if语句或for循环里面？ 我不是一个真正有经验的程序员，但我也明白干净的代码:)
谢谢！
补充：几百行代码都没有重复的，大部分时间。 我理解并尽量坚持，当然DRY原则。
它通常是一个好主意，可以一个屏幕上看到整个的方法。 如果你有太多的向上和向下滚动（有人会说的话），然后运行丢失信息的风险。
所以一般你会建议是一个好主意。 虽然你不必尽可能把所有的代码在一个分支成一个方法去。 有可能是重复的代码段所以你也可以打破它：
if(condition){
CommonMethod();
SpecificMethodA();
}else if{
CommonMethod();
SpecificMethodB();
} else {
CommonMethod();
SpecificMethodC();
}
举个例子。 虽然重构的确切性质将完全取决于你的代码。
从你说的话，我会重构这些块成独立程序的内容（给他们有用的名称和传递参数的要求）。
if(condition){
DoA();
}else if{
DoB();
} else {
DoC();
}
procedure DoA() {
//hundreds of lines of code
}
procedure DoB() {
//hundreds of lines of code
}
procedure DoC() {
//hundreds of lines of code
}
当然，这可能是有用的做到这一点的DOX-程序内为好。
这是可怕的编码风格有数百行的单一功能。 有小功能，希望这适合在一个单一的屏幕，并且服务于一个目的，让你的代码结束寻找像
if (condition) {
func1(); //One purpose
func2(); //Another purpose
func3();
} else if (another condition) {
func4();
} else {
func5();
func6();
func3(); //wow I can reuse some code!
}
不要去简单的路线上把整个数以百计的各种情况下的线的单一功能无论是。 尝试采用隔离的目的（此功能创建一个临时文件，例如）和功能分配给他们。 你可能会惊讶地看到你的总行数下去，因为在那些数百行极有可能重复的功能。
必须考虑到这一点：你 - 或任何其他人阅读代码 - 应阅读时轻松地了解每个功能。 如果函数包含几百行代码的它永远不会是容易理解的。 如果你发现自己阅读理解代码做什么它需要重构时做笔记。
你展示的例子绝对是需要重构的那种是。 如果 - 子句中的每块应该理想地调用只有一个功能。
if (condition)
{
doSomething();
}
else if (anotherCondition)
{
doThisOtherThing();
}
else
{
doThisThirdThing();
}
你看到的代码是如何容易理解的？ 实在没有什么了解那里 - 除了parhaps的条件，但如果这是复杂的，应该作为一个独立的功能也被分解。
现在，doSomething的（），doThisOtherThing（）和doThisThirdThing（）函数不应该的代码hundres线平原块。 无功能应该永远是那么长。 它总是很难理解那么久的功能。 试着找到你的函数可以被分解为单独的功能，这样做的逻辑部分。 如果有应该在所有的通用功能，应创建并从所有的DOX-函数调用的情况下完成的公共部分。
注意：您不需要代码重用创建函数。 你可以将在一个新的功能的东西只是为了让代码更易读。
祝你好运重构！ :-)
在addtion其他答案：如果你想知道更多关于这一点，尝试通过罗伯特C.马丁读“清洁守则”。
在我作为很长一段时间编码器和代码审核人员，回答（像往常一样）意见的时候。 这里有原因，我将代码分成不同的功能：
但也有原因，以使代码在最初的功能：
这不是一个良好的编码风格。
将代码分成更小的程序，使得它更具可读性和maintanable。
话说回来。 不要马上去，并开始削减这些成更小的程序。
只有改变你在阅读什么regularily，或者您需要更新。
请记住，每次你改变你需要测试你的改变代码的时间，所以不要无谓地改变，因为你改变代码的每一次，还有就是引入新的错误的可能性。
有一次，我在那里有20行，每功能代码的官方限制的一个项目工作。 这是地狱！
我可能会被口罩工作，或退出GUI元素的运动数据，然后我会被迫写
transferFirst10Elements()
transferElements11Thru20()
transferElements21Thru30()
transferElements31Thru40()
并抨击了我们作为过头教条的例子政策。
只是为了澄清，我认为首要的功能确实应该被打破了，但我不与其他一些应答者认为击穿应该继续下去，直到有没有更多的碎片超过一屏更大的认同。 有那么一刻，微小的职能管理不计其数要比管理稍少较大的更痛苦。
您所遇到的，只要你重温代码问题的事实是清楚的足够的迹象表明，有一个问题。
相反，大多数这里的其他建议，我会采取略有不同的方法。
试图遵循一些有关的位置和程度拆分可能工作的建议的规则，但它也可能导致情况下故障本身是无法控制的。 相反，向上和向下滚动再次熟悉的，你只是被导航到一堆遍布源文件小例程。
代替...
我建议你尝试专注于分裂你的代码的一些方法，每个方法执行一个任务，显然是由该法的名称表示。 像这样的代码块通常都很大，因为他们在做多件事情。 通过这种方式分裂他们，你会发现，你的代码会自然演变成一个更易于管理的风格，之前提到的问题的风险较小。
这也可能有助于在其他方向工作。 把你的更大的代码块中的一个，尝试（而忽略了实际的代码）定义了它的作用在一些简单的步骤，然后相应地编写它。 请记住，它必须做的一件事; 但可能需要多个步骤来完成这项工作。 这将提供大量的代码块的自然分解。
注：我永远不会主张对执行单一任务套路气势线限制; 例如一个程序来“填充编辑控件”可能有很多行，因为控制数的多少，但失误有些人提出的是，除了填充控制做“简单的计算”。
这种方法的另一个好处是，你更可能有能 ，因为他们没有“超重行李” 被重用例程。
过程/函数用于替代但却难免重复的代码，在这里你只需要微小的细节/值改变。 这减少了冗余和代码的maintinance。 但是，是的，你也可以用它（与meaningfull名称），以减少这么大的代码块。
你真的应该考虑这样一个块分解成类。 OOP为您提供所需的所有技术。 模板方法图案例如解决了与特定条件的动作之间的CommonAction存在的问题。 这是OOP只是冰山的一角。
我第二次模板/模式建议由archimed（对不起，我投你了，但我的代表处是不高但很明显）。 我在想一个策略模式我自己，但是模板会摸出一样好。
实际上，我真的很惊讶，它得到了否决。 做完这两种方法（通过代码移入方法与实施模式），我已经找到了工作的量，实现对这些代码块的模式实在是没有太大的不同。 而作为ya23说，已实施该模式的长远利益是相当可观的。
您提取“如果”块内的长码片段的想法是正确的轨道上; 不过，我会开始比小得多。 寻找重复的代码较小位 - 我想说3-10线 - 那做什么事情都很理解，并提取到一个方法（这应该是很容易的名字）。 如果可能的话，执行使用自动重构工具（以避免发生错误），并添加单元测试针对所提取的方法提取。 现在，这种重复几次，你应该看到的模式和结构开始出现。 你可能会看到类似前面的回答的结构结束：
if (condition) {
func1();
func2();
func3();
} else if (another condition) {
func4();
} else {
func5();
func6();
func3();
}
