使用 #include 包含代码段

Question

我正在使用一个 3rd 方开源应用程序，它做了一些我认为很奇怪的事情。 我想听听你的意见，你是否认为这是错误的/邪恶的/令人憎恶的/等等，或者是否有一些正当的理由这样做。

简而言之，他们使用#include pre-proc 指令来包含包含代码片段的“头文件”。 不是函数原型。 不是内联函数。 只是代码部分。

这是一个简单的例子。 首先是 main.cpp 文件：

#include <iostream>
//Other "normal" includes here...

int main(int argc, char *argv[]) {

  cout << "Initializing program..." << endl;
  #include "parseArgs.h"

  // ... remainder of the program

  cout << "Exiting." << endl;
  return 0;
}

在 parseArgs.h 头文件中，有一小段代码。 请注意，这仅是 parseArgs.h 文件中的内容。 这不是函数的一部分。 没有包含守卫，只有以下 4 行：

argList args(argc, argv);
if(!args.valid()) {
  cout << "Invalid arguments.";
  exit(1);
}

在实际程序中，有几个这样的#include 指令，每个指令都执行另一项小任务。

这似乎是危险和疯狂的。 我不知道他们为什么不编写并将它们称为函数。

你的想法和意见？

Answer 1

我想你在这里谈论的是OpenFOAM 。 这些代码片段解决的问题是避免重复 OpenFOAM 中的许多应用程序所需的样板代码。 将此代码放在函数中并不能解决问题，因为在函数内部声明的变量在其作用域内是局部的。 或许可以想出一种包含这些变量作为成员的基类方案。 但这只会增加另一层不能真正解决任何问题的间接层。 你仍然依赖于变量名（或者，如果你想让它干净，getter-names）。

就个人而言，我不确定这种做法是好是坏。 它就是这样，它是 OpenFOAM 代码文化（或当地行话，如果你愿意）的一部分。 乍一看这很令人惊讶，但人们很快就习惯了。

但是，除非您自己开发 OpenFOAM 应用程序/扩展，否则我强烈反对这种做法。 OpenFOAM 有点独特，因为它包含几乎数百个可执行文件，所有这些都需要一些重叠的样板代码，否则很难维护。 如果你不是那种情况，那就不要这样做。

Answer 2

我会犹豫称它为“疯狂”，因为这种#include用法可能是有原因的。 问题在于理解这些原因并判断这是否是给定上下文中的最佳方法。 对我之所以能想象就是，该代码在某些方面，而不是手写的产生。

OTOH 它确实看起来很奇怪，它确实有一定的代码气味。 我也很想知道究竟是什么原因，如果结果证明没有或错误的原因，它是重构的一个很好的候选者。

Answer 3

我认为这是非常混乱的，你会更好地编写一个函数。

这是我在 SO 上发现的一个问题，询问“为什么在 C++ 中包含两次头文件是有效的？” 您可能会发现答案很有趣，我永远不会以这种方式编写我的代码，因为我认为修复错误和任何其他问题将是痛苦且耗时的

Answer 4

我不会称这种事情为“疯狂”——我会使用“不寻常”、“难以理解”、“意外”等术语，因此“难以阅读、调试和维护”。 或者只是“WTF”——降低代码质量。

永远不要那样做。 使用函数。 或者，如果真的，真的必须，使用一个功能完全相同但人们更熟悉的宏。 是的，宏很糟糕，在调试时可能会成为一个坑。 但这更糟。

编辑：澄清：我不喜欢宏。 我尽可能避免它们。 大多。 使用函数、模板等等。 但是当涉及到“宏或 WTF- #include ”时，请使用宏。

Answer 5

如果您在团队中工作，则需要建立程序和标准以确保沟通顺畅。 一旦解决了，你说葡萄牙语或普通话都没有关系，只要每个人都觉得舒服就行。

这是心态问题。 有些人——包括和我一起工作的老师——被规则奴役； 但是，我不能认真对待它们，特别是当其中一个为了教授面向对象而使用“生菜”和“水果”作为示例时。 我怀疑科尔伯格的阶段有点拖慢了一些人的思考速度。

我在个人项目中使用这种技术 - 包括 source.cpp。 我已经在 C 和 Lazarus (Pascal) 中完成了它，它比摆弄链接器参数和 makefile 更适合我的目的。 我的代码有注释，变量声明对齐，赋值运算符也对齐，当学生给我代码时，我会遍历所有代码，插入空格和行，直到它看起来像我喜欢的样子，然后再分析它。 我沉迷于干净的源代码组织。 你看？ 疯狂是有方法的！

工具（#include、#define、lambda...）就是：工具，当然，意外使用工具可能会让人迷失方向； 那不好。 更重要的是，当“软件的心理复杂性”（谷歌它）伤害（你或你团队中的某个人）时，立即停止并仔细研究出了什么问题。

那是我的2cts。