最近，我在GitHub上遇到了许多开源Ruby（或大多数是Ruby）项目，当使用诸如Rubocop之类的代码分析工具进行检查时，会造成很多冒犯。

现在，大多数此类违法行为包括使用双引号而不是单引号（未插值时），不遵循每级2个空格规则，超过80个字符的行长规则或对多行块使用{和}。

[The Ruby风格指南]推荐了最佳实践，以便现实世界中的Ruby程序员可以编写可由其他现实世界中的Ruby程序员维护的代码。〜资料来源：Ruby样式指南

尽管它们很小且易于修复，但是否适合通过修正违规并提出“拉取请求”来更改开源项目的编码风格？我承认，某些项目（例如Rails）不接受外观更改，而有些项目太大而无法一次“修复”（例如，在运行Rubocop时，Rails会产生80,000多个违规行为-不管它们有自己的一小套编码）贡献时应遵循的惯例）。毕竟，《Ruby样式指南》与诸如Rubocop之类的工具一起存在是有原因的。

人们喜欢一致性，因此对Ruby社区来说，进行此类更改通常是一件好事，对吧？

[Ruby样式指南的作者]并非一无所有地提出了所有规则-它们主要是基于我作为专业软件工程师的广泛职业，以及来自Ruby社区成员和各种人的反馈和建议。高度评价的Ruby编程资源，例如“ Programming Ruby 1.9”和“ The Ruby Programming Language”。〜资料来源：Ruby样式指南

难道不是遵循社区编码风格的惯例和最佳实践基本上是在鼓励不良实践吗？

询问维护者。

编码风格是一个非常主观的讨论，并且最大行长（例如80个字符）之类的规则是相当主观的-尽管普遍同意应该使较短的行更易于阅读，但对于今天的屏幕尺寸和IDE来说，80行可能过于严格。

其他规则也可以有意忽略。例如，开发人员可能会认为对他更好地全局使用双引号，并愿意接受意外插值带来的“风险”，而解析时间的增加却很小。

许多维护人员也不喜欢对代码风格进行较大的更改，因为它们很无聊，并且可能会引入错误。例如，即使字符串包含有意的内插并且应该使用双引号，也可以将其切换为单引号。维护人员更喜欢在处理实际代码时进行样式清理，以便他们可以验证样式更改不会引入新的错误。

您似乎在很大程度上受到尊重rubocop工具和Ruby样式指南的权威的鼓舞，而维护者可能不会共享它们。它们已经具有自己的风格并且已经习惯了，因此任何更改都会影响到项目中的每个人，这是很多工作，尤其是在项目规模较大的情况下。

考虑维护者的动机。他们（可能）希望新人通过提交错误修正，错误报告，工作代码和编写良好的文档来加入他们的行列。如果您出现并说“您在鲁比科有冒犯”，他们不会想“哦，好新的人来帮助分担负担”，他们会想“这家伙是谁？他为什么告诉我们”该怎么办？”。

开源项目往往是优点：基于您的工作质量而受到尊重。如果您出现并做一些很棒的事情，然后提出您的风格问题，尽管他们仍然会拒绝，但他们更有可能倾听。有一个开放源代码，说“对话很便宜，请告诉我代码”。

总是对教条的实用主义。编码风格指南是一种特别隐蔽的邪恶形式，它使人们的注意力从建筑问题转移到轻率的废话，如单引号或双引号。问问自己：这真的有所作为吗？

它们可以达到一定程度，但是第二次以几乎宗教的热情对待它们时，您走得太远了。它们是准则，建议，观点，而不是事实。

那他们应该被忽略吗？不，使用这些工具来获得需要查看的内容的一般想法是有意义的，但仅此而已。

令人惊讶的是，初级人员经常将观点误认为事实。

仅当存在用于修复格式的未解决问题时，才能拉出这些更改。否则，请启动您自己的分支，并且如果作者看到更多的人只是因为其可读性强而使用您的分支。他们将自行合并在分支中，但准备通过合并更新并不断修复格式来维护分支。

如果该项目对您而言并不重要，无法继续维护自己的分支，那么首先就不值得进行清理。

拉取请求可以由作者亲自处理。这不是一种提供批评的机制，重新格式化所有代码都可以视为批评。

