|
|
1
8
我在办公室 例1 营地。根据经验,压痕越少越好。
当您使用if/else并将成功代码和错误代码放在并行部分时,您会使它看起来好像两个代码块相等。在现实中,边缘情况和误差条件应该被忽略。故意提前处理错误 不 把“重要的”代码放在else子句中,我觉得这样可以使重要代码的位置看起来更清晰。 “这些都是先决条件。现在好东西来了。” |
|
2
3
编辑:我越想,函数方法是迄今为止最好的方法,因为它不必编写多次测试条件的逻辑。它还允许更大的可读性,因为很明显您正在“测试”条件(只要您给函数一个有意义的名称)。另外,正如问题edit中指出的,将其他参数传递给函数是很简单的。即
|
|
|
3
2
做 停止一些事情,这样在10年内维护你的代码的人就不会因为修改代码而意外地破坏它。 |
|
|
4
1
|
|
|
5
1
我建议对任何可能有错误的部分使用try子句,并在每次发生错误时使用throw“error description”(如示例1)。
|
|
|
6
1
我更喜欢这种风格,如果条件块中的任何一个被更改了,它们就不会中断,这样它们就不会退出执行。
编辑:错过了PS,所以更新了代码以匹配完整的问题细节。 |
|
|
7
1
我大体上同意 Amber 因为你的第一个选择看起来最清晰。这是我与自己斗争过的一件事——到目前为止,我唯一偶然发现的理由如下:
我提到第二点是因为这是一个棘手的问题。每个脚本可能是一个更大系统的一部分,事实上,您正在注入“纾困”代码的脚本元素可能会被多个地方调用。加上一些OO,你就有了一个真正的潜在泡菜。
随着当今一些更强大的调试和跟踪工具的出现,这越来越成为个人风格的问题,而不是必要性。你可能会考虑的另一个选择是在每个纾困区之前(可能之后)的评论中加入信息,以明确如果满足(或失败)标准,备选方案是什么。 编辑: 我得说 Fraser's answer 是最干净的封装。我要补充的唯一一点是,通过将对象或哈希数组传递到标准的“bail out,I'm dead”方法中,您可能会从中受益,这样您就可以修改提供给函数的信息,而无需一直更改参数列表(非常烦人……)。 也就是说,在生产系统中,您可能需要清理处于中间状态的资源,所以要小心。 |
|
|
8
0
我也更喜欢1。 另外,我非常喜欢在条件语句中指定变量 例如
我通常会发现,在第一次编写代码时,我会得到一些杂乱无章的嵌套条件语句,所以通常是在第二次运行时,我会返回并清理这些内容,尽可能多地取消嵌套条件语句。
|
|
|
9
0
例5
例6
|
|
10
-3
构造条件逻辑的最佳方法是 遵循逻辑本身。
如果你有依赖关系,比如说,第一个条件的失败会使其他的不必要是一回事。那么
如果你要在考试中做决定,说
是的
等。
和
|