开源礼节

我已经开始在Codeplex上进行我的第一个开源项目，并遇到了一些糟糕的代码。（我确实了解到C＃仍然具有“ goto”语句），我开始添加“所有者”想要的功能，并在探究了代码库并看清混乱之后（例如使用“ goto”），我想清理它一点点。但是我有点担心，这就是为什么我转向所有人：“修复”“错误代码”对我来说是适当的礼节，还是应该让它继续进行新功能？就像我之前说的，我是整个OSS领域的新手，并且通常在一个团队中工作，所以我不想搞砸。

如果您对此保持谦虚并且不会破坏任何内容，则可以这样做。您无法重新格式化代码并引入错误。它具有良好的单元测试吗？如果没有，我将通过添加单元测试开始做出贡献，然后在以后修复结构。

开源的目的是使更多的人关注项目并对其进行改进。这包括使代码更好。就是说，这是在清单上做广告的好形式。您可能会有所回退，或者可能会得到一堆+1。这些goto陈述可能就在那里，因为原始作者无法想到完成工作的更好方法。如果您后退，最好输入一个对话框来找出压力的来源。尽量不要让它变得个人化，并尝试解决这些问题。

最重要的是，单元测试胜过教条。如果您可以证明该代码在某些情况下会像现在一样发生故障，那么您要么竖起大拇指，要么由原始作者来解决。

请记住，在开源中，社区比代码更重要。如果没有社区（包括用户和开发人员），那么就没有项目。

嫉妒自己代码的人通常不会将其发布给全世界进行审查，如果这样做，周围的社区也不会持续很长时间。机智，但不要担心会伤及感情。

告诉他们您想做什么，然后再花太多时间投入其中。有时，某些不明显的原因是有历史原因的。避免getos的原因是它们可以通过代码产生意外的路径。因此，删除gotos的危险是您没有注意到其中一条有益的途径，而无意中将其从重构中忽略了。

另一方面，也许原始作者当时无法想到一种更干净的编写方式。这是代码胜于雄辩的地方，因为他们可能不相信在您展示它们之前可以做到干净整洁。我最初的开源贡献之一是撤消堆栈修复程序，该修复程序可以显着提高性能，但是一些核心开发人员说，当我初次描述它时听起来太复杂了。简短的代码示例将它们带入了程序。

如果事实证明确实有充分的理由将其保留，那么我至少会发表评论以解释这些原因。

从经验上讲...

我参与的第一个开源项目是，当我刚开始的时候，我也充满了小便和醋。

我立即要做的是浏览一堆源文件，并根据我的个人喜好开始将其样式化，创建了一个庞大的补丁程序并提交了它。

如果您正在与“好”的人（例如我）合作，他将立即拒绝该补丁。这主要是因为，当您为一个开源项目做贡献时，期望将您的修复程序分解为可解决单个问题的小块。“删除所有问题”不是原子提交的一个好例子。即使您先将其分解为较小的，有据可查的提交，也可能会拒绝它。

原因是，随着时间的推移，代码由多个人（具有不同样式）共同处理，因此接受整个库中的更改以适应一个开发人员的样式实际上是不可行的。如果出于风格的考虑而改变样式是可行的，那么每个开源项目将永远不会前进，因为将不断编辑代码以适应不同的开发者样式。

重构代码和添加功能（或删除已弃用的碎片）通常优先于“清理”代码。

开源项目中最困难，最有意义的部分是，系统会询问您为什么要进行提交的更改。如果您有充分的理由，则很有可能会提交您的补丁。

我的建议是在一个源文件上进行一些更改，以使您了解首先要执行的操作。如果这些更改有充分的理由和可以接受的，请询问是否有其他类似的更改会提高项目质量。这样，如果将来您的补丁程序被拒绝，您将一无所获。

开发开源不仅仅是编写代码。您正在建立信任关系，因为网守（控制推送访问的开发人员）将尽其所能保护项目的完整性。当您提交更多补丁时，关守将对您的样式有更好的了解，并且您不必为更改做充分的辩护。

这是一个需要时间的过程，但却是非常有益的。您不仅可以通过查看和批评别人的代码中学到很多东西，而且还会对自己的风格提出批评。

在浪费大量时间尝试“纠正其他人的编码样式的错误的不公正之处”之前，请先问自己以下问题：

您是基于为项目增值而提议的更改，还是基于您自己的内部风格宗教。

Stack Overflow（以及相关的Stack Exchange网站）上有很多宗教信仰。我的意思很多。人们会无休止地思考和讨论样式，好像您谈论的越多，就越接近“完美，理想，坚不可摧，可靠的”编码样式。我之所以谈论太多，主要是因为它很有趣。

在开源世界中，样式并不是那么重要。功能是。

注意：所有这些建议均假定您的网守是一个合理且有才华的程序员。如果他是，请算上自己的幸运，因为您没有被其中一位唯一的保护自己的“婴儿”的牢骚b @＆＃＆es卡住。它们确实存在于野外，所以如果遇到它们，不要感到惊讶。

质量>礼节

我认为您一发现质量低下就不必担心编辑他人的代码。为了获得良好的软件质量，您只需要关心干净的代码即可。我认为对其他人的代码进行改进不会有任何问题，其他人应该意识到并感激有些编码员正在编写他们的代码。

如果您不使用“ goto”就可以找到解决问题的更好方法，那么我建议您这样做。今天为使代码更好而付出一些努力可能会在将来节省您更多的精力。

与原始作者进行交流也是一个好主意。

没有什么隐含的错误goto。看一下汇编代码-到处都有很多goto（跳转和分支）。

goto这些天之所以有一个不好的名字的原因是因为Dijkstra的论文Go To语句被认为是有害的，它指出goto语句是一件非常糟糕的事情。

请注意，那是在50年前，甚至还没有命名软件工程的地方，并且大多数编程语言本质上都是底层机器的抽象，因此机器语言包含goto，所以它们也是如此。您可以尝试使用Microsoft Basic（在Apple []或Commodore 64上为原始版本）进行编程，以了解这种思维方式。

Dijkstra争论的是使事情保持简单的做法并不能解决问题，而是保持一条简单的程序路径并带有共同的结尾。例如，从方法返回。换句话说，只有局部跳跃，而不是整体跳跃。

这是引入诸如带参数的方法调用，代码的模块化，程序包等之类的步骤，所有这些都是为了减轻软件开发的复杂性而引入的。goto声明只是那场战争的第一个旁观者。