编码标准 [英] Coding standards

问题描述

在没有任何编码标准的情况下经过多年的运营，我最近开始工作的

公司已经决定拥有一些可能是个好主意。我参与了这项计划。


通常我发现编码标准是由

公司的某个人编写的，他有一种编码方式他喜欢然后试图强迫其他人以他喜欢的方式编写代码，而不是因为任何理性的原因，而只是因为他喜欢它的主观方式。我认为这是错误的

。

当涉及到代码布局风格问题时，这是特别令人讨厌的问题

与这个问题几乎没有关系执行代码或

可读性和维护代码。


我也认为编码标准试图阻止白痴从

做蠢事。无论一些标准有多么严格，有人

愚蠢的人会找到一种方法来为代码做一些愚蠢的事情。我的观点

不是让标准对于良好的编码人员更具限制性，而是应该加快编写好代码的速度，而不是

符合标准。例如，看似普遍的

态度完全括号

语法是要走的路（这将阻止白痴）。我非常不同意。

有很多时候，在没有必要的情况下省略括号

以获得更易读的代码。它还减少了支架的维护;支撑越少，支撑越大越容易。问题是，我认为大多数程序员都懒得知道他们何时需要确切地知道他们什么时候需要支持。如果你不知道，只要把它们粘在各处

，它就不会受到伤害。很多很多大括号意味着需要很多很多代码才能保证不需要在那里。


我最近读了一个禁止的标准使用三元（条件

？）运算符。我发现大多数C程序员都没有费心去学习

如何使用它而不想让别人使用它，因为那时他们将不得不

搞清楚。但是我也发现在大多数情况下使用的是b $ b，它可以使代码更加清晰，即使对那些不习惯使用它的人来说也是如此。 />

a =（b == c）？ d：e;


如果（b == c）{
$ b，那么就像


一样可理解且更易于维护$ ba = d;

}

else {

a = e;

}


在第一种情况下，在一行中很明显，您只是根据条件为a分配一个

值。 if语句的使用会导致更多的代码在维护时出错。


我遇到的另一个问题是出于功能的方式

问题。我认为，如果有条件需要从某个函数提前退出

，那么应该提前退出。例如：


int funct（int arg）

