您如何找到，完善和维护您的编码风格？

最近，我一直在几个项目和开发环境之间切换。每种代码风格的期望都不同。

现在，我的问题分为三个部分，第一部分是出于好奇：

1. 您如何定义和找到您的编码风格？
2. 您如何不断扩大和改进它？
3. 您如何保养它？（从心理笔记中，保存文档，使用StyleCop等工具。）

№1。＃您是如何定义和找到编码风格的？

通过代码示例，首先是书籍，然后是MSDN文本和文章，然后是博客和其他网站。

№2。您如何不断扩大和改进它？

我会注意别人提出的所有建议。我尝试一下，如果他们为我工作，他们就会坚持下去。我也会不时地进行实验，似乎可以改善的事情仍然存在。

№3。您如何保养它？（从心理笔记中，保存文档，使用StyleCop等工具。）

我记得自己的风格，并自动将其应用于所有地方。

注1.保持睁大眼睛和保持耳朵锐利对于保持电流极为重要。多年前，我从其他人那里学到了匈牙利记号法，所以我遵循了它。当社区意识到这不是很好时，我与所有人一起改变了。

注意2：采用哪种特定的样式元素通常并不重要，而是在整个代码中保持样式一致。团队也是如此。选择某种风格，然后坚持下去。

注意3.不同语言的编码样式可能会有所不同。C ++应该具有一种风格，Java应该具有另一种风格。HTML和CSS的特性再次需要一些不同的样式。

注意4.无论您选择哪种样式，都应理解并接受它不会100％有效。有时您有一些需要就地使用其他样式的代码，或者拆分多行，使用不同的对齐方式或其他使该特定代码段更具可读性的方式。不要将样式推到任何地方，而要专注于代码的可读性。如果很明显，该样式在该特定位置不起作用，请例外。

注意5.不要遵循宗教的代码风格。实施代码样式的工具不错，但有时会使您发疯。例如，我禁用了Visual Studio的自动代码格式，因为它使我发疯。如果工具成为障碍，只需添加一个例外，不必担心您的代码与100％不兼容。并不是那么重要，而完美是无法实现的。

• 您如何定义和找到您的编码风格？

我不认为我曾经说过：“好吧，这将成为我的风格”。一定要专注于特定的环境或语言。您的风格应反映您面对特定问题的方式。

• 您如何不断扩大和改进它？阅读开发人员博客可能对了解其他人正在从事的工作，寻找被广泛使用的软件（如果它是如此出色，也许您可​​以使用他们的一些解决方案）等有用。
• 您如何保养它？（从精神笔记，保存文档，使用诸如StyleCop之类的工具。）这个问题又引起了一个问题：您可以松开样式吗？我认为这是您的一部分，所以您不能，不是吗？

我曾与一个我喜欢的封闭源代码游戏团队合作，首席开发人员指导了我，并在问了他之后也帮助我提高了技能。

他建议，我采用了Zend框架的编码风格（http://framework.zend.com/manual/en/coding-standard.html）

我最终采用了不同样式的特征-包括反映在MSDN上的样式。然后，我在VS中设置模板，这些模板提供了我的代码#region/#endregion块以及其他任何可取的代码。

我继续研究通过研究和阅读遇到的其他风格。如果我认为有什么与众不同的地方可以改善我的风格的可读性，维护性或组织性，请尝试一下。如果需要进行新的样式调整，我将在VS中更新模板或进行心理注释。

1. 读取DOOM源代码。
2. 阅读其他所有内容，我会全力以赴，挑选出有用的部分。
3. 酗酒。

单独编码时，我力求简洁。Spartan编程可能是完整的，精打细算 ……但这可能是我的信条中最熟悉的事情。

当与他人进行编码时，尤其是与维护编码时，我的目标是成为变色龙-我所做的更改应改进它们所做的修改，而又不会显得不合适。

您如何定义和找到您的编码风格？

通过关注简单性和可读性（可读性！==可读性，请参阅Spartan编程）

您如何不断扩大和改进它？

通过查看他人和我自己的代码（甚至包括自己的编码标准）。

您如何保养它？（从心理笔记中，保存文档，使用StyleCop等工具。）

我使用dokuwiki，轻而易举地进行设置（无数据库），层次结构，粒度控制（开箱即用的ACL），非常漂亮的外观，还有它的wiki，因此任何人都可以贡献力量。而且，基于简单性和可读性，贡献/更改始终在共识和合理的基础上。

这是一个很奇怪的答案，但是我花了很长时间才真正开始编程。在考虑自己成为程序员之前，我花了很多时间在“艺术”领域工作。

编码时，我倾向于以写作等单元（段落，短语等）的方式进行思考。因此，我将代码扩展到更多行上，以使其像故事/文章/等那样易于阅读。当开发人员尝试尽可能多地填充到一行或一个狭小的空间时，我真的很生气，因为它除了使作者感到聪明并使以后的读者感到烦恼之外，什么也做不了。

如果为了效率而需要做一些奇怪的事情，我将对其进行评论以解释为什么会这样。

我可能对此不会有任何支持，但是无论如何，这可能会引发一些讨论。

至于技术方面，例如放置支架等，我将它们保持对齐，因为这样可以提高可读性。

1. How did you define and find your coding style?

我选择采用已经开发的样式指南，该指南在很大程度上被大型公司/项目开发并广泛接受或普及。

我这样做的原因有很多，但主要是因为这样的样式指南可以被开发人员立即采用。样式指南的价值仅与开发人员愿意坚持的一样多。

例如，Python的PEP 8，Android的Java样式指南，jQuery Core样式指南或Google的Python样式指南。

2. How do you keep augmenting and improving it?

这种样式指南的最大争议是它们不是在这里发明的，也不是我发明的。开发人员花了很多时间，令人恐惧的代码行以及比公司/团队愿意花更多的时间来开发和维护样式指南的时间。

至于改进，但是从来没有一个风格指南立即回答一切，你可能需要知道。但是，在大多数情况下，我看到的改进只是对样式指南在编写代码方法方面已经铺平的内容的更为冗长的版本。

在这种情况下，遇到麻烦时，应将其粘贴到要点或具有颜色语法支持的其他一些合适的代码片段共享工具中，并与其他开发人员讨论。很棒的事情是，在这种情况下，您对代码的功能不感兴趣，而对代码的显示方式不感兴趣，因此您可以将该代码块放在上下文之外，并讨论如何改进它，并将其与已经在代码中指定的内容进行比较。样式指南是讨论的主要起点。

3. How do you maintain it?

好吧，最棒的是，您将已经有在线公开维护的现有文档。

当涉及到代码格式化时，您还可以加倍努力，为您的团队提供他们最喜欢的编辑器的格式化程序配置，该配置程序应该在保留尖端外观的过程中消除繁琐和猜测。实际上，我不会说这会花费更多的精力，而是开发不可或缺的一部分-进行差异测试并没有什么比这更糟的了，因为90％的代码更改是有人检查了格式正确/样式正确的代码，因为有人忘记了在他们提交了一个巨大的新功能之前先进行清理。

如果您是团队的一员，则应始终添加团队标准。可以说有很多使用通用布局而不是您自己的布局。它使您的代码更易于他人阅读和理解，这是必不可少的。