1

拥有开发人员中最好的论坛网站，我想我会就哪些政策和最佳实践可以做出好的编码找到非常好的共识。我会把其中的一些放在这里，所以我给出了这个想法，但我想听听你的意见，投票可能会成为最佳政策的评判者。

  • 开发团队之间编码的特定缩进
  • 每个方法前，每个变量声明前的具体注释
  • 命名约定，驼峰式或任何其他。
  • 在每个容器标记后的 HTML 注释中。
  • 在 CSS 中，每个声明只使用一次。

你明白了。我想知道公司要求我们做什么，以及哪些真正有助于获得可维护和漂亮的代码。

4

3 回答 3

2

我会关注围绕开发实践而不是代码格式的任何政策。一些例子是：

  • 始终使用参数化 SQL 查询。永远不要将用户输入连接到查询中。
  • 将 HTML、CSS 和 JavaScript 保存在单独的文件中。
  • 每次提交代码时使用jslint或等效工具。
  • 选择一个 HTML 标准（例如 HTML 4.01 strict）。所有 HTML 都必须验证。

不要成为政策纳粹。有时必须打破规则——但这样做应该有一个很好的理由。

于 2009-08-24T19:09:34.907 回答
1
  • 如果代码不受版本控制，则代码不存在。更具体地说，生产服务器上没有任何东西，除非它被提交到存储库。
  • 如果一个项目提供了重构旧代码的机会，请抓住这个机会。
  • 维护一个 wiki 或类似的文档程序、标准和库代码的使用（当此类文档对于代码注释来说太多时）
于 2009-08-24T19:22:37.890 回答
0

（至少对于 PHP 项目——请注意 PHP 是开源的并且有一个重要的社区；所以，很多事情都是由社区中所做的事情驱动的）

首先，当在项目中使用框架时（即，始终），如果明确定义（至少 Zend 框架就是这种情况），我们会尝试坚持其政策：它确保任何人都会来从事此工作项目可以：

  • 找到标准的定义
  • 在使用相同框架的任何其他项目中重新使用它
    • 即使去另一家公司，或为另一个客户工作
    • 或者来自另一家公司时;-)

考虑到我们在我工作的公司中只为 PHP 项目使用了 3 到 5 个框架，而且他们的标准中定义的许多规则都是相同的，这不是一个真正的问题。

当然，如果在某种 CMS 内部/周围进行编码，同样适用。


当不使用特定框架时，​​我们会尝试遵守 PHP 社区广泛接受的一组通用规则：同样，它确保这些规则是众所周知的（即使是我们公司的新人），很容易找到，并且许多人确实尝试过并增强了它们。


关于注释，有一个在 PHP 中很好用的工具：phpDocumentor （与 javadoc 差不多）；它定义了一个标准——这是事实上的标准，因为没有其他工具使用得这么多。

关于特定的评论标签：

  • 我们总是使用 @param / @return ：它们集成在 IDE 中，提供类型提示，所以很有用
  • 否则，我们不会使用太多：几行来说明该方法在不明显时的作用；如果使用了困难的算法，则需要几行。


Camel-case 或其他：我们坚持 PHP 社区和框架中的共同点：

this_is_a_function

和

ThisIsAClassName

和

thisIsAMethodName


在 HTML 中：我们尽可能不使用 HTML 注释，因为它们是发送到浏览器的：

  • 意味着更大的页面（好吧，没那么多）
  • 意味着放弃用户不需要的信息

如果可能，我们使用模板引擎中的注释。


在 CSS 中：我们在需要时发表评论；更重要的是使用几个小的 CSS 文件，非常具体（即使在构建过程中使用合并工具）


但是，也许比这一切更重要：我们尝试使用“干净”的代码，带有只做一个小的“单元”事情的小方法，带有自我描述的名称和所有

它没有魔法，但它有助于理解代码......而且，测试它，重用它，......


此外，正如 Nate 所说：这些主要是指导方针——除非客户特别要求......在这种情况下，您必须使用一些自动工具（例如在您的构建过程中）来验证它们是否跟在字母后面。

于 2009-08-24T19:10:59.897 回答