我正在从事一个非个人项目，所以可以肯定地说维护程序员不会是我，否则我不需要问这个问题。
现在我想在我的代码中尝试一些构造（委托、lambda 表达式），不是故意使代码更难阅读，而是因为它们适合这种情况（并且需要输入的代码也更少)，并练习使用它们，因为我是该语言的新手。
但是，我不确定维护程序员是否会了解每个构造，因为我们中的许多人都没有 c# 背景，而且我不确定他是否像我一样热衷于编程，或者只是对待它就像一个普通的日常工作。所以我的问题是：
是否应该避免某些编程结构以提高可维护性？
如果上述问题的答案是肯定的，那么应该避免使用的构造子集是什么？
维护程序员有责任全面学习一门语言吗？
【问题讨论】：
标签： c# maintenance language-construct
我反对最小公分母编码。我们是专业人士，我们应该做的一部分是学习我们不知道的东西。
另一方面，我也反对荣耀编码。使用可以完成工作的最简单的结构 - 调试代码的难度是编写代码的两倍，因此您最好只编写代码的一半聪明！
【讨论】：
我认为一般的经验法则是确保您的代码在许多 cmets 下都是可读的，尤其是在您正在做任何不直接的事情的地方。
不应该避免某些结构，如委托和 lambda 表达式，如果使用得当且合理，这样的语言特性可以大大降低代码的复杂性，并使它们更加简洁和富有表现力。毕竟，这就是 LINQ 的美妙之处，不是吗？ ;-)
我认为，无论其他程序员是否具备理解您的代码所需的所有知识，这都是您无法控制的，我认为您应该专注于尽您所能完成您的那部分工作。如果那个维护程序员离开了，其他人进来了，那会怎样？您不应该修改代码以适合维护程序员，而是修改代码以适合您要解决的问题。
【讨论】：
我相信尤其是 lambda 表达式可以使代码更易于阅读（如果有的话）。无需使用多个带有大量条件的 for-each，而是几乎可以读取干净的 lambda。
根据我的经验，使代码难以阅读的原因是聪明的泛型 Func 参数...这些通常只取出 tw0+ 易于阅读的函数，并将其替换为通用的难以阅读的函数。
因此，在我的书中，拥有好名字的方法比避免某些结构更重要。但是不要担心他们不知道它们——无论如何他们都应该学习它们。
【讨论】：
我认为，即使您正在编写自己的项目，也值得尽可能坚持使用您使用的任何语言的常见/标准习语。
我自己也陷入了这个陷阱 - 编写了一些“聪明”的代码，没有充分记录它，几个月后我回来更改代码时引入了一个严重的错误。
我的经验法则 - 尽可能多地使用“核心语言”，当您与此不同时，请彻底记录您的方法。避免利用语法糖来缩短代码，除非它是一个真正的标准习语（例如 C# 中的属性）。可读性每次都应该胜过打字速度。
如果您希望维护编码员接管您的工作，那么这一切都是正确的。您不能指望维护编码人员精通大多数组织中的多种范例。因此，如果你例如开始在面向对象的代码中使用像 lambdas 这样的逻辑/函数式编程结构，这有点像在英文书中用德语写一章。您可能希望您的读者是多语言爱好者，但很可能他们不是。
【讨论】：