几乎在我工作的每一个地方，我都会遇到很多人，他们不在乎他们产生了大量的样板代码。

对我来说，这是有史以来最糟糕的事情之一，它会导致错误，它很无聊，而且会增加噪音。

最糟糕的例子可能是微软不愿意为这个恼人的"inotifypropertieschanged"东西提供更好的语法。您不能使用自动生成的属性，您必须创建一个大的冗余(复制对"onPropertyChanged"的调用中的属性名，或任何调用您的Raiser方法的对象)。

有些人甚至认为许多编程语言中的大多数程序都是由相同的重复代码(噪声)组成的，而不是有趣的东西(信号)。参见msdn-例如，这里有很多不必要的、重复的代码(可怕的"inotifypropertychanged"模式，它破坏了所有的流程，只不过是冰山一角)。

然而，当我提出这个问题并提出诸如AOP(postsharp.net)或使用委托(对于非C类：匿名函数，通常使用lambda运算符实现)之类的解决方案时，我得到的只是"我们不在乎"。

这里还有谁为样板文件代码引入的疯狂噪音而烦恼，谁想考虑如何将解决方案推送到样板文件中去？

不管怎样，我完全站在你这边。

样板用户认为重复的、冗余的代码是"自动的"或"一致的"，因此不会增加代码的复杂性。通常，当一种语言强制开发人员创建样板文件时，行业会创建IDES和其他拐杖来自动化流程。然后，当生成样板代码的明显成本接近零时，人们认为它不需要任何成本。

他们错了：样板代码导致了代码量的增加，任何维护代码的人都必须挖掘出不相关的代码来获取重要的部分。此外，由于自动生成的代码可以而且经常被编辑，所以它可以隐藏由打字错误、不完整的重命名或其他事故引起的错误。样板代码的成本不是在其创建过程中，而是在其维护过程中——许多项目试图完全忽略这一点。

在80年代，我看到贸易MAG贴满了用于C++内存泄漏调试器的广告，对我来说，C++中的内存管理被严重破坏是一个明显的迹象。现在，在Java和C语言的附近，我看到代码生成辅助的扩散，并且告诉我这些语言有更好的解决方案。

scala本身也有一些问题，但我喜欢它们对属性和自动初始化构造函数所做的工作。

杀了他们就行了。不，真的，如果有人写样板代码而不想改进它，我怀疑我们会称他为专业人员。通常情况下，管理层希望看到任务快速完成，唯一剩下的就是推出一些只写样板代码，以使它们满意。如果你的管理层鼓励这样的方法-改变你的工作。