我正在看一个非常大的(5-6位的LOC),非常复杂的代码库,充满交互、庞大、相互依存、视图和存储过程(多个4-5位数的竖井)。
源SQL已被许多不同的人多次访问,并且没有强制执行任何格式约束。这导致了SQL格式的巨大差异,甚至在单个存储过程/视图定义中也是如此。
该代码继续由几组高级程序员(大部分是高级程序员)处理,并看到了持续不断的小变化和改进。
在这些条件下:
什么是明智的标准,以符合格式(例如,我们是否应该使用所有的大写关键字?似乎有这么多程序员不必按一下Shift的小好处实际上等于节省了大量的时间/成本)
是否值得提倡一项重大的重构来标准化格式(例如,培训大量程序员的成本/改变他们的行为/对强制执行新约束的不良意愿,从长远来看是值得的?)
发布于 2013-12-23 17:11:22
为未来的工作商定一个合理的编码标准,并根据需要在重构过程中修复问题SQL。保持原封不动的所有代码工作,否则不需要被触及。
发布于 2013-12-23 18:22:12
在格式化SQL时,什么是明智的标准?
可以用编程形式表示的内容,这样就可以向程序发送文本文件,并知道格式是否“标准”。
理想情况下,您所关心的规则将是您可以自动强加在非标准文件或文本块上的规则,例如“大写所有关键字”或“将每个字段包装在自己的行中”。
是否值得提倡一种主要的重构来标准化格式化?
不是的。如果代码没有被破坏,并且没有对最终结果进行改进,那么您就不想碰它并冒着破坏它的风险。
顺便说一下,代码标准的好处不是提高编写时间的效率。相反,一个好的格式化标准将减少程序员查看他们已经有一段时间没有接触过的代码所需的时间,并且查看正在发生的事情。
https://softwareengineering.stackexchange.com/questions/222208
复制相似问题