问题标签 [google-style-guide]

Google Style Guide 说要始终使用local变量并将所有内容放入function.

另一方面，提供了示例 for循环：

为什么没有约定总是在循环之前将循环变量声明为本地变量？或者也许以下是应该如何编写函数内部的循环以符合样式指南的方式？

我目前正在使用 Sphinx 记录我的 Python 项目。在文档字符串的多行部分中包含项目符号列表时遇到了一个问题。

我想包括一个项目符号列表，但其中一个项目很长。我想：

• 通过 Sphinx 正确呈现项目符号列表
• 但也让我的代码尊重 PEP8 关于行长（<79）

你会建议我为这个文档字符串做什么：

最后一行超过 79 个字符。

然后通过 Sphinx 呈现评论。添加回车符只会破坏 Sphinx 中的项目符号列表。

如何更改 VSCode 中的语法突出显示以使其符合特定的样式指南？例如，我想遵守Google C++ 风格指南，其中成员变量写为some_member_variable_. 当我使用此约定时，VSCode 不会为该名称着色与标准文本不同。但是我有一些使用mSomeMemberVariable约定的代码，并且它的颜色确实与其他文本不同。有没有办法更好地配置它？

在Google Python Style Guide 的Imports Formatting部分中，关于特定于应用程序的导入的第四点被标记为在 Nov. 2018 中已弃用。本节中的示例没有提供足够的信息来理解应该用什么格式替换旧格式。指示为旧样式的行以注释和未注释格式出现！

以样式指南中的示例为例。

这两条线好不好？如果不是，应该用什么代替它们？

Google C++ 风格指南部分“其他 C++ 功能”包含以下内容：

除了样式指南的其余部分中描述的内容外，可能无法使用以下 C++ 功能：

• 编译时有理数 ( <ratio>)，因为担心它与更重模板的界面样式相关联。
• 和头文件<cfenv>，<fenv.h>因为许多编译器不可靠地支持这些功能。
• 标<filesystem>头没有足够的测试支持，并且存在固有的安全漏洞。

（强调我的）

我知道 Google C++ 风格指南可能会引起一些争议，并且有些观点我不同意。尽管如此，我很想知道<filesystem>标头中存在的固有安全漏洞是什么，这是指在使用其他一些访问文件系统的方式（例如特定于操作系统的 API 调用）时不会出现的安全漏洞。

前向声明可以隐藏依赖关系，允许用户代码在标头更改时跳过必要的重新编译。

来自https://google.github.io/styleguide/cppguide.html#Forward_Declarations

我最近了解到，关于是使用前向声明还是仅将标头包含在标头本身中存在一些争论。在工作中，我们向前声明我们的内部类（不是库代码），并在相应的.cpp. 如果.cpp从不使用类中的代码，则可以完全跳过包含；例如，它传递一个类型。

假设我们有以下代码和文件

MyClass 实际上从不需要知道 Test 的大小才能到达doWork(). 所以，我们不需要包含Test.h. 只有真正起作用的函数 ( doWork) 才需要包含在它的 cpp 中。通过使用前向声明，对 MyClass.cpp 的更改Test.h不会导致任何重新编译。但在我看来这是一件好事，因为它不是必要的重新编译。

免责声明：谷歌风格指南有一个与 void* 相关的示例，但我不确定它是否与此要点相关；因为它只是一个不正确的函数调用，而不是必要的重新编译。另外，我相信如果函数是在 .cpp 中定义的并且它们包含适当的类，那么特定示例将被消除。此外，如果它与我在这个问题中的要点有关，那么缓解与 void* 相关的问题听起来不足以完全禁止使用前向声明。

所以，我的问题是——是否有任何具体的例子可以跳过必要的重新编译？

编辑：这不是链接帖子的副本，因为该答案仅包含 void* 响应。我在这个问题中表示，我正在从给出的 void* 中寻找任何其他示例。IMO 是一个非常深奥的问题（希望在现代 c++ 中并不常见）完全放弃使用前向声明。在我看来，就像创建一个从不使用引用的规则，包括按引用传递，因为类成员引用可以通过默认副本轻松产生悬空引用

查看 3.13 下的 Google Python Style Guide 它说导入的顺序应该是：

1. Python 未来导入
2. Python 标准导入
3. 第三方模块或包导入
4. 代码仓库子包导入

究竟是Code repository sub-package imports什么？如果公司中有另一个团队编写的库是第三方还是代码库？

1. 最值得注意的是，他们使用两个空格而不是 4 个缩进。
2. 函数和方法的 CamelCase 样式而不是 camel_case 样式。

我使用 Google 风格的 Python Docstring 格式已经有一段时间了。我一直在处理没有参数的函数/方法的方式突然对我来说看起来不正确。我做了一些搜索，在网上找不到任何说明如何处理这种情况的东西。

当没有退货时，我已经看到None使用过，我可以接受，因为从技术上讲，这就是退货。但是，使用Noneargs 可能意味着实际上只有一个参数应该是类型：NoneType。

目前，我一直在做的事情看起来像这样：

我的问题是，我应该使用哪种格式（我更喜欢总是有一个Args部分）？或者也许我目前的方法并没有那么糟糕，并且是常见的做法。

其他一些候选人（如果您觉得有更好的格式，请随时提供您自己的候选人）：

我对Google Python Style GuideOptional中的类型提示有疑问。在第 3.19.5 节中，正确用法如下所示：

我不明白a: Optional[Text]。为什么不是a: Optional[Text] = None？