在.h中定义setter和getter使代码或多或少可读

我通常喜欢在.h中定义getter和setter，而不是.cpp，因为我认为.cpp通常比.h有更多的代码，所以我想平衡.h和.cpp.中的代码数量

有什么具体的理由这样做吗？你必须在应该的地方编写代码，而不是根据平衡的（有问题的）美感。此外，一个非常短且大量使用的头文件和一个长的编译单元可能会导致总编译时间减少。

此外，我认为getter和setter的更改频率低于其他函数。

如果头包含在许多其他编译单元中，那么减少编译时间是有意义的。但是不要滥用这一点，编译时间很重要，但代码可读性更高。只有当你使用的是一台非常旧的电脑或正在进行一个巨大的项目时，才需要担心这一点。

我通常将getter和setter标记为"inline"，但不是出于性能目的：只使用"inline（内联）"作为getter和seter的标记，当我看到"inline）"时，我可以很快知道它是getter或setter方法。因此，我将阻止"内联"其他方法，因为"内联"只是用作将getter和setter与其他方法分离的标记。

绝对糟糕！inline是给编译器一个内联该方法的提示，不要把它用于其他事情！您会使用（让我们想象一下）volatile来突出显示仅在const函数中使用的变量吗？使用语言结构来达到目的。总是

但过了一段时间，我发现似乎没有人会把getter和setter放在.h.中

有任何证据吗？

此外，内联getter和setter似乎并不常见。

也许不是显式的（因为现在inline对其他程序员来说更像是一个提示，而不是编译器），但它们是内联的好候选者，因为它们通常很简单，调用开销高于它们执行的代码。不要担心你把它们放在哪里，如果compiled检测到它会提高你的代码性能（速度或内存占用），它会在没有你帮助的情况下使它们内联（但你可能会强迫它这样做，或者不使用一些特定于供应商的扩展）。

这个习惯真的会提高可读性吗？还是只会导致代码不那么容易理解和合理？

在我看来（我把这个答案标记为社区维基），这是一个坏习惯，因为除了你，没有人会理解你的推理。令人惊讶的是：如果我看到一个明确标记为inline的方法，我希望它是一个性能关键的方法（inline让它变得明显），而令人惊讶的代码是容易出错的代码。

我特别反对内联用来标记getter/setter方法，选择一个好的编码约定并使其成为您的。它会随着你自己（或你的公司）的编码风格和你的经验而发展，但在你第一次掌握现有的东西之前，不要重新发明轮子。。。

1. 您可以在.h文件中定义它，如果它们很短，这并不意味着代码的可读性。int getX（）const｛return _x；｝如果这些函数很复杂，也许你应该避免
2. setter通常更复杂，这就是为什么您应该移动到.cpp文件
3. 关于内联：
   • 在开发的优化步骤之前不要在意它
   • .h中的函数不会自动内联，甚至内联单词也只是编译器的建议。（不同的编译器有__force_inline字）
4. 你应该阅读一些代码风格，例如谷歌C++代码风格或其他一些风格，并在那里获取一些规则

类定义inline中定义的标记函数是多余的，因为这些函数在默认情况下都是内联的。

只有在头文件中定义了类外的函数时，该定义才应标记为inline。

此外，在类定义中定义getter和setter等简单的单行函数也是很常见的，不用担心。只需自动将所有单行函数放在那里，这是常见的做法。

您可以从它们的get或set前缀以及它们的定义很短这一事实中快速看出哪些是getter和setter。这也可能有助于他们在身体上聚在一起。

1. 虽然将getter和setter放在头文件中很常见，但我认为这不是一个好的做法。如果您需要更改这些函数，或者它们需要变得比单行函数更复杂，那么使用该标头的所有编译单元都需要重新编译。只需制定一条规则，即只有.cpp文件中的函数定义，如果您担心编译器将不再内联它们，则在启用LTCG或LTO的情况下进行编译。

2. 尽管从历史上看，inline关键字可能是编译器内联函数体的提示，但据我所知，所有现代编译器在决定如何最佳优化时都会忽略它。它唯一的现代用法是声明一个内联函数，该函数可以存在于多个编译单元中，而不违反一个定义规则。这是一个链接概念，与内联函数的概念是分开的，尽管考虑到过去多次使用关键字，这种混淆是可以理解的。类或结构定义中声明的所有函数都是隐式内联函数，因此不需要显式使用inline关键字。