{


.....

if（条件）返回ERROR;


....


返回OK;


比

更优惠
int funct（int arg）

{

int retval =错误;

.....


if（！condition）{

retval = OK;

（其余功能）;

....

} / * if of if（！condition）* /


返回retval;


在第一种情况下，你已经非常清楚将会返回什么价值

返回，你'减少了所涉及的牙套数量，并且减少了功能主要部分的缩进水平。反对这个论点

可能需要在

函数中进行一些清理，这种风格可能导致一个白痴退出该函数而没有

正在进行清理。我的反驳是第一，只有少数

函数要求在退出

函数之前完成清理。第二，清理应该是一个单独的功能，

可以从父功能的任何地方调用，而你只需要三号

不能指望无论如何要保护代码免受白痴影响的标准，为什么

假装它呢？


类似的问题就是这个：


如果（条件）{

retval = func（arg）;

}


如果条件必须在每个函数之前进行测试然后条件

应该由函数评估：


retval = func（arg，condition）;


....

int func（int arg，BOOLEAN条件）

{


if （！条件）返回OK;


....

}

总的来说，我认为更少的代码更多可维护而不是很多代码。

任何地方我都可以减少代码行，这样可以更容易地维护
。例如：


if（条件）

{

retval = func（a，b）;

}

其他

{

retval = func（a，c）;

}


if（retval！= OK）

{

error_exit_func（）;

}


a更好的方式是


if（！func（a，condition？b：c）error_exit_func（）;

有没有人会在这些问题上与我达成一致意见，还是我这个编码的唯一声音是什么？

解决方案

Natt Serrasalmus写道：

经过多年的运作，没有任何编码标准，我最近开始工作的
公司已经决定了我可能有一个好主意。我参与了这项计划。

通常我发现编码标准是由
公司的一些人编写的。一种他喜欢的编码方式d然后试图强迫其他人以他喜欢的方式编写代码，不是为了任何理性的原因，而只是为了他喜欢的主观方式。我认为这是错误的。


嗯，从你的帖子的其余部分可以得到印象

，你只是一个更加自我意识的这个家伙的味道。

您的示例显示的偏好可能比其他编码标准更具限制性

。


这在特别令人厌烦的时候它涉及到代码布局风格的问题，它与代码的执行或代码的可读性和维护几乎没有关系。


这是正确的。迟早会有人成为编码警察

对正确使用缩进，白色空间，

评论样式等感兴趣。

但是，由于人们不关心详细信息，在组中编码可疑的乐趣，我认为编码

规则可以潦草地编写在一张纸上是

最佳方式。如果你使用cvs，甚至缩进之类的东西都可以足够重要，可以放在上面的表格上。


我也认为编码标准是错误的试图阻止白痴做蠢事。无论一些标准有多么严格，有人愚蠢的是要找到一种方法来为代码做一些愚蠢的事情。我的观点是，不是让标准对于优秀的编码人员更具限制性，而是应该加快编写好的编码，以便能够编写出良好的代码，而不是按标准编写。 。例如，看似普遍的态度，完全括号
语法是要走的路（这将阻止白痴）。我非常不同意。
很多时候，在没有必要的情况下省略括号以获得更易读的代码。它还减少了支架的维护;支撑越少，支撑越大越容易。问题在于我认为大多数程序员都懒得不知道他们何时需要支撑以及什么时候不需要。如果你不知道，只要把它们粘在各处，它就不会受伤。很多很多大括号意味着要维护的代码很多很多，而不需要在那里。


如果贵公司不使用可以跟上牙套的编辑器，那么他们可能会遇到麻烦...

老实说，尽管完全支撑是不必要的，这是

之一的规则，这取决于你的编码标准的其余部分。如果

没有关于缩进和支撑位置或相关问题的规则，

腰带和牙套（没有双关语）方法可能更安全。


我最近阅读了一个禁止使用三元（条件
？）运算符的标准。我发现大多数C程序员都没有费心去学习
如何使用它而不想让别人使用它，因为那样他们就不得不弄明白了。但是我也发现在大多数使用它的情况下，它可以使代码更清晰，即使是那些不习惯使用它的人。

a = （b == c）？ d：e;

如果（b == c）{
a = d;
} <与

一样可理解且更易于维护br />其他{
a = e;
}

在第一种情况下，在一行中很明显，您只是将
值分配给基于在条件。使用if语句会导致更多的代码在维护时出错。


嗯，这取决于。我会以不同的方式放置括号，

其他人可能会将它们排除在外，第三种可能会添加各种

括号。

但是，除非部分语言的运营商或关键词是

仅在特殊情况下才可取。如果

for，我会非常愤怒。和做不允许。


我遇到的另一个问题是功能问题的一种解决方法。我认为，如果有条件需要提前退出某个功能，那么应该提前退出。例如：

int funct（int arg）
{

....
如果（条件）返回ERROR;



返回OK;

比funct（int arg）要好得多 {
int retval = ERROR;
....

if（！condition）{
retval = OK;
（其余功能） ;
...
} / *结束if（！condition）* /

返回retval;

在第一种情况下你''已经非常清楚将返回什么样的价值，你减少了所涉及的括号数量，并且你已经减少了函数主要部分的缩进级别。反对这一点的论点是，可能需要在
函数中进行一些清理，这种风格可能导致白痴退出该功能而不进行清理。我的反驳是第一，只有少数功能要求在退出
功能之前完成清理工作。第二，清理应该是一个单独的功能，无论如何，
可以从父功能的任何地方调用，你只是不能指望保护代码免受白痴攻击的标准那么为什么呢？假装它呢？


你再一次提倡你自己的观点。

为什么不制定一个只允许单一退出点的规则

for包含清理代码的函数。是否通过状态变量达到
，将功能转换或分成三部分

（初始化，工作，清理），使规则仅针对

实际的清理程序，可以由程序员和

的情况决定。


类似的问题是这个：

if（condition）{
retval = func（arg）;
}
如果必须在每个函数之前测试那个条件那么条件
应该由函数评估：

retval = func（arg，condition）;

... int func（int arg，BOOLEAN condition）
{

如果（！条件）返回OK;

...
}


完全有效这个案例。但是如果func已经有七个参数，那么你可能会给自己增加一两个人的伤害......人们只会得到盲目

关于参数。

鉴于你喜欢简短的表达式，你可能会选择

condition&& （retval = func（arg））


总的来说，我认为代码更少，比大量代码更易于维护。
任何地方我都可以减少代码行使维护更容易。例如：

如果（条件）
{
retval = func（a，b）;
}

{
retval = func（a，c）;
}
if（retval！= OK）
{
error_exit_func（）;
} <

如果（！func（a，condition？b：c）error_exit_func（）;


Apart从缺少的右括号开始，我认为

太多了。我至少会打电话给

error_exit_func（）驻留在第二行。


有没有人会就这些问题与我达成一致意见，还是我这种编码的唯一声音？

可能你会发现一些人会同意你所说的最多

。


在不知道代码的类型和复杂性的情况下，通常

可以完全拼凑你的建议：编码标准

符合创作者的口味。


我建议你sta rt从代码的目的和所需的

文档级别。

然后添加规则，如某些类型的对象的命名约定，

统一接口（来源，目的地，大小或目的地，来源，

大小或来源，大小，目的地或......）

如果您的工作表上还有一些空间论文，州规则

喜欢代码使得它可以像散文一样阅读，避免无聊的

评论。具体说明评论风格。

如果还有更多规则的空间，请查看错误的错误

，这需要花费大部分时间才能找到。执行减少这些错误数量的规则是一个好主意。如果这意味着每个

的新模块都会进行单元测试，那么就这样吧。

如果还有更多规则的空间，你就该作弊并去了

卫生纸...


不要针对任何让你发痒的规则。

去寻找问题。

上述订单的原因：如果需要明确的文件，

错误发现得更快，并且投入足够的人认为

在编码之前自动编码一个较少复杂的代码方式。

统一接口和命名规则可以节省时间。

淘汰适合配额评论或其他不良习惯

一般规则比试图涵盖所有

积极的好评/不良评论情况更有效。

如果有的话是一个如何破解代码破坏的模式

它不仅仅是在争论支撑的错综复杂

的位置。如果你找不到这样的规则，那么你已经找到了

你的软件中需要重新设计或替代

解决方案的点...

HTH

Michael

-

电子邮箱：我的是/ at / gmx / dot / de地址。

Op Sun，2004年12月19日18:05:06 -0500，schreef Natt Serrasalmus：

经过多年的运作，没有任何编码标准，我最近开始工作的公司已经决定拥有一些可能是个好主意。我参与了这项计划。

通常我发现编码标准是由
公司的某个人编写的，他有一种他喜欢的编码方式然后试图强制<每个人都以他喜欢的方式编写代码，不是出于任何理性的原因，而只是为了他喜欢的主观方式。我认为这是错误的。


i认为任意决定（通常）是正确的。

这是标准的全部，均匀性。

例如我本来希望处理器供应商已决定

endianness，很少或很大，每个人都会遵守这个标准。


可能在某些情况下另一个约定会更有用

（？），但是拥有一个endianness的优势确实非常大！


i不喜欢这些编码标准我自己，每个人都应按照我的方式编码：
做:-)

if（！func（a，condition？b：c）error_exit_func（）;

恕我直言，这太短了。可读性非常重要。即使对于新手程序员来说也应该很容易。

但是如果新手程序员不喜欢不知道（？:)他们应该学习它而不是在编码标准中禁止它的

>之后多年没有任何编码标准的操作，我最近开始工作的

公司已经决定它可能会有一些好主意。我参与了这个倡议。


大多数编码标准，如果以与员工相同的方式应用

着装要求，则相当于所有员工应该

穿着一件6号红色连衣裙目录＃AC37626R来自Macy's的工作期间

hours"男性或怀孕没有例外。


请考虑有些东西不值得花费

a很多时间标准化，比如定位大括号，

除了同意outdenting很糟糕：


#include< stdio.h>

#include< ; stdlib.h>

int main（int argc，char ** argv）{

if（argc< 2）{

printf （用法：bulrfl filename \ n）;

}

退出（0）;

}


通常我发现编码标准是由
公司的某个人编写的，他有一种他喜欢的编码方式，然后试图强迫其他人按照他的方式编写代码喜欢它，不是出于任何理性的原因，而只是因为他喜欢它的主观方式。我认为这是错误的。


如果您希望标准化代码布局，我可以想到的最佳标准是所有C代码都应该通过GNU缩进与<在检入源代码控件之前，有以下选项的


system。 （我真的不在乎你选择什么选项，只要没有选择

outdenting，我很确定它甚至不是

如有必要，选择硬币使用哪些选项

翻转）。一些源代码控制系统甚至可以自动完成。

这在代码布局风格问题上非常令人讨厌
与代码的执行或代码的可读性和维护几乎没有关系。

我也认为编码标准试图阻止白痴做傻是错误的的东西。无论一些标准有多么严格，有人愚蠢的是要找到一种方法来为代码做一些愚蠢的事情。我的观点是，不是让标准对于优秀的编码人员更具限制性，而是应该加快编写好的编码，以便能够编写出良好的代码，而不是按标准编写。 。例如，看似普遍的态度，完全括号
语法是要走的路（这将阻止白痴）。


我同意即使在可选的情况下使用大括号（例如在if中）但

不是因为这将阻止白痴。我认为它使

更具可读性。

我强烈不同意。
有很多时候没有必要使用括号的
更易读的代码。它还减少了支架的维护;支撑越少，支撑越大越容易。


如果按匹配，你的意思是缩进到同一级别，让GNU

缩进处理它。如果你的意思是不平衡，那就把它们留下来

对你来说不会有多大帮助，因为你不会再那么一致了。

将两者都放在一起。

问题在于我认为大多数程序员都懒得知道他们何时需要支撑以及什么时候他们不知道。如果你不知道，只要把它们粘在各处，它就不会受伤。很多很多大括号意味着要维护的代码很多很多，而不需要在那里。


如果大括号是很多很多代码，我认为代码有很多问题，而不是大括号。

我最近读了一个禁止使用三元（条件
？）运算符的标准。我发现大多数C程序员都没有费心去学习
如何使用它而不想让别人使用它，因为那样他们就不得不弄明白了。但是我也发现在大多数使用它的情况下，它可以使代码更清晰，即使是那些不习惯使用它的人。

a = （b == c）？ d：e;

如果（b == c）{
a = d;
} <与

一样可理解且更易于维护br />其他{
a = e;
}


我特别发现它在某些调试情况下很有用：


printf（" Name：％s Address：％s \ n"，

（name == NULL）？"（null）"：name，

（addr == NULL）？"（null）"：addr）;


其中引入临时变量或复制

printf （）是不受欢迎的。它使％s和参数

相关联，保证不会更容易为NULL。


当你开始嵌套时？：，但是，你可能已经走得太远。

在第一种情况下，在一行中很明显，你只是根据条件为一个
赋值。使用if语句会导致更多的代码在维护时出错。
我遇到的另一个问题是功能问题的一种解决方法。我认为，如果有条件需要提前退出某个功能，那么应该提前退出。例如：


一般来说，我同意这里，因为你最终会有更深层次的嵌套

条件，并且接近函数的末尾，你必须看看

仔细查看你不必担心的错误情况

因为你已经检查了它们。

int funct（int arg）
{

....
如果（条件）返回ERROR;

...
比funct（int arg）好多了
{/ / int int retval = ERROR;
....

if（！condition）{
retval = OK;
（其余功能）;
......
} / *结束if（！condition）* /

返回retval;

在第一种情况下，你已经非常清楚将会是什么值
返回，你减少了所涉及的括号数量，并且你已经减少了函数主要部分的缩进级别。反对这一点的论点是，可能需要在
函数中进行一些清理，这种风格可能导致白痴退出该功能而不进行清理。我的反驳是第一，只有少数功能要求在退出
功能之前完成清理工作。第二，清理应该是一个单独的功能，无论如何，


清理几乎不可能在一个单独的功能中，因为所有涉及的局部变量都是b $ b。它真的没有多大意义

定义一个单独的函数，参数为7个指针免费

如果它们被分配，2个打开FILE *'到关闭，如果他们是开放的b $ b。另一方面，如果您小心地将FILE *''初始化为NULL并将

设置为NULL，则可以使用closeifopen（）定义

以下关闭文件。现在有了内存分配，你需要
不需要freeifallocated（），因为free（）本身也做同样的事情。

可以在父函数的任何地方调用第三，你只是不能依靠标准来保护代码免受白痴的影响，所以为什么
假装它呢？

类似的问题是这个：

如果（条件）{
retval = func（arg）;
}
如果必须在每个函数之前测试该条件那么条件
应该由函数评估：

retval = func（arg，condition）;


这取决于条件和函数的相关性。

例如，如果func实际上是fopen（），则条件是否是

事务日志记录已启用，我看不到将它们组合成一个

函数。另一方面，我可以看到定义


void closeifopen（FILE * arg）

{

if（arg！= NULL）

{

fclose（arg）;

}

返回;

}


，因为这个条件与你是否能成功地执行这个功能有关，而不是一些无关的原因

为什么你可能会或可能不想执行它。

...
int func（int arg，BOOLEAN条件）
{

如果（！condition）返回OK;

...
}
总的来说，我认为代码越少，代码就越多，代码就越多。

代码行是一个荒谬的指标，你不应该使用它。

一个好的编码标准将禁止对任何<的代码行计数br />
原因。将它发挥到极致，所有连续的非预处理器

语句都在同一行上，直到达到行长度限制。

例如：

if（条件）
{
retval = func（a，b）;
}

{
retval = func（a，c） ;
}
如果（retval！= OK）
{
error_exit_func（）;
}

好多了方式是

if（！func（a，condition？b：c）error_exit_func（）;


不，我不同意这是更好的，我认为从第一个案例转换到第二个案例到第二个案例是一个BUG。谁说OK等于零？

哦，是的，你也失踪了a）。


但这真的很糟糕：

if（condition）{retval = func（a，b）;} else {retval = func（a） ，c）;} if（retval！= OK）{error_exit_func（）;}

是否有人会在这些问题上与我达成一致意见，或者我是单独的声音这种类型的编码？

我会跟你一起去你把第一部分翻译成

retval = func（a，条件？ b：c）;


Gordon L. Burditt

After years of operating without any coding standards whatsoever, the
company that I recently started working for has decided that it might be a
good idea to have some. I''m involved in this initiative.

Typically I find that coding standards are written by some guy in the
company who has a way of coding that he likes and then tries to force
everybody else to write code the way he likes it, not for any rational
reason, but simply for the subjective way he likes it. I think this is
wrong.
This is particularly irksome when it comes to issues of code layout style
which has very little relevance to the execution of the code or the
readablility and maintenance of the code.

I also think it is wrong for coding standards to try to prevent idiots from
doing stupid things. No matter how stringent some standards are, somebody
stupid is going to find a way to do something stupid to the code. My point
is that instead of making the standard more restrictive on good coders, the
bad coders should be brought up to speed to be able to write good code, not
pandered to by the standard. For example there is the seemingly universal
attitude that fully bracketed
syntax is the way to go (this will stop the idiots). I strongly disagree.
There are many times that leaving out the braces where not necessary makes
for more readable code. It also reduces the maintenance of braces; the fewer
braces the easier it is to keep braces matched up. The problem is that I
think most coders are too lazy to be bothered to know exactly when they need
braces and when they don''t. If you don''t know, just stick them in everywhere
that it can''t hurt. Lots and lots of braces means lots and lots of code to
maintain that doesn''t need to be there.

I recently read a standard that prohibited use of the ternary (conditional
?) operator. I find that most C programmers just haven''t bothered to learn
how to use it and don''t want others to use it, because then they''ll have to
figure it out. However I have also found that in most cases where it is
used, it can make the code much clearer even for those who are not
accustomed to its use.

a = (b == c) ? d : e;

Is just as understandable and more maintainable than

if (b==c) {
a = d;
}
else {
a = e;
}

In the first case it is obvious in one line that you are simply assigning a
value to a based on the condition. The use of the if statement makes for a
lot more code that is subject to error in maintenance.

Another issue that I have come across is the one way out of a function
issue. I contend that if there are conditions that warrant an earlier exit
from a function then the early exit should be taken. For eample:

int funct( int arg )
{

.....

if (condition) return ERROR;

....

return OK;

is much better than

int funct( int arg )
{
int retval = ERROR;
.....

if ( !condition) {
retval = OK;
(rest of function);
....
} /* end of if ( !condition) */

return retval;

In the first case you''ve been very clear as to what values are going to be
returned, you''ve reduced the number of braces involved and you''ve reduced
the indentation level of the major part of the function. The argument
against this is that there may be some clean up that needs to be done in a
function and this style may lead an idiot to exit the function with out
doing the clean up. My rebuttal is that number one, only a small minority of
functions have the requirement that the clean up be done before exiting the
function. Number two, the clean up should be a separate function anyway that
can be called from anywhere in the parent function and number three you just
can''t count on the standard to protect the code from idiots anyway so why
pretend that it does?

A similar issue is this one:

if (condition) {
retval = func(arg );
}

If that condition has to be tested before each function then the condition
should be evaluated by the function instead:

retval = func( arg, condition);

....
int func( int arg, BOOLEAN condition)
{

if (!condition) return OK;

....
}
On the whole I consider less code to be more maintainable than lots of code.
Anywhere I can reduce the lines of code then that makes it easier to
maintain. For example:

if( condition)
{
retval = func( a, b);
}
else
{
retval = func( a, c);
}

if (retval != OK)
{
error_exit_func();
}

a much better way is

if ( !func(a, condition ? b : c ) error_exit_func();
Is there anybody out there who will agree with me on these issues or am I
the lone voice for this type of coding?

解决方案

Natt Serrasalmus wrote:

After years of operating without any coding standards whatsoever, the
company that I recently started working for has decided that it might be a
good idea to have some. I''m involved in this initiative.

Typically I find that coding standards are written by some guy in the
company who has a way of coding that he likes and then tries to force
everybody else to write code the way he likes it, not for any rational
reason, but simply for the subjective way he likes it. I think this is
wrong.
Well, from the rest of your post one could get the impression
that you are just a more self-aware flavour of "this guy".
Your examples show preferences which may be more restrictive
for some programmers than other coding standards.

This is particularly irksome when it comes to issues of code layout style
which has very little relevance to the execution of the code or the
readablility and maintenance of the code.
This is correct. Sooner or later someone will become coding police
more interested in the right use of indentation, white-spaces,
comment styles and so on.
However, having had the dubious pleasure of coding in a group
where people did not care about the "details", I think that coding
rules which can be scribbled down on one piece of paper are the
best way to go. If you use cvs, even stuff like indentation can
be important enough to be put down on said sheet.

I also think it is wrong for coding standards to try to prevent idiots from
doing stupid things. No matter how stringent some standards are, somebody
stupid is going to find a way to do something stupid to the code. My point
is that instead of making the standard more restrictive on good coders, the
bad coders should be brought up to speed to be able to write good code, not
pandered to by the standard. For example there is the seemingly universal
attitude that fully bracketed
syntax is the way to go (this will stop the idiots). I strongly disagree.
There are many times that leaving out the braces where not necessary makes
for more readable code. It also reduces the maintenance of braces; the fewer
braces the easier it is to keep braces matched up. The problem is that I
think most coders are too lazy to be bothered to know exactly when they need
braces and when they don''t. If you don''t know, just stick them in everywhere
that it can''t hurt. Lots and lots of braces means lots and lots of code to
maintain that doesn''t need to be there.
If your company does not use editors which can keep up with braces,
then they may be in trouble...
Honestly, even though "full bracing" is unnecessary, this is one of
the rules which depend on the rest of your coding standard. If there
are no rules about indentation and brace placement or related issues,
the belt and braces (no pun intended) method may be safer.

I recently read a standard that prohibited use of the ternary (conditional
?) operator. I find that most C programmers just haven''t bothered to learn
how to use it and don''t want others to use it, because then they''ll have to
figure it out. However I have also found that in most cases where it is
used, it can make the code much clearer even for those who are not
accustomed to its use.

a = (b == c) ? d : e;

Is just as understandable and more maintainable than

if (b==c) {
a = d;
}
else {
a = e;
}

In the first case it is obvious in one line that you are simply assigning a
value to a based on the condition. The use of the if statement makes for a
lot more code that is subject to error in maintenance.
Well, this depends. I would have placed the parentheses differently,
someone else might leave them out, a third might add all sorts of
parentheses.
However, banishing part of the language''s operators or keywords is
only advisable in very special cases. I would be very wroth if
"for" and "do" were disallowed.

Another issue that I have come across is the one way out of a function
issue. I contend that if there are conditions that warrant an earlier exit
from a function then the early exit should be taken. For eample:

int funct( int arg )
{

....

if (condition) return ERROR;

...

return OK;

is much better than

int funct( int arg )
{
int retval = ERROR;
....

if ( !condition) {
retval = OK;
(rest of function);
...
} /* end of if ( !condition) */

return retval;

In the first case you''ve been very clear as to what values are going to be
returned, you''ve reduced the number of braces involved and you''ve reduced
the indentation level of the major part of the function. The argument
against this is that there may be some clean up that needs to be done in a
function and this style may lead an idiot to exit the function with out
doing the clean up. My rebuttal is that number one, only a small minority of
functions have the requirement that the clean up be done before exiting the
function. Number two, the clean up should be a separate function anyway that
can be called from anywhere in the parent function and number three you just
can''t count on the standard to protect the code from idiots anyway so why
pretend that it does?
You are once more only advocating your own views.
Why not formulate a rule which allows only single exit points
for functions containing cleanup code. Whether this is reached
by state variables, goto or splitting the function into three parts
(initialization, work, cleanup) such that the rule only aims at
the actual cleanup routine, can be up to the programmers and
situation.

A similar issue is this one:

if (condition) {
retval = func(arg );
}

If that condition has to be tested before each function then the condition
should be evaluated by the function instead:

retval = func( arg, condition);

...
int func( int arg, BOOLEAN condition)
{

if (!condition) return OK;

...
}
Perfectly valid for this case. But if func already has seven
parameters, then you are probably doing yourself a disservice
by adding another one or two -- people will just get "blind"
with respect to the arguments.
Given your liking for short expressions you might just go for
condition && (retval = func(arg))

On the whole I consider less code to be more maintainable than lots of code.
Anywhere I can reduce the lines of code then that makes it easier to
maintain. For example:

if( condition)
{
retval = func( a, b);
}
else
{
retval = func( a, c);
}

if (retval != OK)
{
error_exit_func();
}

a much better way is

if ( !func(a, condition ? b : c ) error_exit_func();
Apart from the missing closing parenthesis, I think
that is too much. I would at least let the call to
error_exit_func() reside on a second line.

Is there anybody out there who will agree with me on these issues or am I
the lone voice for this type of coding?

Probably you will find some people who will agree with most
you said.

Without knowing the type and complexity of the code, one usually
can cobble together exactly what you proposed: A coding standard
fitted to the tastes of the creators.

I suggest you start from the purpose of the code and the needed
documentation level.
Then add rules like naming conventions for certain types of objects,
unified interfaces (source, destination, size or destination, source,
size or source, size, destination or ...)
If there is still some room on your sheet of paper, state rules
like "code such that it can be read like prose, avoiding inane
comments". Be specific about comment styles.
If there is still room for more rules, have a look at the bugs
which cost most time to find. Enforcing rules which reduce the
number of these bugs are a good idea. If this means that every
new module gets unit tests, so be it.
If there is still room for more rules, you cheated and went for
toilet paper...

Do not go for rules aiming at whatever makes you itch.
Go for the problems.
Reasons for the above order: If clear documentation is required,
bugs are found sooner, and people who invest enough thought
before coding automatically code in a less convoluted way.
Unified interfaces and naming rules save time.
Weeding out the "fit the quota" comments or other bad habits
by general rules is more effective than trying to cover all
positive good comment/bad comment situations.
If there is a pattern of how bugs get into the code breaking
it helps more than arguing about the intricacies of brace
placement. If you cannot find such rules, then you have found
the point in your software where redesign or alternative
solutions are needed...
HTH
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.

Op Sun, 19 Dec 2004 18:05:06 -0500, schreef Natt Serrasalmus:

After years of operating without any coding standards whatsoever, the
company that I recently started working for has decided that it might be a
good idea to have some. I''m involved in this initiative.

Typically I find that coding standards are written by some guy in the
company who has a way of coding that he likes and then tries to force
everybody else to write code the way he likes it, not for any rational
reason, but simply for the subjective way he likes it. I think this is
wrong.
i think an arbitrary decision is (often) right.
that''s what standards are all about, uniformity.
e.g. i would have liked that processor vendors had made a decision on
endianness, little or big, and everyone would conform to that standard.

maybe in some circumstances the other convention would be more usefull
(?), but the advantage of having one endianness would be _very_ big indeed!

i don''t like these coding standard myself, everyone should code the way I
do :-)
if ( !func(a, condition ? b : c ) error_exit_func();

IMHO this is too short. readability is very important. it should be
easy even for novice programmers.
but if novice programmers don''t know ( ? : ) they should learn it instead
of prohibiting it in the coding standard

>After years of operating without any coding standards whatsoever, the

company that I recently started working for has decided that it might be a
good idea to have some. I''m involved in this initiative.
Most coding standards, if applied in the same way as an employee
dress code, would amount to something like "all employees shall
wear a size 6 red dress catalog # AC37626R from Macy''s during working
hours" with no exceptions for the men or the pregnant.

Please consider that there are things that are not worth spending
a lot of time standardizing, such as the positioning of braces,
except to agree that outdenting is awful:

#include <stdio.h>
#include <stdlib.h>
int main(int argc, char **argv) {
if (argc < 2) {
printf("Usage: bulrfl filename\n");
}
exit(0);
}

Typically I find that coding standards are written by some guy in the
company who has a way of coding that he likes and then tries to force
everybody else to write code the way he likes it, not for any rational
reason, but simply for the subjective way he likes it. I think this is
wrong.
If you wish to standardize code layout, the best standard I can
think of is "All C code shall be run through GNU indent with the
following options before being checked into the source code control
system." (I really don''t care what options you choose, as long as
outdenting is not selected, and I''m pretty sure it''s not even
supported. If necessary, select which options are used by coin
flipping). Some source code control systems can even be made to
do this automatically.
This is particularly irksome when it comes to issues of code layout style
which has very little relevance to the execution of the code or the
readablility and maintenance of the code.

I also think it is wrong for coding standards to try to prevent idiots from
doing stupid things. No matter how stringent some standards are, somebody
stupid is going to find a way to do something stupid to the code. My point
is that instead of making the standard more restrictive on good coders, the
bad coders should be brought up to speed to be able to write good code, not
pandered to by the standard. For example there is the seemingly universal
attitude that fully bracketed
syntax is the way to go (this will stop the idiots).
I agree with braces being used even where optional (e.g. in an if) but
not for the reason "this will stop the idiots". I think it makes
it more readable.
I strongly disagree.
There are many times that leaving out the braces where not necessary makes
for more readable code. It also reduces the maintenance of braces; the fewer
braces the easier it is to keep braces matched up.
If by "matched up", you mean indented at the same level, let GNU
indent handle it. If you mean unbalanced, then leaving them out
is not going to help much, as you won''t be any more consistent about
leaving both out as putting both in.
The problem is that I
think most coders are too lazy to be bothered to know exactly when they need
braces and when they don''t. If you don''t know, just stick them in everywhere
that it can''t hurt. Lots and lots of braces means lots and lots of code to
maintain that doesn''t need to be there.
If braces are "lots and lots of code", I think the code has a lot
more problems than braces.
I recently read a standard that prohibited use of the ternary (conditional
?) operator. I find that most C programmers just haven''t bothered to learn
how to use it and don''t want others to use it, because then they''ll have to
figure it out. However I have also found that in most cases where it is
used, it can make the code much clearer even for those who are not
accustomed to its use.

a = (b == c) ? d : e;

Is just as understandable and more maintainable than

if (b==c) {
a = d;
}
else {
a = e;
}
I especially find it useful in certain debugging situations:

printf("Name: %s Address: %s\n",
(name == NULL) ? "(null)" : name,
(addr == NULL) ? "(null)" : addr );

where the introduction of temporary variables or replicating the
printf() is undesirable. It makes relating the %s and the argument
that''s guaranteed not to be NULL easier.

When you''ve started nesting ?:, though, you''ve probably gone too far.
In the first case it is obvious in one line that you are simply assigning a
value to a based on the condition. The use of the if statement makes for a
lot more code that is subject to error in maintenance. Another issue that I have come across is the one way out of a function
issue. I contend that if there are conditions that warrant an earlier exit
from a function then the early exit should be taken. For eample:
Generally, I agree here, because you end up with deeper-nested
conditionals, and near the end of the function, you have to look
carefully to see what error conditions you don''t have to worry
about because you''ve already checked them.
int funct( int arg )
{

....

if (condition) return ERROR;

...

return OK;

is much better than

int funct( int arg )
{
int retval = ERROR;
....

if ( !condition) {
retval = OK;
(rest of function);
...
} /* end of if ( !condition) */

return retval;

In the first case you''ve been very clear as to what values are going to be
returned, you''ve reduced the number of braces involved and you''ve reduced
the indentation level of the major part of the function. The argument
against this is that there may be some clean up that needs to be done in a
function and this style may lead an idiot to exit the function with out
doing the clean up. My rebuttal is that number one, only a small minority of
functions have the requirement that the clean up be done before exiting the
function. Number two, the clean up should be a separate function anyway that
Cleanup can hardly ever be in a separate function because of all
the local variables involved. It really doesn''t make much sense
to define a separate function with arguments of 7 pointers to free
if they were allocated and 2 open FILE *''s to close if they were
open. On the other hand, there is some use for closeifopen() defined
below if you are careful to initialize FILE *''s to NULL and set
them to NULL after closing a file. Now with memory allocation, you
don''t need freeifallocated() since free() itself does the same thing.
can be called from anywhere in the parent function and number three you just
can''t count on the standard to protect the code from idiots anyway so why
pretend that it does?

A similar issue is this one:

if (condition) {
retval = func(arg );
}

If that condition has to be tested before each function then the condition
should be evaluated by the function instead:

retval = func( arg, condition);
This depends on how the condition and the function are related.
If, for example, func is actually fopen(), and condition is whether
transaction logging is enabled, I can''t see combining those into one
function. On the other hand, I can see defining

void closeifopen(FILE *arg)
{
if (arg != NULL)
{
fclose(arg);
}
return;
}

because the condition is related to whether you can successfully
execute the function at all, not some unrelated reason as to
why you might or might not want to execute it.
...
int func( int arg, BOOLEAN condition)
{

if (!condition) return OK;

...
}
On the whole I consider less code to be more maintainable than lots of code.
Anywhere I can reduce the lines of code then that makes it easier to
maintain.
Lines of code are a ridiculous metric, and you shouldn''t use it.
A good coding standard will forbid counting lines of code for any
reason. Taking it to the extreme, all consecutive non-preprocessor
statements go on the same line until you hit line length limits.
For example:

if( condition)
{
retval = func( a, b);
}
else
{
retval = func( a, c);
}

if (retval != OK)
{
error_exit_func();
}

a much better way is

if ( !func(a, condition ? b : c ) error_exit_func();
No, I don''t agree this is BETTER, and I think translating from the
first case to the second is a BUG. Who said OK is equal to zero?
Oh, yes, you''re also missing a ).

But this really sucks:
if(condition){retval=func(a,b);}else{retval=func(a ,c);}if(retval!=OK){error_exit_func();}
Is there anybody out there who will agree with me on these issues or am I
the lone voice for this type of coding?

I''ll go along with you as far as translating the first part to
retval = func(a, condition ? b : c);

Gordon L. Burditt

这篇关于编码标准的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！