具有不带扩展名的C ++头文件是一种好习惯吗?


9

关于我要遵循的C ++准则,我和我的一位同事争论不休。

他目前以这种方式设计他的所有库:

  • 他在文件名中使用大小写不一致的字母
  • 他的某些标题没有任何扩展名

我相信没有扩展名是C ++标准文件所保留的东西,并且使用大写字母容易出错(尤其是当您处理要在Windows和Linux上都可以使用的代码时)。

他的观点是,他遵循Qt惯例(即使对于不使用Qt的代码),并一直说:“如果Qt那样做,那就不错了。”

现在,我尝试保持开放的态度,但是当我不得不使用他的库时,我真的很难过。是否有一套与此相关的通用规则?标准是否说明了这一点?

非常感谢你。


3
#define signal……(“如果Qt那样做,那就不错了。”)-我不能说我个人同意他们所有的设计选择。
贾斯汀2012年

@贾斯汀:我也不。我没有反对Qt。我什至认为这是一个了不起的库,但是他们的某些设计选择对我来说真的很不对。
ereOn 2012年

1
@Justin我已经看到宏是从_流行的,广泛使用的代码开始的,但是它完全违反了标准。
Luchian Grigore'2

1
但这是避免没有扩展头的真正原因之一:我的主IDE和文本编辑器不会自动识别它们。我只使用*.hpp一个c ++头文件,而我所有的工具都“得到它”。
贾斯汀2012年

5
Qt 之所以使用该约定,恰恰是因为聪明的程序员没有这么做。这意味着您的标头不会与新的Qt标头冲突。
MSalters

Answers:


16

据我所知,扩展名(或缺少名)不会引起您的问题。我要说的是,完全删除扩展名是很不方便的,因为这会使搜索头文件变得困难(例如,使用通配符* .h和* .hpp),并且使识别文件的内容更加困难(例如您的编辑器依靠扩展名来选择适当的语法突出显示模式)。

从代码的角度来看,只要您在所有地方使用一致的大小写并且不仅仅依靠大小写差异来区分文件,即使大小写也不会有太大问题。从方便的角度来看,更容易坚持使用小写字母并具有扩展名(.h或.hpp)。

然而,更重要的是,为整个开发团队选择一个约定并坚持下去。更糟糕的是,每当您要包含某些内容时,必须查找文件的大小写,命名方式以及使用的扩展名-所有这些都应该在您尝试使用的内容的知识下是“可猜测的”。


选择一个约定并坚持下去不是一个坏主意,但是如果可以改善现有约定呢?在这种情况下,改变路线也许是个好主意。
kotlinski

@kotlinski这是您无能为力的情况下的其中一种情况,因为您选择的任何东西都是偏好问题。我想说,实际上,扩展名总比没有好,因为操作系统(读取的Windows)可以根据扩展名确定使用哪个程序打开文件。
保罗

@PaulManta:但是,您不是在这里反对自己吗?首先,您说没有任何办法可以改善。然后,您说拥有扩展总比没有好。这是一种失败主义态度,说不可能改变。
kotlinski '02

@kotlinski通常,我想这取决于您要处理多少旧代码,将所有代码更改为新约定是否可行以及混合约定的影响。在这种情况下,尽管我同意Paul Manta的意见,但这主要是个人喜好,出于实际原因,大多数人都喜欢使用扩展名。
亚当·鲍恩

1
@kotlinski没有任何方法可以改善任何情况,但是有一些方法可以使情况变得更糟。该讨论与spaces-vs-tabs讨论一样没有意义。只需选择一项约定,然后做一些有用的事情即可。
保罗

6

(在标准中)没有规则,只有标准头文件可以没有扩展名。文件名可以是您想要的任何东西。但是,一般的良好做法建议:

  1. 没有文件没有扩展名,并且

  2. 不同类型的文件具有不同的扩展名-特别是C ++标头使用的扩展名(.hpp.hh)与C编译器可接受的标头不同。

(遗憾的是,经常违反第二条规则,并且经常看到C ++头文件带有.h。根据个人经验,我可以确保这会在以后引起维护问题,但这是常见的做法。)

关于大小写,需要格外小心,因为文件名在某些系统中区分大小写,而在其他系统中则不区分大小写。我看到了两个不同的规则都起作用:文件名中的所有小写字母,或文件名遵循与C ++中符号大小写完全相同的规则。

在这两种情况下,您都要以协商一致的方式为项目建立规则,并且每个人都应遵循它们。


1
我完全支持詹姆斯。如果扩展名相同,则使工具无法在2种不同的头文件上正常工作就成了噩梦。

@TomTanner如果文件没有扩展名,那就更糟了。我主要在Unix环境中工作,而可执行文件没有扩展名总是让我感到沮丧(并引起了问题)。

6
If Qt does it that way, then it can't be bad.

是。是的,确实可以。他们的库设计是“我们非常想成为Java”。真是一团糟。标准库要好得多。

而且,从根本上讲,这是一个逻辑谬误。Qt的设计仅是值得您效仿的逻辑原因,因为它是Qt,所以不好。


这是一个经验论证。这是一个被许多人使用的大型软件产品。如果这种命名约定的选择引起了严重的问题,那么它就会为人所知,并且现在可能已经改变。因为不是这种情况,所以它不会太糟。但是,这并不意味着它是最佳解决方案。
H. Rittich

0

据我所知,自1998年标准以来,只有标准库头文件才没有.h。因此,非标准C ++头文件通常仍以.h编写。但是请记住,这是一个约定,您不能使用任何扩展名,甚至不能使用.txt扩展名,就像您以小写字母开始编写类一样,它仍然可以工作,但这不是约定。


3
顺便说一句,“如果Qt那样做,那就不错了。” 这是一个非常糟糕的论点……

2
对于用户定义的标头应如何命名,该标准无话可说。它仅指定标准标头的名称。
Mike Seymour 2012年

0

这些是惯例,不是规则,没有遵守惯例的约束,但是当您到处参考时,惯例确实使生活变得更轻松。

根据扩展名(.h,.hpp),包含在c ++中的那些文件不需要扩展名,如果您使用的不是c ++的标头(例如c库或boost库),则需要使用扩展名。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.