Rob Pike的简单包含规则 [英] Rob Pike's simple Include rule
问题描述
在Rob Pike的风格指南中，他提出以下建议：
简单规则：包含文件绝不应包含
文件。相反，他们说（在评论中或隐含地）
他们需要首先包含哪些文件，
决定要包含哪些文件的问题推送给用户
（程序员）但是以一种易于处理的方式，
通过施工，避免多次包含。
我对这条指南感到震惊，因为它并不是我想象的那样
作为通常的做法，即通过
标题保护标题中的暴力幂等性。
我对这个建议有三个问题，对于那些使用
类似风格的人：
1遵循本指南是轻而易举还是麻烦？我将
简单的双头程序转换为这种样式，在此过程中产生了几个
错误。我显然没有经验
用它。
2.标题如何隐含地显示它需要什么
标头？我认为他的意思是你通过读取头文件来获取这些信息，但是我想确保我不会错过
一些有趣的东西。
它似乎是一个很好的自动化候选者。
-
Neil Cerutti
" ;你想看到他们吗？
"看什么？"
"尸体。他们在地下室。 --_活死人员的回归_
In Rob Pike''s style guide he urges the following:
Simple rule: include files should never include include
files. If instead they state (in comments or implicitly)
what files they need to have included first, the problem of
deciding which files to include is pushed to the user
(programmer) but in a way that''s easy to handle and that,
by construction, avoids multiple inclusions.
I was startled by this guideline, since it''s not what I think of
as the usual practice, i.e., brute-force idempotency through
header guards in the headers.
I have three questions about this advice, for those who use a
similar style:
1. Is following this guideline facile or hassle? I converted a
simple two-header program over to this style, making several
errors along the way. I clearly don''t have experience
with it.
2. How does a header state implicitly what it requires for
headers? I assume he means that you gleen this information by
reading the header file, but I want to make sure I''m not missing
something interesting.
It seems like a good candidate for automation.
--
Neil Cerutti
"Do you wanna see ''em?"
"See what?"
"The corpses. They''re in the basement." --_Return of the Living Dead_.
推荐答案
Neil Cerutti写道：
Neil Cerutti wrote:
简单规则：包含文件永远不应包含
文件。
遵循本指南轻松还是麻烦？
Simple rule: include files should never include include
files.
Is following this guideline facile or hassle?
绝对麻烦，唯一真正的好处就是避免污染
命名空间;所引用的好处（防止多重包含）确实无关紧要，因为您可以使用一些预处理器
指令完成它，如您所述。
对于真正的问题（命名空间污染），应该记录每个包含哪个
标题。
-
++ acr @，ka"
Definitely a hassle, and the only real gain is to avoid polluting the
namespace; the quoted benefit (prevention of multiple inclusion) does
not matter one whit, as you can accomplish it with some pre-processor
directives, as you note.
For the real problem (namespace pollution), one should document which
headers are included by each.
--
++acr@,ka"
2004年4月22日18:52:12 GMT，Neil Cerutti< ho **** *@yahoo.com>写道：
On 22 Apr 2004 18:52:12 GMT, Neil Cerutti <ho*****@yahoo.com> wrote:
在Rob Pike的风格指南中，他提出以下建议：
简单规则：包含文件绝不应包括包含
文件。如果相反他们说（在评论中或隐含地）
他们需要首先包含哪些文件，
决定包含哪些文件的问题被推送给用户
（程序员）但是在这种方法很容易处理，而且，通过构造，可以避免多次包含。
我被这条指南吓了一跳，因为它不是我想到的
通常的做法，即通过标题中的标题守卫进行强力幂等性。
FWIW，我在这个问题上不同意Rob Pike。我相信包含
文件应该包含它自己需要的任何其他标头。但是，
它不应该包括任何其他人。在第一次编译之后发现
一些头文件需要在其前面包含另一个标题是
诅咒作者的合法理由。
我有三个问题关于这个建议，对于那些使用类似风格的人来说：
1。遵循本指南是轻而易举还是麻烦？我将一个简单的双头程序转换为这种样式，在此过程中出现了几个错误。我显然没有经验
。
2。标题如何隐含地表明
标题需要什么？我认为他意味着你通过阅读头文件来收集这些信息，但我想确保我不会错过
一些有趣的东西。
这似乎是一个自动化的良好候选人。
In Rob Pike''s style guide he urges the following:
Simple rule: include files should never include include
files. If instead they state (in comments or implicitly)
what files they need to have included first, the problem of
deciding which files to include is pushed to the user
(programmer) but in a way that''s easy to handle and that,
by construction, avoids multiple inclusions.
I was startled by this guideline, since it''s not what I think of
as the usual practice, i.e., brute-force idempotency through
header guards in the headers.
FWIW, I disagree with Rob Pike on this issue. I believe an include
file should include whatever other headers it itself needs. However,
it shouldn''t include any others. Finding after the first compile that
some header file needed another header included in front of it is
legitimate grounds for cursing the author.
I have three questions about this advice, for those who use a
similar style:
1. Is following this guideline facile or hassle? I converted a
simple two-header program over to this style, making several
errors along the way. I clearly don''t have experience
with it.
2. How does a header state implicitly what it requires for
headers? I assume he means that you gleen this information by
reading the header file, but I want to make sure I''m not missing
something interesting.
It seems like a good candidate for automation.
第三个问题是什么？ :-)
-
Al Balmer
Balmer Consulting
再******************** ****@att.net
" Neil Cerutti" <豪***** @ yahoo.com>在留言中写道
news：c6 ************ @ ID-60390.news.uni-berlin.de ...
"Neil Cerutti" <ho*****@yahoo.com> wrote in message
news:c6************@ID-60390.news.uni-berlin.de...
In Rob Pike的风格指南他敦促以下内容：
简单的规则：包含文件永远不应包括包含
文件。如果相反他们说（在评论中或隐含地）
他们需要首先包含哪些文件，
决定包含哪些文件的问题被推送给用户
（程序员）但是在这种方法很容易处理，而且，通过构造，可以避免多次包含。
我被这条指南吓了一跳，因为它不是我想到的
通常的做法，即通过标题中的标题守卫进行蛮力幂等。
In Rob Pike''s style guide he urges the following:
Simple rule: include files should never include include
files. If instead they state (in comments or implicitly)
what files they need to have included first, the problem of
deciding which files to include is pushed to the user
(programmer) but in a way that''s easy to handle and that,
by construction, avoids multiple inclusions.
I was startled by this guideline, since it''s not what I think of
as the usual practice, i.e., brute-force idempotency through
header guards in the headers.
标题保护是便宜的，不需要额外的使用您的库的
程序员保持警惕。我已经参与了几个开源项目
其中包含依赖项是一个噩梦，直到我添加了标题保护
所有文件和只是暴力包含的东西根据需要在标题中。
什么是反头套保护不是最有效的
解决方案？
S
-
Stephen Sprunk愚蠢的人用智能环绕自己
CCIE＃3723人。聪明的人围绕着他们自己与他们不同意的K5SSS聪明人。 --Aaron Sorkin
Header guards are cheap and don''t require extra vigilance on the part of the
programmer using your library. I''ve worked on a couple open-source projects
where include dependencies were a nightmare until I added header guards to
all the files and just brute-force included things in headers as needed.
What are the counter-cases where header guards are NOT the most efficient
solution?
S
--
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin
这篇关于Rob Pike的简单包含规则的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
