问题标签 [google-style-guide]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票
1 回答
2361 浏览

intellij-idea - IntelliJ IDEA 似乎忽略了代码格式

我一直在尝试让我的 Intellij IDEA 确认类似于 google 的 Java 标准 - 但是导入和手动设置似乎都被忽略了。

这是我的缩进当前设置的方式: 截图

但是,我的代码仍然格式化为 4 个空格,当我重新格式化时,它也变为 4 个空格。

提前致谢!

0 投票
3 回答
10091 浏览

google-style-guide - 在整个项目上运行 CPPlint

我想在我的整个项目上运行cpplint.py而不是单个文件来获取项目中所有 C/C++ 文件的报告。如何在 macOS 和 Windows 上执行此操作?

0 投票
2 回答
2229 浏览

python - Sphinx Napoleon 扩展:使用 Google Style 文档字符串记录多个返回参数

这个问题与另一个有关。建议和接受的解决方案是:

这个解决方案不起作用,至少对我来说。不解析带有arg1和描述的缩进子块。arg2

sphinx我应该如何使用,sphinx.ext.napoleon和 Google Style 文档字符串管理多个退货?

0 投票
1 回答
391 浏览

java - Java google 样式的缩进 emacs 文件

我需要在 Java 应用程序中使用谷歌风格的缩进。我获得了添加到我的 .emacs 文件的代码,但它不起作用。

当我运行 checkstyle 代码时,它给了我标签错误。

这是我的 .emacs 文件包含的内容:

您能否告诉我出了什么问题,或者指向我要替换它的文件?

0 投票
1 回答
2247 浏览

r - r 80 个字符的行限制

我一直致力于为工作编写可读的代码和样式指南。我了解 80 个字符的行限制建议。

有时我会写一长串代码,如果我坚持 80 个字符的限制,那么它的可读性就会降低。

这是我如何格式化代码的示例(不符合 80 个字符,破折号表示字符)

如果我遵循 80 个字符的限制,我可以输入如下代码

我发现第一个示例更具可读性。每个逻辑操作都是一个新行,并且读得很清楚。第二个例子很容易理解,但是当我达到 80 个字符的限制时变得很复杂。我可以阅读它,但我将字符串分成多行,将单个逻辑操作分成多行等。

是否可以接受更长的字符串超过 80 个字符的限制(除了所有潜在的格式问题)?

0 投票
3 回答
11377 浏览

java - 如何解决 At-clause 应该有一个非空的描述?- 检查样式 - Java

我在 eclipse luna 的 checkstyle 插件中使用 google java 样式。在我的 java 文档中看到这个错误,但似乎找不到解决方法。这是次要的,但它困扰着我。

我的javadoc:

错误在@throws 行,错误:

0 投票
1 回答
7255 浏览

c++ - 谷歌风格指南“是未经批准的 C++11 标头”

为什么<chrono>Google CPP 指南中有未经批准的标头?我在Google CPP Style Guide中找不到任何直接提及的内容。 这一点提到了可移植性问题,<ratio><cfenv>没有提到<chrono>.

0 投票
1 回答
1228 浏览

c++ - 为什么 Google C++ Style Guide 推荐 PascalCase 函数名?

歌风格指南说:

通常,函数应该以大写字母开头,并且每个新词都有一个大写字母(又名“大写驼峰式”或“帕斯卡式”)。

对我来说,Pascal 案例看起来非常陌生,我非常不愿意适应该准则。使用 PascalCase 的风格指南背后的原因是什么?

0 投票
2 回答
4710 浏览

c++ - 为什么 Google 样式指南不鼓励前向声明?

并不是说 Google Style Guide 是圣经,但作为一个新手程序员,它似乎是一个很好的参考。

Google Style Guide 列出了前向声明的以下缺点

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

  2. 对库的后续更改可能会破坏前向声明。函数和模板的前向声明可以防止标头所有者对其 API 进行其他兼容的更改,例如扩大参数类型、添加具有默认值的模板参数或迁移到新的命名空间。

  3. 从命名空间 std:: 前向声明符号会产生未定义的行为。

  4. 可能很难确定是否需要前向声明或完整的#include。用前向声明替换 #include 可以默默地改变代码的含义:

代码:

如果#include 被替换为B 和D 的前向decls,test() 将调用f(void*)。

  1. 从标头前向声明多个符号可能比简单地#includeing 标头更冗长。

  2. 构造代码以启用前向声明(例如,使用指针成员而不是对象成员)会使代码变得更慢和更复杂。

但是,对 SO 的一些搜索似乎表明前向声明通常是一个更好的解决方案。

因此,鉴于这些看似微不足道的缺点,有人可以解释这种差异吗?

什么时候可以安全地忽略部分或全部这些缺点?

0 投票
1 回答
166 浏览

android - 谷歌样式向导

我开始使用谷歌风格向导,我想知道是否可以根据确定的区域为街道(例如:当地街道)涂上不同的颜色。如果您能告诉我如何在 android studio 2.2 中执行此操作,我将不胜感激。