使用空格,制表符以及多少个空格或制表符宽度缩进

Question

我知道这更像是一种编码风格,而不是一种正确的做事方式.但是,如果我遇到不同的缩进格式,我会感到有点沮丧.

但是,我想听听各方就这些问题的原因:

• 你使用空格或标签吗？带空格的标签？"Tab insert space"有什么不同,而不是直接使用空格键？
• 每行代码缩进多少个空格？为什么？
• 不同的代码有不同的风格,更适合他们每个人？

有没有办法"视觉"缩进代码而不实际写缩进？那么它不会破坏原来的缩进吗？似乎不太可能.

我正在使用Xcode,所以如果您对Xcode项目有建议,那就更好了.

Answer 1

如果要修改现有项目,则应始终使用项目已在使用的编码样式.

话虽这么说,如果您能够为新项目选择自己的编码样式,我建议您使用制表符来缩进代码而不是空格 - 这就是原因.通过使用空格,您可以强制所有其他在项目上工作的开发人员符合您的缩进首选项,无论是2个空格还是4个或8个(或其他).但是通过使用标签,每个开发人员都可以使用自己的偏好查看代码.您应该使用空格而不是制表符来格式化文本(将每行一个变量名称排成一行,或排列多行注释),因为这将适用于任何制表符宽度首选项.但是,当您缩进代码时,使用制表符而不是空格.简而言之,缩进与制表符,因为缩进空格是粗鲁的.

Answer 2

• 空间,因为它们在任何地方呈现相同
• indent-width与上下文有关.失控的缩进很糟糕.通常,您无法通过命名的抽象项(函数或方法)轻松地将缩进重置为理智级别的语言需要缩小缩进.
• 是的,见前面的子弹

标签允许各个开发人员使用不同标签宽度的说法是错误的.考虑

typedef __LA_SSIZE_T archive_write_callback(struct archive *,
                                            void *_client_data,
                                            const void *_buffer,
                                            size_t _length);

如果这是使用tabwidth为2生成的,它看起来像tabwidth = 4:

typedef __LA_SSIZE_T archive_write_callback(struct archive *,
                                                                                        void *_client_data,
                                                                                        const void *_buffer,
                                                                                        size_t _length);

相反,如果它是使用tabwidth = 8生成并以tabwidth = 4显示,则结果为

typedef __LA_SSIZE_T archive_write_callback(struct archive *,
                        void *_client_data,
                        const void *_buffer,
                        size_t _length);

因此,如果项目样式指南需要选项卡并且说功能参数需要与第一个代码显示中的对齐,那么只有一个正确的选项卡宽度.

(另一个答案提出了相同的论点.)

一个早该进行的编辑:

我全心全意地同意接受的答案的开头句,即

如果要修改现有项目,则应始终使用项目已在使用的编码样式.

其余的答案是,对不起,垃圾,我试图解释为什么上面.

压痕风格的问题应该只在任何项目开始时出现,一旦它完成了它就完成了.我确实认为空格比标签更好,并且(再次,我相信)支持我的立场的理性论据等等,但我不会开始讨论这个主题因为它们没用:我认识的大多数程序员用非理性的论证支持他们的偏好,其余的已经确定了一种最适合他们工具的风格(比如我:"因为它们在任何地方呈现相同的空间"),我一般都没有影响力.

趣闻:我曾经在其经受换行符的变化,从一个项目\r\n到\n,而且竟然是在屁股我们需要走过去在修订任何时候疼痛svn blame. s/newlines/indentation/,你有一个很好的论据反对正在运行的项目中的大量缩进更改.