我是一名相当新的 Scala 开发人员。我是一名经验丰富的 Java 开发人员，到目前为止，我一直很喜欢 Scala 的简单性。我真的很喜欢函数式结构，而且它们常常迫使你编写更简洁的代码。然而最近我注意到，由于舒适性和简单性，我最终使用了在 Java 中不一定使用的结构，并且实际上被认为是一种不好的做法，例如
private def convertStringToSourceIds(value: String) : Seq[Integer] = {
Try(value.split(",").toSeq.map(convertToSourceId(_))).getOrElse(Seq())
}
相同的代码片段可以写成
private def convertStringToSourceIds(value: String) : Seq[Integer] = {
if(value!=null) value.split(",").toSeq.map(convertToSourceId(_)) else Seq()
}
我的一部分意识到Try/getOrElse块的设计是Options记住，但通常它会使代码更具可读性并处理您可能错过的情况（当然这并不总是一件好事）。
我很想知道经验丰富的 Scala 开发人员对此事有何看法。
我并没有声称任何“经验”头衔，但出于几个原因我更喜欢你的第二个构造
抛出异常（在本例中为 NPE）的成本很高，最好避免；它应该保持不变，例外al
if是 Scala 中的表达式，它避免声明“悬空”变量来保存测试结果（就像三元运算符一样）。或者，match..case构造提供了非常可读的代码。
我个人会返回一个Option[Seq[Integer]]来“传回”信息values was null并促进您的功能的进一步链接。
就像是
private def convertStringToSourceIds(value: String) : Option[Seq[Integer]] = value match {
case null => None
case _ => Some(value.split(",").map(convertToSourceId(_)))
}
注意1：不确定你需要toSeq
注2：无论好坏，看起来都有点哈斯克尔式的
Scala + FP 的结合几乎加倍肯定你会得到不同的意见:)
Edit请阅读下面的评论以了解其他原因和替代方案，即
def convertStringToSourceIds(value: String): Option[Array[String]] = Option(value).map(_.split(",").map(convertToSourceId(_)))
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
