PROS / CONS：#define BEGIN { [英] PROS/CONS: #define BEGIN {
问题描述
我的同事提议我们使用一组预处理器
定义来使我们的C代码更具可读性：
#define BEGIN {
#define ENG}
#define EQ ==
等
我最初的反应是"呸"！; （与常见问题解答没有什么不同，只是
说Bleah）。
除此之外，有什么理由可以做到这一点，或者不这样做？
我提出的一些消极因素包括：
*不能使用某些工具，例如
- 语法识别编辑器
- 指标
- 静态分析工具
- 编码风格执行
- 代码压头/重新格式化器
- 漂亮的打印机
*不检查不匹配（例如，{对比END ）。
*不妨碍使用{，}，==等，只是添加替代品。
*需要重新使用培训习惯于标准C语法的C开发人员。
A colleague of mine is proposing that we use a set of preprocessor
definitions to make our C code more readable:
#define BEGIN {
#define ENG }
#define EQ ==
etc.
My initial reaction is "Yuck!" (Not too different from the FAQ, which just
says "Bleah").
Aside from that, what are some good reasons to do this, or not to do this?
A few negatives I come up with include:
* Won''t work with some tools, such as
- syntax-aware editors
- metrics
- static analysis tools
- coding style enforcement
- code indenters/reformatters
- pretty printers
* Does not check for mismatches (e.g., "{" vs. "END").
* Does not prevent use of {, }, ==, etc., just adds alternatives.
* Requires re-training of C developers who are used to standard C syntax.
推荐答案
Mike Malone写道：
Mike Malone wrote:
A我的同事建议我们使用一组预处理器定义来使我们的C代码更具可读性：
#define BEGIN {
#define END}
#define EQ ==
我最初的反应是哎呀！
（与FAQ之间没有什么不同，常见问题解答只是说Bleah。
除此之外，有什么理由可以做到这一点，或者不这样做？
一些消极的我想出了包括：
*不能使用某些工具，例如
- 语法感知编辑器
- 指标
- 静态分析工具<编码风格执行
- 代码压头/重新格式化工具
- 漂亮的打印机
*不检查不匹配（例如，{与结束相比。
*不妨碍使用{，}，==等，只是添加替代品。
*需要重新培训习惯于标准C语法的C开发人员。
A colleague of mine is proposing that we use a set of preprocessor
definitions to make our C code more readable:
#define BEGIN {
#define END }
#define EQ ==
etc.
My initial reaction is "Yuck!"
(Not too different from the FAQ, which just says "Bleah").
Aside from that, what are some good reasons to do this, or not to do this?
A few negatives I come up with include:
* Won''t work with some tools, such as
- syntax-aware editors
- metrics
- static analysis tools
- coding style enforcement
- code indenters/reformatters
- pretty printers
* Does not check for mismatches (e.g., "{" vs. "END").
* Does not prevent use of {, }, ==, etc., just adds alternatives.
* Requires re-training of C developers who are used to standard C syntax.
为什么不使用sed脚本来修改你的一些代码
看看你喜欢它吗？
需要一段时间才能适应它
你将不得不投入一些时间
来调整你的工具来使用
但是，最后，你会发现
的人可以习惯几乎任何东西
并且他们实际上非常喜欢这些东西。
但是，一般来说，我认为这不是一个好主意
不必要地混淆你的宏命名空间。
我相信编码风格强制执行
是恶作剧的来源和这类问题
应该留给个别程序员。
Why don''t you use a sed script to modify some of your code
and see how you like it?
It takes a while to get used to it
and you will be obliged to invest some time
to adjust your tools to work with it
but, in the end, you will find that
people can get used to just about anything
and that they actually become quite fond of these things.
But, generally, I don''t think that it''s a good idea
to clutter up your macro namespace unnecessarily.
I believe that "coding style enforcement"
is a source of mischief and such issues
should be left up to the individual programmer.
& 麦克马龙 < mr*@prodigy.net>写道：
"Mike Malone" <mr*@prodigy.net> writes:
我的一位同事建议我们使用一组预处理器定义来使我们的C代码更具可读性：
#define开始{
#define ENG}
#define EQ ==
A colleague of mine is proposing that we use a set of preprocessor
definitions to make our C code more readable:
#define BEGIN {
#define ENG }
#define EQ ==
第三个类似于iso646.h中给出的等价物：
和&&
and_eq& =
bitand&
bitor |
compl~
不是！
not_eq！=
或||
or_eq | =
xor ^
xor_eq ^ =
我不知道这是支持还是反对的论据。
-
只是另一个C黑客。
The third is similar to the equivalents given in iso646.h:
and &&
and_eq &=
bitand &
bitor |
compl ~
not !
not_eq !=
or ||
or_eq |=
xor ^
xor_eq ^=
I don''t know whether that''s an argument for or against.
--
Just another C hacker.
Pro - 更少的嵌套错误......
" Mike Malone" < mr*@prodigy.net>写道：
Pro - fewer nesting errors...
"Mike Malone" <mr*@prodigy.net> writes:
我的一位同事建议我们使用一组预处理器定义来使我们的C代码更具可读性：
#define BEGIN {
#define ENG}
#define EQ ==
等等。
我最初的反应是哎呀！ （与常见问题解答没有什么不同，只是
说Bleah）。
除此之外，有什么理由可以做到这一点，或者不这样做？
我想出的一些消极因素包括：
*不能使用某些工具，例如
- 语法识别编辑器
- 指标
- 静态分析工具
- 编码风格执行
- 代码压缩器/重新格式化器
- 漂亮的打印机
*不检查不匹配（例如，{与END相比）。
*不阻止使用{，}，==等，只是添加替代品。
*需要重新培训习惯于标准C语法的C开发人员。
A colleague of mine is proposing that we use a set of preprocessor
definitions to make our C code more readable: #define BEGIN {
#define ENG }
#define EQ ==
etc. My initial reaction is "Yuck!" (Not too different from the FAQ, which just
says "Bleah"). Aside from that, what are some good reasons to do this, or not to do this?
A few negatives I come up with include: * Won''t work with some tools, such as
- syntax-aware editors
- metrics
- static analysis tools
- coding style enforcement
- code indenters/reformatters
- pretty printers * Does not check for mismatches (e.g., "{" vs. "END"). * Does not prevent use of {, }, ==, etc., just adds alternatives. * Requires re-training of C developers who are used to standard C syntax.
这篇关于PROS / CONS：#define BEGIN {的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
