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