C中的设计原理DRY?

时间:2018-04-27 08:22:01

标签: c performance design-patterns

我对更大编码视角的问题,但我试图用简单的例子来理解。可以说我有几行代码

int main(void) {
    int input_1 = 10;
    int input_2 = 10;
    /* some stuff */
    return 0;
}

在阅读了设计原则之后(我不确定它是否常见于编程语言,我希望它是通用的)我开始知道上面的代码是有效的C代码,但是它的脏代码< / strong>因为在这里我没有关注 DRY (不要重复自己)原则,因为幻数10正在重复。

首先我怀疑的是, C 标准是否对编码的最佳实践说了同样的内容,我读了规格,但我没有完全准确?

我修改如下以避免使用短语Dirty Code

int main(void) { /* I'm not 100 percent sure that this is not dirty code ? */
    const int value = 10; /*assigning 10 to const variable*/
    int input_1 = value; 
    int input_2 = value;  
    /* some stuff */
    return 0;
}

修改版本是正确的还是我可以做得更好?最后,如果最好地建议这些设计原则,那么为什么编译器不会产生任何警告。

2 个答案:

答案 0 :(得分:5)

这更多是关于避免幻数。如果您声称“相同的10 ”,则10应具有某种语义含义。那你应该做点什么

#define FROBNUM 10 // use a name here that explains the meaning of the number

int main(void) {
    int input_1 = FROBNUM; 
    int input_2 = FROBNUM;  
    /* some stuff */
    return 0;
}

引入const是不必要的,宏可以很好地解决这个问题。这里解决了DRY,宏定义是具体值的唯一来源。

另一方面,如果两个10值之间存在无语义关系,则会#define两个宏。如果它们确实具有不同的含义,那么这不是“重复自己”。不要在这里误解DRY。

关于const版本的附注:它有两个缺陷

  • 名称value根本不是语义,所以没有任何收获,数字仍然是 magic
  • 使用此声明,您将引入一个自动存储持续时间和类型int的新对象,您并不真正需要它。一个好的编译器会优化它,但最好不要依赖它 - 这就是为什么宏在这里更适合。

答案 1 :(得分:3)

DRY主要指的是一个单一的事实来源。某些业务规则或可重复使用的代码模式应该只表达一次,特别是如果将来可以更改它们。示例包括计算运费或税率的代码,您想要编码一次并改变如果他们改变,确切地在一个地方;或数据库适配器的实例化,当数据库详细信息发生更改时,您可以在一个位置进行更改。

DRY并不意味着您必须将看起来与另一行代码类似的每行代码减少到一行。