如果您不想维护自己的分支机构，但是想为一个项目做贡献。打开一个新问题，并说明当前格式导致您出现问题的原因，然后为作者提供解决问题的方法。如果作者同意，那么他们将把问题分配给您，您现在有权提出拉取请求。

您已经谈到了一个我也同意在GitHub上普遍存在的问题。撇开格式，有许多项目错误地使用了注释，并且导致许多IDE遭受破坏。我可以想到三个最受欢迎的项目，这些项目错误地使用了已弃用的标志，这些标志在我的IDE中传播了警告消息。我已经发送了修复请求的修复请求，但是作者没有使用相同的IDE，因此该请求被忽略。

分支，合并和修复似乎是唯一的解决方案。

来自Rubocop网站本身（重点是我）：

作为Ruby开发人员，一件事情一直困扰着我-Python开发人员拥有出色的编程风格参考（PEP-8），而我们却从未得到过正式指南，没有记录Ruby编码风格和最佳实践。

请理解：

没有官方的Ruby样式指南

我并不是说样式指南不好。但是不仅没有官方指南，而且拥有风格指南是在个人，项目，团队，公司级别上做出的选择。用心理学术语来说，风格指南是“团体内社会规范”。

这对您意味着什么？好吧，如果您不被视为小组成员，则意味着您-或任何其他网站所说的任何事情-极不可能与小组保持联系。因此，如果您不是该特定项目的积极，受人尊敬的贡献者，那么您的建议很可能会被忽略，或者充其量只能提醒您有关使用样式指南的先前考虑。在最坏的情况下，它会被当作侮辱，或者是闯入者或骑车者将鼻子塞在不属于它的地方。

您不能只建议样式指南吗？

实际上，这似乎是您想要做的：您相信样式指南的价值，高度重视一致性，并且希望宣传致力于统一样式指南的工作。

很好，只要您真的很清楚这就是您要实现的目标和要实现的目标。如果您相信一种特定的风格指南，并且相信它是《一个真实的风格指南》，或者至少比那些无赖的异教徒们在练习时跑来跑去，那也很好。

但是人们不满意的是，人们被告知他们的行为不符合非官方，无约束力，很大程度上是任意的规则，这些规则来自他们不认为是合法权威的来源。当您打算这样做时，或者仅仅是您被认为正在做的事情时，您将获得较少的“红地毯护理”，而更多的是“带有矛和大锅的愤怒本地人”治疗。

在这里提供替代意见，在许多情况下，欢迎进行此类更改。开源项目往往有很多作者。通常没有“编码风格”。样式就是编写有问题的代码的人碰巧使用的任何样式。如果一个文件是由另一个人编写的，则样式也可能会有所不同。即使在存在共识样式的项目中，除非他们定期检查这种样式，否则通常不会使用它。

在我的经验中，一个常见的例子是有人通过样式相对较低的拉取请求贡献了一些代码。但是，该代码可能会起作用。不同的人对此有不同的看法。除非样式良好，否则某些人会拒绝合并拉取请求。只要代码有效，有些人就不在乎。有些人喜欢有良好的风格，但是他们不想用一堆“在此处修复空白”的注释吓退贡献者（我个人总是对这些注释感到内gui，尽管我知道它们会变得更好。很好的代码库，因为它确实感觉会吓跑贡献者）。

因此，不要直接假设您看到的样式就是项目所需的样式。实际上，通常可以将其概括为对开源做出贡献：不要以为开源项目拥有的代码就是它想要的代码。

不过，您应该注意一些事项：

• 有些人信奉风格。如果很明显他们不想让步，那就不要打扰。

• 这是一个巨大的 bikeshed问题。每个人和他们的兄弟都对这些事情有看法。因此，很难合并这样的拉取请求。

• 合并这样的拉取请求也很困难，因为它将很快合并冲突。基本上，只要您修改的代码库的任何部分发生更改，即使它以微不足道的方式发生。

我会坚持“先问”的方法。如果他们愿意接受，并且您愿意坚持请求请求完成，那么就去做吧。

我曾经非常擅长于编写好的样式指南，但是鉴于Ruby的状况，“我已经继续”。

