我的代码是这样的
string statuscodeToSet;
if (xElementAltItem != null && (generalstatuscode.Contains(currentstatuscode) && xElementAltItem.Value.Trim() =="null"))
{
statuscodeToSet = "1";
}
if (xElementupdateDate != null && (xElementAltItem != null && (generalstatuscode.Contains(currentstatuscode) && xElementAltItem.Value.Trim() == "null") && xElementupdateDate.Value == "01-JAN-2099"))
{
statuscodeToSet = "2";
}
if (xElementupdateDate != null && (xElementAltItem != null && (generalstatuscode.Contains(currentstatuscode) && xElementAltItem.Value.Trim() == "null") && xElementupdateDate.Value != "01-JAN-2099"))
{
statuscodeToSet = "3";
}
if (xElementAltItem != null && (generalstatuscode.Contains(currentstatuscode) && xElementAltItem.Value.Trim() != "null"))
{
statuscodeToSet = "4";
}
if (xElementAltItem != null && (currentstatuscode == "Act-NotOrd" && xElementAltItem.Value.Trim() == "null"))
{
statuscodeToSet = "5";
}
显然我不认为这是最好的编码方式。有没有什么方法可以缩短这段代码,让它看起来更标准。可能会使用Linq
4条答案
按热度按时间jgovgodb1#
这似乎是最简单的可能,但我不认为这是简单的。
您确实需要通过创建一些有意义的变量名来梳理这里的逻辑,使条件读起来像英语,否则您的代码很容易出现错误。
hmae6n7t2#
更新:我似乎已经引入了一个差异wrt在处理更新日期的原始,因为它似乎我折叠成两个三个国家(哎呀!)这出现在步骤#2/#3.在任何情况下,我相信下面仍然是一个适用的模板遵循.
第一步:消除重复的变量条件检查。
这极大地简化了条件句,并使其更容易看到“应该”发生的事情。
第二步:将单独的条件分组,并使用“嵌套”和“else”条件重写代码。
这将消除大部分(如果不是全部)重复检查,并提供贯穿整个条件结构的“一条路径”。分组的顺序取决于每个条件的逻辑重要性以及它消除分支之间重复的程度。在这种情况下,代码按
nullAt
分组,然后按hasCurrentState
分组。第三步:将代码放入一个单独的函数中并返回结果。
也就是说,不要将“状态”分配给变量。除了保持整洁的代码分离和自文档化之外,这很有用,因为这样可以更容易地发现无效的代码路径/逻辑。
例如,
return "1"
在它所处的位置没有意义(因为这样就不能到达状态“2”或“3”,如果它被删除,那么状态“1”就永远不会返回!),并且有一些“否则”的情况没有得到处理。在最后一个阶段,中间变量的使用可以恢复,而不会损失太多的可读性,因为重复的表达式已经被消除了。然而,除了严格要求延迟计算的情况外,单独的变量是完全有效的-如果它们使代码更干净,请使用它们。
使用枚举或常量也是一种改进:
NeedsUpdate
的状态值比"3"
提供更多信息。我建议保持简单,并遵循上面概述的方法。
YMMV。
pkln4tw63#
试试这个:
tyu7yeag4#
@Samiey Mehdi走在正确的道路上。
但这与if语句无关,它是关于构建规则引擎,或者将您的代码置于构建规则引擎的位置
反转Samiey代码:
现在每一个“返回”都是一个规则。
我们可以把每个都放在它自己的接口/类中。
将这些接口/类放入工厂
调用工厂获取规则列表
循环遍历列表以执行规则
该枚举可以是foreach或Parellel。foreach
通过我们的代码