关于C++程序设计实践的几点看法

取决于这些函数有多大。如果源文件的长度开始超过几百行代码,则有理由将部分功能提取到一个(或多个)单独的文件中。

如果您可以根据函数的职责和/或抽象级别将函数分组为不同的集合,那么您可能更喜欢沿着这些行将它们划分为不同的物理文件(当然还有类)。例如,某些函数可以处理文件I/O,而其他函数则进行一些计算。或者一些函数在文件I/O中执行低级的位翻转任务,而另一些函数则在前者的基础上实现一些更抽象的功能。

划分代码的另一个原因是,如果一些函数被多个客户机使用,但这显然不适用于您的情况。(但是,如果你的应用程序在未来得到进一步开发和扩展,这可能会有所改变…)

根据代码的相似性,将代码分为不同的文件是很好的。如果你有多个类,你可以把它按类分解。如果您有几个可以在其他程序中使用的函数,为了便于移植,您应该将它们放在自己的文件中。

因为您只提到了函数,所以我假设您的程序不是面向对象的。如果是的话,我建议每个.h/.cpp对有一个类。在您的情况下,这取决于这些函数是否可以分组为2个或更多子集。如果是这样,我会将相关函数放在单独的.cpp模块中,并始终具有包含其原型的相应.h头。

在同一个模块中拥有这15个功能并不一定正确或不正确。同样,如果它们都是强相关的,那么它们应该属于同一个模块。另一个要决定的规则是模块大小本身。我发现很难管理一个已经增长到1000行以上的模块,这个阈值是一个警告信号,它应该被拆分。这两件事是相关的,通常当模块变得这么大的时候,它也可能有两个或更多不同的功能组。

假设每个函数都很小,那么在文件之间拆分它是没有意义的,IMO。

如果函数是几百行代码,那么最好将其拆分。主要是因为如果/当您扩展程序时,它会更容易。

我擅长在可能的情况下只使用头类。它的效率更高,因为编译器可以通过这种方式执行更多的优化,成本是编译时间更长。但是你也会有同样的好处,你的程序完全包含在一个源文件中。

但是,如果您打算重用代码,那么在逻辑单元之间拆分代码是明智的。类之间的系统拆分,不管依赖关系或逻辑单元,甚至可以被认为是一个坏的做法(嗯,在一些其他语言,如Java,你没有太多的选择……)。

如果你最终需要使用 CTRL+F 要找到您要查找的函数,可能是时候开始分解文件了。

同样,如果你需要使用 CTRL+F 要在一个长函数中找到某段代码,可能是时候将其分为多个函数(或者编写更简洁的代码)。

如果您必须花费大量的时间在代码中快速浏览,那么跟踪bug将变得更加困难(而且修复起来需要花费更多的时间)。

然而,每当你要分解文件或函数时,试着用有意义的方式将它们分开,不仅对你,而且对普通人也是如此。假设你是唯一会看你的代码的人是愚蠢的。如果你在离开几年后回到这个项目,你很可能是一个不同于你现在的人。

有人可能会假设较大的程序(如商业开发的程序)将其代码保存在多个文件中。你能想象一下那个文件的大小吗?将这种良好的实践扩展到小型项目也是一个好主意。

但就代码而言, 通常 在物理代码所在的位置没有任何区别,因为所有代码最终都位于同一个位置(共享库/dll或可执行文件)。

如果您觉得将在其他应用程序中重用代码的某个部分,那么将该部分拆分为不同的文件(头文件和实现)。

除此之外,我不介意。

M