Re：重新格式化为符合工具/编辑器的C风格？ [英] Re: reformat to tool/editor-compliant C style?
问题描述
7月4日15:26，Hallvard B Furuseth< hbfurus ... @ usit.uio.nowrote：
On 4 Jul, 15:26, Hallvard B Furuseth <h.b.furus...@usit.uio.nowrote:
我想要将开源软件包（OpenLDAP）重新格式化为新的C风格。
8M代码，0.3M行。目前还有一些无望的格式化规则，比如
tab-width = 4。
I''d like to reformat an open source package (OpenLDAP) to a new C style.
8M code, 0.3M lines. With some currently hopeless formatting rules like
tab-width=4.
这有什么问题？！
what''s wrong with that?!
我很有信心有意义的一次为
源代码节省磁盘空间，或者其他东西:-(
I''m sure that made sense once to save disk space for the
source code, or something:-(
不会用标签替换空格这样做了吗？这些磁盘是不是很小？我曾经在旧的迷你电脑上工作过，甚至还没有b $ b，那么我们并没有尝试节省空间* source * level。
wouldn''t replacing spaces with tabs do that? Were disks ever
*that* small? I''ve worked on old mini-computers and even
then we didn''t try to save space at the *source* level.
项目的正常规则是不要b $ b不必要地重新格式化，因为它使得源代码控制合并/差异
难度。
The project''s normal rule is "don''t
reformat unnecessarily" since it makes source control merge/diff
difficult.
使用合适的配置控制系统并确保
你不要不要将源代码更改与重新格式混合。显式标记
重新格式化版本。
无法帮助您缩进
< snip>
-
Nick Keighley
use a decent configuration control system and make sure
you don''t mix source code changes with reformats. Clearly label
the reformat versions.
can''t help you with indent
<snip>
--
Nick Keighley
推荐答案
Nick Keighley写道：
Nick Keighley writes:
7月4日15:26，Hallvard B Furuseth< hbfurus ... @ usit.uio.nowrote：
On 4 Jul, 15:26, Hallvard B Furuseth <h.b.furus...@usit.uio.nowrote:
>我想将开源软件包（OpenLDAP）重新格式化为新的C风格。 /> 8M代码，0.3M线。有一些目前无望的格式规则，如
tab-width = 4。
>I''d like to reformat an open source package (OpenLDAP) to a new C style.
8M code, 0.3M lines. With some currently hopeless formatting rules like
tab-width=4.
这有什么问题？！
what''s wrong with that?!
选项卡宽度8是其他地方的标准，至少在Unix世界中并且使用
发布的ASCII文本。所以一些代码用tab-width 4编写，一些
with 8.即使每个人都设置了indentation = tab-width，代码仍会得到
错位。这是用tab-width 4（我已经替换过的空格）写的：
int foo; / *你好* /
const char * barbaz [256]; / *和这里* /
在显示标签宽度为8时变为此：
int foo; / *你好* /
const char * barbaz [256]; / *和这里* /
Tab width 8 is the norm elsewhere, at least in the Unix world and with
published ASCII text. So some code gets written with tab-width 4, some
with 8. Even if everyone sets indentation = tab-width, code still gets
misaligned. This written with tab-width 4 (I''ve substituted spaces):
int foo; /* hi there */
const char *barbaz[256]; /* and here */
becomes this when displayed with tab-width 8:
int foo; /* hi there */
const char *barbaz[256]; /* and here */
>我确定一次有意义为
源代码，或者其他东西:-(
>I''m sure that made sense once to save disk space for the
source code, or something:-(
不会用标签替换空格吗？
wouldn''t replacing spaces with tabs do that?
如果标签宽度缩进级别没有。（例如8和4）。
Not if tab width indentation level. (e.g. 8 and 4).
磁盘是否*那么小？我曾经在旧的迷你电脑上工作过并且
即使那时我们也没有尝试在* source *级别节省空间。
Were disks ever *that* small? I''ve worked on old mini-computers and
even then we didn''t try to save space at the *source* level.
谁知道。如果重点是为了节省空间，我根本不知道
重点是什么。
Who knows. If the point was not to save space, I have no idea at all
what the point was.
>该项目的正常规则是不要不必要地重新格式化，因为它使源控制合并/差异变得困难。
>The project''s normal rule is "don''t reformat unnecessarily" since it
makes source control merge/diff difficult.
使用一个体面的配置控制系统，并确保
你不要将源代码更改与重新格式混合。显然标记
重新格式化版本。
use a decent configuration control system and make sure
you don''t mix source code changes with reformats. Clearly label
the reformat versions.
其实我不确定配置控制系统是什么，而不是源代码控制的
。这个项目仍然在使用CVS，我不会去讨论这个问题。在任何情况下，重新格式化的改变都将不会注意不要重新格式化。规则:-)
-
Hallvard
Actually I''m not sure what a configuration control system is, as opposed
to source control. This project is still using CVS, and I''m not going
to fight about that. In any case the reformatting changes will
certainly not pay attention to the "don''t reformat" rule:-)
--
Hallvard
Hallvard B Furuseth schrieb：
Hallvard B Furuseth schrieb:
谁知道。如果不是为了节省空间，我根本不知道这是什么意思。
Who knows. If the point was not to save space, I have no idea at all
what the point was.
使用标签的重点是每个人都可以轻松转换为
方便的东西。我发现4个空间的值是完美的，有些人更喜欢2个，有些人更喜欢8个b $ b更喜欢8.我也看过3.
你建议你切换在我看来8个空格（即没有标签）
就像一个非常好的主意。毕竟每个人都应该能够以他/她想要的方式显示它 - 而不是程序员喜欢的方式。
代码缩进空格是一种烦人的害虫，恕我直言。
问候，
约翰内斯
-
" Wer etwas kritisiert muss es noch lange nicht selber besser k？nnen。 Es
reicht zu wissen，da？ andere es besser k？nnen und andere es auch
besser machen um einen Vergleich zu bringen。 - Wolfgang Gerber
in de.sci.electronics< 47 *********************** @ news.freenet.de>
The point of using tabs is that everyone can easily convert to something
convenient. I find a value of 4 spaces perfect, some prefer 2, some
prefer 8. I''ve also seen 3.
You suggest that you switch to 8 spaces (i.e. no tabs) which seems to me
like a really not that good idea. After all everyone should be able to
display it the way he/she wants - not the way the programmer liked it.
Code indented by spaces is an annoying pest, IMHO.
Regards,
Johannes
--
"Wer etwas kritisiert muss es noch lange nicht selber besser k?nnen. Es
reicht zu wissen, da? andere es besser k?nnen und andere es auch
besser machen um einen Vergleich zu bringen." - Wolfgang Gerber
in de.sci.electronics <47***********************@news.freenet.de>
你建议你切换到8个空格（即没有标签）在我看来
就像一个非常好的主意。毕竟每个人都应该能够以他/她想要的方式显示它 - 而不是程序员喜欢的方式。
代码缩进空格是一种烦人的害虫，恕我直言。
You suggest that you switch to 8 spaces (i.e. no tabs) which seems to me
like a really not that good idea. After all everyone should be able to
display it the way he/she wants - not the way the programmer liked it.
Code indented by spaces is an annoying pest, IMHO.
如果你想因任何原因保持垂直对齐，那么
你必须使用空格。
当然在源代码中有垂直对齐是一个问题
个人品味
减少缩进（制表符）大小会增加嵌套块的数量
不需要换行，或允许使用更长的变量
名称。
增加缩进尺寸可降低风险垂直对齐
如果标签尺寸改变可能会令人不安，因为可能只需要一个标签
需要保持对齐
If you wish to maintain vertical aligment for whatever reason, then
you have to use spaces.
Of course having vertical alignment in source code is a matter of
personal taste
Reducing indent (tab) size increases the number of nested blocks that
dont require line wrapping, or allows the use of longer variable
names.
Increasing the indent size reduces the risk of vertical alignment
being upset if the tab size is changed as possibly only a single tab
is required to maintain alignment
这篇关于Re：重新格式化为符合工具/编辑器的C风格？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