基本上，我按照自己的工作习惯生活，否则遵循从许多工作中学到的一般惯例。

对于Ruby（我选择的语言），我（头脑中）也将样式划分为普遍接受，普遍接受的偏好和最佳实践。普遍接受的事情我可能会在问题或功能分支请求的变更请求中提交变更。

每种样式的示例（在我看来）：

Ruby普遍接受：

• 空格而不是制表符
• 两个空格缩进
• method_names_use_underscores
• 常量以Caps开头。

普遍接受：

• 如有必要，不要使用括号
• 用{ }一行块和do end多行块。
• CONSTANTS_ARE_IN_ALL_CAPS
• 如果表达式适合1行cond ? true : false，if then则使用谓词（）。

个人喜好：

• 行长为120个字符行
• case when语句从case语句缩进2。
• 除非需要双引号，否则使用单引号。

没有协议：

• 案例陈述
• 线长

最佳做法：

• 小方法，如果可能，<= 5行。
• 小类，如果可能，<= 100行。
• 避免常数
• 代码有测试

最后，正如其他人详细介绍的那样，您应该先问一下。归根结底，风格的关键是开发人员之间的沟通和对他人的敏感性。例如，如果我想在一个开源项目中进行样式更改，我通常会先提出一个或两个实际功能或错误修复的请求请求。一旦维护人员了解我并看到我的贡献，那么我可能会建议更改样式。我只建议他们。例如“在项目x上做另一个功能时，我注意到您在几个文件中有4个空格缩进，我想知道是否可以将它们更改为2个？”

尽管它们很小并且很容易修复，但是您认为可以通过修正违规并提出“拉取请求”来更改开源项目的编码风格吗？

简而言之，不！

当然，我在这里假设这些只是样式问题，而不是实际的错误-对后者的拉取请求始终是明智的（IMO）。我还假设您是该项目的陌生人，并且不与已经维护它的人联系。

但是，在所有语言中，总有一些人的喜好与样式指南有所不同，无论好坏，他们都试图对您不认识的人和您不参与的项目实施这些样式更改的，如果没有别的可能给人的印象是有点粗鲁。毕竟-如果请求被接受，您将实现什么（实际上）？如果一个项目的成员很可能希望将样式更改为其他样式，那么他们早就已经做到了-而您对该请求所做的只是强迫他们使用一种不一定能更好地工作的样式对于现有成员。

如果您愿意以其他方式（而不是样式“修复”）为项目做出贡献，则此更改会稍有变化。我想说的是，如果您想与维护者就您想如何进行该项目进行对话，但发现非标准样式很困难，那就很好。但是我真的不会只是盲目地为一堆只包含样式更改的项目创建拉取请求！

任何更改都有可能引入错误，甚至更改代码的印刷格式。
因此，除非有有效的业务案例，否则不得对代码进行任何更改，并且“但代码看起来不美观”或“代码未遵循编码标准”不是有效的业务案例。风险实在太大了。
现在，如果您仍然要对源文件进行重大更改，则可以按照标准提取整个文件，这是可以接受的，但是很可能您将进行较小的更改，在这种情况下，将自己的更改保存在其中通常是更可取的选择即使现有代码未遵循编码标准，该代码仍与现有代码一致。
哎呀，代码很可能是代码生成器的结果，有时会被重新生成。代码生成器因生成丑陋的代码而臭名昭著。

我有几个中度成功的.NET项目，还有一些PR的发布者，他们似乎与ReSharper和StyleCop一起完成了代码，并“修复”了很多东西。由于某些原因，我不接受这些PR：

• 尽管许多更改都变得更好，但是其中一些更改以某种方式（通常是性能）对代码产生了负面影响，而挑选好的部分则是非常艰巨的工作。
• 即使所有更改都是良性的，甚至是有益的，每次提交中每个文件中的每个更改都需要进行检查，并且再次花费的时间太长。

就是说，如果有人想添加一些更好的错误检查或文档注释，我将在心跳中接受该PR。

您需要确定维护者是否认为这些编码风格违规是缺陷，或者项目是否具有不同的编码风格标准。

如果它有不同的标准，则可以提供帮助文档或使其正式化。然后可能会发现有些违反该样式的问题，您可以修复这些问题。