代码之家 › 专栏 › 技术社区 › cwallenpoole

何时更改代码以匹配标准是最好的?

puremvc coding-style standards

cwallenpoole · 技术社区 · 16 年前

我最近负责调试两个不同的程序,这些程序最终至少需要共享一个XML解析脚本。一个是用pureMVC编写的,另一个是从头构建的。虽然它最初让人觉得是从头开始写的(它节省了大量的内存,但是内存问题已经解决了)。

移植非pureMVC应用程序需要花费大量的时间和精力,而这些时间和精力不需要使用,但是它将使文档和代码共享变得更容易。它还将降低整体学习曲线。考虑到这一点:

1。在考虑是否最好将事物移动到一个标准时,应该考虑什么?

有些代码有点奇怪。因为解释应用程序必须将命令从一种语法转换为另一种语法,所以有一个解释程序对象是有意义的。因为需要与外部环境进行通信,所以让一个对象与环境进行交互更为合理,并且处理解释器。 唯一地 .

实际上,一个反单体被创造出来。对象将只与解释器接口,就是这样。如果另一个类的成员试图调用其公共方法之一,则该对象将引发异常。

有更好的方法可以做到这一点,但这确实有点奇怪。有更多的标准方法来完成相同的事情,尽管它们通常涉及到创建非常大的类或类文件。我能找到的唯一符合标准的解决方案,如果不是更多的话,将包括与当前所需的一样多的评论和解释。考虑到这一点:

4 回复 | 直到 15 年前

Galwegian 16 年前

在我看来,这种类型的重构通常不在时间表中考虑,只有在有额外的时间时才能进行。

通常情况下,运输代码的标准是它是否有效, 如果这是最好的代码解决方案,就不一定了 .

所以在回答你的问题时, 我会在有时间的时候尝试重构 . 第一要务仍然是生成一段功能性代码。

Sarah Mei 15 年前

需要考虑的事项:

正如Galwegian所指出的,这是许多商店的唯一标准。然而,IMO同样重要的是:

如果您要维护它,那么考虑:

这很难猜测,但是考虑到许多代码基远远超过了它们最初作者所设想的有用性。(Y2K有人吗?)我逐渐形成了这样一种感觉:什么时候重构是值得的,什么时候重构是不值得的,主要是因为太频繁地犯了“不”的错误,后来又后悔了。

thursdaysgeek 16 年前

只有在需要进行更改时才进行更改。但少一些怪癖总是一个好目标。在一个特定的软件上花费的大部分时间都是在维护上,所以如果你能做些事情使之更简单,你将减少花在这段代码上的总时间。尽管如此,如果它工作并且不需要任何修改,就不要改变它。

15 年前

如果你有时间,现在。如果你没有时间,以后可以避免。