[也许OT]如何让人们相信ANSI标准一致性的重要性？ [英] [Maybe OT] How to convince people about the importance of ANSI standards conformance ?
问题描述
我正在开发一个传统的用户空间应用程序，大约15年前，它已经完全用C开发了
。毋庸置疑，它甚至没有部分符合任何标准。
我的团队正在为此应用添加新功能。作为一个
开始，我让他们编写干净的代码，这符合ANSI标准的某些
方面。我不是标准的权威，并且
我的知识基于C Unleashed。
为此我请他们 -
1.避免使用以_开头的标识符名称。
我要求他们更改以下结构 -
typedef struct _foo {
...
} Foo;
到
typedef struct foo_ {
...
} Foo;
2.避免与系统命名空间发生冲突。为了避免id名称
以str开头，是等等。
我想通过让他们意识到这些问题，我们可以写一下
代码更干净，易于维护，部分符合
ANSI。
但是他们没有看到我的一致性和我面临着像
这样的问题 -
1.我们如何使用诸如
_DBGetFooRecord等名称来践踏系统名称空间。
2.标准等是垃圾，绝不是我们要遵守的。我们
将以_we_感觉的方式编写代码。
我的防守是我从C Unleashed中学到的所有东西，但它是
证明自己很弱。我希望你们所有人都能从clc那里帮助我提高我的防御能力，这样我就可以让他们看到一些亮点！
我不是确定这封邮件是OT还是OT（开或关），但是我发布了它。
干杯，
Amarendra
2004年1月18日20:45:44 -0800， ro ** @ zworg.com （Amarendra GODBOLE）
在comp.lang.c中写道：
我正在开发一个遗留用户空间应用程序，大约15年前，它已完全用C语言开发。毋庸置疑，它甚至不符合任何标准。
我的团队正在为此应用添加新功能。作为一个开始，我要求他们编写干净的代码，这符合ANSI标准的某些方面。我不是标准的权威，而且我的知识基于C Unleashed。
为此我请他们 -
1.避免使用以_开头的标识符名称。
我让他们改变以下结构 -
typedef struct _foo {
...
} Foo;
br />
typedef struct foo_ {
...
} Foo;
请注意，几乎没有必要或特别有用的是
为结构定义提供结构标记和typedef。
除非你需要，否则不要这样做。
2.避免与系统命名空间发生冲突。为了避免id名称以str，is等开头。
我想通过让他们意识到这些问题，我们可以写出更干净，更容易的代码保持，部分符合ANSI。
但是他们没有看到我的一致性，我面临着像
这样的问题.1。如何我们用类似
_DBGetFooRecord等名称来践踏系统命名空间。
也许你会，也许你不会。这正是关键所在，
命名空间是为语言标准（__FILE__，等等）保留的。
和实现，意味着编译器和它'''标题。
当你尝试使用新编译器构建旧代码时，你可以想出一些难以置信的难以发现的错误，或者甚至更新版本的
你当前的编译器，以及编译器内部的某处或
某些私有包含文件是一个匹配的宏或内在符号
你的一个标识符。
2.标准等是垃圾，绝不是我们要遵守的。我们将以_we_感觉的方式编写代码。
这是一个志愿者开源项目还是商业产品？
你是否与专业程序员打交道或者想要教授一个班级？
的螃蟹学龄前儿童？
其中一个原因对于大量有缺陷的软件来说，
今天是太多程序员的牛仔知识态度。
那些仍然认为编程是艺术的人而不是一个科学或
工程学科可能无法帮助。
如果为我工作，他们会改变态度或找到
他们自己在寻找一份新工作。
我的防守就是我从C Unleashed那里学到的所有东西，但它证明了自己很弱。我希望你们所有人都能从clc那里帮助我提高防御能力，这样我就能让他们看到一些亮点！
我不确定这封邮件是OT还是OT （开或关），但是我发布了它。
欢呼，
Amarendra
-
Jack Klein
主页： http：// JK-Technology.Com
常见问题解答
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c ++ http://www.parashift.com/c++ -faq-lite /
alt.comp.lang.learn.c-c ++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html
Amarendra GODBOLE wro te：
我正在开发一个遗留的用户空间应用程序
大约15年前完全用C语言开发。
不用说，它没有甚至部分符合任何标准。
我的团队正在为此应用程序添加新功能。
作为一个开始，我要求他们编写干净的代码
符合ANSI标准的某些方面。
我不是标准的权威
我的知识基于C Unleashed。
为此我请他们 -
1.避免使用以_开头的标识符名称。
我要求他们更改以下结构 -
typedef struct _foo {
...
} Foo;
typedef struct foo_ {
...
} Foo;
请他们写一下
typedef struct Foo {
//。 。 。
} Foo;
代替。混淆命名空间毫无意义。
2.避免与系统命名空间发生冲突。
要避免以str开头的id名称，是等等。
我想通过让他们意识到这些问题，
我们可以编写更干净，易于维护和部分符合ANSI的代码。
但是他们没有看到我的一致性
并且我遇到了类似的问题 -
1.我们如何用_DBGetFooRecord等名称来篡改系统命名空间
2标准等等都是垃圾，我们绝不会遵守这个标准。
我们将按照我们感受到的方式编写代码。
我的防守就是我从中学到的一切C释放了
但事实证明它很弱。
我希望你们都能从clc那里帮助我让我的防守变得更强大
这样我才能让他们看到一些光明！
除非你是团队领导，否则你没有生意这样做。
我不确定ho你可以成为一个团队负责人监督C程序员
没有*强大的掌握ANSI / ISO C标准。
如果你只是另一个团队会员，试着听而不是说话。
尝试向更有经验的团队成员学习。
小心他们的坏习惯，并努力不自己获取。
Jack Klein写道：
2004年1月18日20:45:44 -0800， ro ** @ zworg.com （Amarendra GODBOLE）
在comp.lang.c中写道：
typedef struct foo_ {
...
} Foo;
请注意，为结构定义提供结构标记和typedef几乎不需要或特别有用。
除非你需要，否则不要这样做。
公平评论，但我想提出一些有利于它的观点：1）它可以让b $ b赚取生命一些代码分析工具更容易; 2）它永远不会伤害，前提是
一个类型的命名约定甚至更高; 3）它使
不透明打字稍微容易一些; 4）如果你这样做/全部/该死的时间，当你/你需要它的时候就会有b $ b，而你不必考虑什么
改变了。
< snip>
[由于嗤之以鼻，我应该指出OP正在对抗
遵循态度，而不是支持它！]
2.标准等是垃圾，我们决不会遵守这一点。我们将按照_we_感觉的方式编写代码。
这是一个志愿者开源项目还是商业产品？您是否与专业程序员打交道或尝试教授螃蟹学龄前儿童课程？
对我来说，他们不是听起来像是两组人。更确切地说，他们只是完全正常的C程序员还没有发现comp.lang.c.你知道，其中有很多只是其中的一部分。
今天牛奶知道的数量众多的原因之一就是牛仔知道了太多程序员的所有态度。
那些仍然认为编程是一门艺术而不是科学或工程学科的人可能会有所帮助。
我会买而不是，因为我认为它是一种艺术/和/或科学/和/或工艺。
-
Richard Heathfield： bi****@eton.powernet.co.uk
Usenet是一个奇怪的地方。 - Dennis M Ritchie，1999年7月29日。
C FAQ： http://www.eskimo.com/~scs/C-faq/top.html
K& R答案，C书等：< a rel =nofollowhref =http://users.powernet.co.uk/etontarget =_ blank> http://users.powernet.co.uk/eton
Hi,
I am working on a legacy user space app, which has been developed
entirely in C, some 15 years ago. Needless to say, it does not even
partially conform to any standard.
My team is in the process of adding new features to this app. As a
start off, I asked them to write clean code, which conforms to certain
aspects of the ANSI standard. I am no authority on the standard, and
my knowledge is based on C Unleashed.
For that I asked them to --
1. Avoid identifier names starting with _.
I asked them to change the following structure --
typedef struct _foo {
...
} Foo;
to
typedef struct foo_ {
...
} Foo;
2. Avoid clashes with the system namespace. To avoid id names
beginning with str, is, etc.
I thought by making them aware of such issues, we can probably write
code which is more clean, easy to maintain, and partly conforming to
ANSI.
But they fail to see my point of conformance and I am faced with
issues like --
1. How will we trample the system namespace with names like
_DBGetFooRecord etc.
2. Standards etc are junk and in no way we are to conform to that. We
are going to write code the way _we_ feel it.
My defense was all that I have learned from C Unleashed, but it is
proving to ve weak. I''d like you all from clc to help me make my
defense stronger, so that I can make them see some light !
I am not sure if this mail is OT or OT (On or Off), but nevertheless I
am posting it.
Cheers,
Amarendra
On 18 Jan 2004 20:45:44 -0800, ro**@zworg.com (Amarendra GODBOLE)
wrote in comp.lang.c:
Hi,
I am working on a legacy user space app, which has been developed
entirely in C, some 15 years ago. Needless to say, it does not even
partially conform to any standard.
My team is in the process of adding new features to this app. As a
start off, I asked them to write clean code, which conforms to certain
aspects of the ANSI standard. I am no authority on the standard, and
my knowledge is based on C Unleashed.
For that I asked them to --
1. Avoid identifier names starting with _.
I asked them to change the following structure --
typedef struct _foo {
...
} Foo;
to
typedef struct foo_ {
...
} Foo;
Note that it is almost never necessary, or particularly helpful, to
provide both a structure tag and a typedef for a structure definition.
Don''t do this unless you need it.
2. Avoid clashes with the system namespace. To avoid id names
beginning with str, is, etc.
I thought by making them aware of such issues, we can probably write
code which is more clean, easy to maintain, and partly conforming to
ANSI.
But they fail to see my point of conformance and I am faced with
issues like --
1. How will we trample the system namespace with names like
_DBGetFooRecord etc.
Maybe you will, maybe you won''t. That''s exactly the point, that
namespace is reserved for the language standard (__FILE__, and such)
and for the implementation, meaning the compiler and it''s headers.
You can come up with some incredibly hard-to-find bugs when you try to
build your old code with a new compiler, or even a newer version of
your current compiler, and somewhere in the compiler internals or in
some private include file is a macro or intrinsic symbol that matches
one of your identifiers.
2. Standards etc are junk and in no way we are to conform to that. We
are going to write code the way _we_ feel it.
Is this a volunteer open source project or a commercial product? Are
you dealing with professional programmers or trying to teach a class
of crabby pre-schoolers?
One of the reasons for the incredible amount of defective software
today is the cowboy know-it-all attitude of far too many programmers.
Those who still see programming as an art and not as a science or
engineering discipline might be beyond help.
If the worked for me, they would change their attitudes or find
themselves looking for a new job.
My defense was all that I have learned from C Unleashed, but it is
proving to ve weak. I''d like you all from clc to help me make my
defense stronger, so that I can make them see some light !
I am not sure if this mail is OT or OT (On or Off), but nevertheless I
am posting it.
Cheers,
Amarendra
--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html
Amarendra GODBOLE wrote:
I am working on a legacy user space application
which has been developed entirely in C some 15 years ago.
Needless to say, it does not even partially conform to any standard.
My team is in the process of adding new features to this application.
As a start off, I asked them to write clean code
which conforms to certain aspects of the ANSI standard.
I am no authority on the standard
and my knowledge is based on C Unleashed.
For that I asked them to --
1. Avoid identifier names starting with _.
I asked them to change the following structure --
typedef struct _foo {
...
} Foo;
to
typedef struct foo_ {
...
} Foo;
Ask them to write
typedef struct Foo {
// . . .
} Foo;
instead. There is no point in cluttering up the namespace.
2. Avoid clashes with the system namespace.
To avoid id names beginning with str, is, etc.
I thought by making them aware of such issues,
we can probably write code which is more clean, easy to maintain
and partly conforming to ANSI.
But they fail to see my point of conformance
and I am faced with issues like --
1. How will we trample the system namespace
with names like _DBGetFooRecord etc.
2. Standards etc. are junk and in no way we are to conform to that.
We are going to write code the way _we_ feel it.
My defense was all that I have learned from C Unleashed
but it is proving to be weak.
I''d like you all from clc to help me make my defense stronger
so that I can make them see some light!
Unless you are the team leader, you have no business doing so.
I''m not sure how you could be a team leader supervising C programmers
without a *strong* grasp on the ANSI/ISO C standards.
If you are just another team member, try listening instead of talking.
Try to learn from more experienced team members.
Beware of their bad habits and endeavor not to acquire them yourself.
Jack Klein wrote:
On 18 Jan 2004 20:45:44 -0800, ro**@zworg.com (Amarendra GODBOLE)
wrote in comp.lang.c:typedef struct foo_ {
...
} Foo;
Note that it is almost never necessary, or particularly helpful, to
provide both a structure tag and a typedef for a structure definition.
Don''t do this unless you need it.
Fair comment, but I''d like to raise some points in its favour: 1) it can
make life easier for some code analysis tools; 2) it never hurts, provided
one has an even remotely decent naming convention for types; 3) it makes
opaque typing slightly easier; 4) if you do it /all/ the damn time, it''s
there when you /do/ need it, without your having to think about what
changed.
<snip>
[Because of snippage, I should point out that the OP is railing against the
following attitude, not espousing it!]
2. Standards etc are junk and in no way we are to conform to that. We
are going to write code the way _we_ feel it.
Is this a volunteer open source project or a commercial product? Are
you dealing with professional programmers or trying to teach a class
of crabby pre-schoolers?
To me, they don''t sound like either group. Rather, they''re simply perfectly
normal C programmers who haven''t yet discovered comp.lang.c. There are
quite a few of them out there, you know.
One of the reasons for the incredible amount of defective software
today is the cowboy know-it-all attitude of far too many programmers.
Those who still see programming as an art and not as a science or
engineering discipline might be beyond help.
I''ll buy "and not", since I see it as an art /and/ a science /and/ a craft.
--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
这篇关于[也许OT]如何让人们相信ANSI标准一致性的重要性？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
