良好的编程习惯与临时编程的速度

Question

我知道良好的编程习惯对于项目的“长期运行”总是有帮助，但有时候它们似乎花费了很多时间。例如，它建议我为每个类维护一个头文件和一个cpp文件，只保留头文件中的声明而cpp中的定义。即使是10-12班，这个过程也变得非常繁琐。每次添加一个新类时，更新makefile依赖和evthing ..需要很多时间...

虽然我忙于做所有这些工作，但其他人只会在单个文件中写入ev文件，发出单个编译命令并运行他们的程序......为什么我也不应该这样做？它的速度和它的作品？

即使试图想出变量和函数的短，有意义的名称，需要花费大量的时间，否则你最终键入30个字符长的名字，完全unmanagable没有自动完成

编辑：

好让我说得有点不同：让我说我正在从事一个中小型项目，这是永远不会需要不同开发人员（甚至我）的任何维护。它基本上是一次发展。在这种情况下，编程实践是值得的。我想我的问题是，良好的编程实践在开发过程中确实有帮助，还是在维护期间还清？

Answer 1

从长远来看，特别是在维护时（特别是当维护编码员不是您自己的人时），缺点就在于此。这些技术对于快速验证概念可能是可行的，但如果您不正确重建，将来会导致更多问题。

Answer 2

我从来没有在这个领域工作过很长时间，但没有懈怠和记录，因为我去了，用有用的名字来定义变量等......绝对可以节省时间。当其他开发人员/我自己回到代码进行维护时，它可以节省时间。

不知道这个变量意味着什么，为什么我这样做，等等！ :)

Answer 3

是的，值得这样做的是“正确的”，也就是好，因为基本上它现在是支付我还是以后支付我，并且，你不是唯一一个看过代码的人。 如果现在需要15分钟才能做到“好” - 从现在开始需要6个月（甚至更多）的时间才能确定您的代码的含义！

现在，您可以使用Martin Fowler的3重构思路进行重构。 第一次在代码中修复某些内容时，请注意它可能会被重构，但是你太忙了，就放手吧。第二次回到相同的代码，同样的事情。第三次：重构代码。

Answer 4

编程实践的有效性似乎不是你的问题，在这里。你应该关心的是你用来开发的工具。例如，有很多IDE和其他选项可以让制作文件自动保持最新。

Answer 5

懒惰现在可能还清，但它只会回报一次。花时间做正确的事情不会立即付清，但会多次并且持续更长的时间。

此外，真正的长变量和方法名称没有任何问题，除非您订阅天真的观点，即大部分时间您花费在编程上而不是解决问题。

附录：如果难以简洁地命名，可能需要将其分解为更多模块化单元。难以命名的方法或变量是一种确定的代码味道。

Answer 6

它的所有关于长期支持性。很明显，你要么没有在团队中编写代码，要么不必去查看你多年前写的代码。我可以打开我15年前编写的代码，如果我给出了有意义的变量名称，就可以用非常小的重新学习曲线对其进行修改，而如果我没有编写它，我们需要一些时间才能弄清楚我正在用X和H来做什么，以及为什么T不应该超过4.

尝试与团队中的10人共享代码，并让他们每个人都将代码放在任何他们喜欢的地方......我曾与这样的人合作过。如果私刑仍然得到公众的支持，我会带领很多人。想象一下......我知道我需要修改Foo.SetFoos（int FoosInFooVille）上的签名，但是我查找了Foo.h并没有找到它，现在我只是寻找Foo.cpp对不对？糟糕，为了节省...时间？......他们将Foo.cpp塞进Chew.cpp中......所以我看那里......它不在文件顶部！我是否在该文件中找到Foo，并查看它是否在上面...确定...没有，未找到...在Chew.h中。现在我准备好检查SVN日志，并在他下一次经过时立即瞄准我的USB动力导弹发射器。