【问题标题】:Routine to keep names of methods, classes and functions organized?保持方法、类和函数的名称井井有条的例行程序?
【发布时间】:2010-10-11 20:13:51
【问题描述】:

我目前正在与几个同事一起开发一个 Web 应用程序。事实证明,我们都有自己的方式来命名我们目前正在编写的类、方法或任何函数。

这已经开始变得非常烦人了,所以我知道如果我们继续这样下去,我们将面临一座冰山。

显然,最好的方法是找到一个例行程序并坚持下去 - 但该具体例程应该如何看待? - 命名部件、对象、功能或其他什么时的常识是什么?有什么标准吗?

非常感谢!

【问题讨论】:

  • 这导致了哪些冲突示例?是对大小写、使用特定单词的选择还是其他方面的担忧?
  • 大写,单数,复数,$this->在一个模型中创建,$this->在另一个模型中添加等等。试图了解其他人实际在做什么

标签: php oop naming


【解决方案1】:

您可以采用的一个标准是Zend Framework standards

【讨论】:

    【解决方案2】:

    你可以看看以下:http://www.dagbladet.no/development/phpcodingstandard/

    我的工作已经实现了这一点,虽然我并不总是同意,但至少它产生了一致性。

    【讨论】:

      【解决方案3】:

      看看PEAR Coding Standards。它非常全面,如果您使用任何 pear 包,它会让事情变得更容易。

      在 Wikipedia 上查找 CRUD (Create Read Update Delete) 也可能会有所帮助。

      对于单数与复数,我倾向于尝试坚持我的代码的概念风格。我发现在 OOP 中,当您使用单数时,对象名称通常更容易让您理解。

      即使您的课程将包含有关多条狗的信息,也不要将其命名为 Dogs,而是将其命名为其他名称,例如 Pack,即使它在技术上不是一个包。围绕多个包比多个狗更容易将您的思想包裹起来,并且“包”在概念上比无定形的“狗”组更强大。 “Dogs”听起来不像是一个单一的物体,而“pack”却是。

      我想这是一个明显的例子,但如果你的类只用于定义单个对象,不要让它复数。或者,如果您的函数一次只格式化一个字符串,请不要将其称为 formatStrings()。

      数组有点不同。如果您使用数组来列出所有狗的列表,则不会将其命名为 $pack,因为您希望它包含有关包的信息。相反,您可以将其命名为 $dogs。

      【讨论】:

        【解决方案4】:

        使用命名空间。一起提出一个逻辑命名空间层次结构策略,然后在命名空间中为元素使用逻辑名称。

        【讨论】:

          【解决方案5】:

          与您的同事坐下来,解释您正在观察发展的问题,然后写下你们都同意的标准。

          如您所见,唯一的问题是一致性。因此,不要说服自己您还需要一个经过科学证明是最佳的标准。

          【讨论】:

            猜你喜欢
            • 1970-01-01
            • 1970-01-01
            • 1970-01-01
            • 2011-07-22
            • 1970-01-01
            • 1970-01-01
            • 1970-01-01
            • 2012-08-03
            • 2011-10-22
            相关资源
            最近更新 更多