几乎在我工作的每个地方,我遇到了很多不关心他们制作了大量样板代码的人.
对我来说,这是有史以来最糟糕的事情之一,它导致错误,它很无聊,它会增加噪音.
最糟糕的例子可能是甚至微软不愿意为这个烦人的"INotifyPropertyChanged"提供更好的语法 - 东西.您不能使用自动生成的属性,您必须创建一个大的冗余(在调用"OnPropertyChanged"或调用任何提升方法时复制属性名称).
有些人甚至认为,许多编程语言中的大多数程序主要包含相同的重复代码(噪声),而不是有趣的东西(信号).请参阅MSDN - 例如,在整个地方有太多不需要的,重复的代码(可怕的"INotifyPropertyChanged" - 破坏所有流程的模式只是冰山一角).
但是,当我提出这个问题并提出像AOP(PostSharp.NET)这样的解决方案或使用委托(对于非C# - 人:匿名函数,通常使用lambda运算符实现)时,我得到的只是"我们不关心".
其他任何人都受到样板代码引入的大量噪音的困扰,并且想要考虑如何将解决方案推向样板 - 问题？
对于它的价值,我完全站在你这一边.
样板人认为重复的冗余代码是"自动的"或"一致的",因此不会导致代码复杂性.通常,当一种语言迫使开发人员创建样板时,业界会创建IDE和其他拐杖来自动化该过程.然后,当生产该样板代码的表观成本接近零时,人们认为它不会花费任何成本.
他们错了:Boilerplate代码有助于代码批量,任何维护代码的人都必须深入研究不相关的代码才能获得重要的部分.此外,由于自动生成的代码可以并且经常进行编辑,因此可以隐藏错别字引起的错误,不完整的重命名或其他事故.样板代码的成本不在其创建中,而在于其维护 - 许多项目试图完全忽略它.
在80年代,我看到交易杂志贴满了C++内存泄漏调试器的广告,这对我来说是一个明显的迹象,即C++中的内存管理严重受损.现在,在Java和C#附近,我看到了大量代码生成助手,这表明这些语言存在其他地方可以更好解决的问题.
Scala有自己的问题,但我喜欢他们对属性和自动初始化构造函数所做的事情.
只是杀了我.不,真的,如果有人编写样板代码并且不关心改进它,我怀疑我们可能称他为专业人士.经常会发生这样的情况:管理层希望快速完成任务,而剩下的就是推出一些只写的样板代码,以使他们满意.如果您的管理层鼓励这样做 - 改变您的工作.