什么时候我应该在PHP命名中使用camelCase / Camel Case或下划线？

时间：2017-07-22 12:52:58

标签： php naming-conventions naming camelcasing

我一直在学习PHP，并且看到人们如何命名的东西有很多变化。我渴望至少与自己保持一致。

我应该在哪里使用Camel Case？我应该在哪里使用下划线？

思想：

  • 变量/属性：$userid或$user_id或$userID

  • 课程：MyCustomClass或myCustomClass

  • 函数/方法：my_custom_function()或my_Custom_Function()

任何想法都赞赏。

3 个答案:

答案 0 :(得分：13)

来自PSR基本编码标准（https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-1-basic-coding-standard.md）

  

班级名称必须在 StudlyCaps 中声明。

     

类常量必须使用下划线在所有大写中声明   分离器

     

方法名称必须在 camelCase 中声明。

     

本指南有意避免任何有关使用的推荐   $ StudlyCaps，$ camelCase或$ under_score 属性名称。

<?php
namespace Vendor\Model;

class Foo
{
    const VERSION = '1.0';
    const DATE_APPROVED = '2012-06-01';

    private $StudlyCapsProp = null;
    protected $camelCaseProp = null;
    public $under_score_prop = null;

    public function fooBar()
    {

    }
}

答案 1 :(得分：3)

许多人有很多不同的偏好，在大多数情况下，他们往往只是偏好。除了人们习惯或流行之外，关于普通人偏爱特定风格的理由很少有任何押韵。不幸的是，当涉及到更多实际问题时，这往往不会给您任何为什么使用任何特定约定的想法。

许多人都依赖PSR，这简化了必须建立约定的任务。在任何开发团队中，都应建立约定以简化一致性。与您自己做相比，PSR可以节省一些时间。尽管这是一个有用的开始，但您不应认为PSR建议具有权威性。最终由您决定如何编写PHP，但是如果您是从头开始的话，则应首先研究其他人是如何做到的。这并不意味着您必须以相同的方式进行操作，但这只是一个开始。

PSR具有某些限制：

  1. 它是通过共识而不是任何特定的科学建立的，这意味着它往往不一致。
  2. 这并不完全彻底。您最终会发现没有指定任何选项的情况。
  3. 最初旨在改善框架之间的兼容性，但现在包括了品味而非兼容性。在很多情况下，使用哪种约定对兼容性的影响与对袜子适合脚部颜色的影响一样大。
  4. 对于许多（如果不是大多数）项目，框架之间的兼容性往往很少或不会引起很大关注。特别是对于封闭源代码商业项目。
  5. 它们纯粹是来自非官方第三方的建议。有人可能更喜欢逆时针搅拌咖啡，并建议通过互联网进行搅拌，但实际上，搅拌的方向取决于您或您所在的团队。星巴克，Nero和Costa可能会发表联合声明，建议您顺时针搅拌，但是如果您不想的话，则不必听他们的话。

撇开骆驼案（骆驼案）和蛇案（蛇案）在语义和实践上有一些区别。

直接的区别是骆驼使用较少的字符来分隔单词；它更紧凑。如果将对象转换为JSON，然后将其压缩以发送到浏览器，则可能并非总是如此。尽管在大多数情况下差异可以忽略不计，但在某些情况下骆驼或多或少会有效地压缩。您不必为此担心。总的来说，两者之间的性能差异非常小且无关紧要。

从人的角度和程序的角度来看，紧凑都会带来代价。分离和处理术语可能会更加困难。我们有理由将文件解压缩以在再次压缩之前对其进行处理，尽管此处适用的原理较为微妙，但压缩更难。从某种意义上说，它也是有损的，即分隔符会使字符发生变化。这并不方便，因为它并不总是适用于第一个字符。您不能仅根据情况拆分和加入。重要的原因之一是动态访问或元编码，其中可以例如通过组装一组令牌自动确定属性和方法。

如果我创建了一个生成器，该生成器将自动创建对象以表示数据库中的表并用作存储库，那么我可能会在该类上生成方法，以便能够按列读取。我可能正在看get_by_username|get_by_email或getByUsername|getByEmail。

如果我有(get_by|getBy)($field, $value)，那么我将为该字段传递用户名或电子邮件，那是原始表格。在这种情况下，创建类时，我必须ucfirst的每个字段。如果我进一步通过__call动态提供这些内容，该怎么办？在那种情况下，每次我需要至少用lcfirst转换骆驼时，在使用蛇形盒的情况下，我要做的就是将其固定在字符串的末尾，它将一对一地映射而无需变换或担心。无论是在最后还是在开始。考虑映射到类成员的两个字段（例如operation和field）：

  • lcfirst（如果追加或大写），按大小写分隔，将lcfirst映射到第二个以后
  • 拆分，将ucfirst映射到所有对象，否则添加其余部分，concat

对：

  • 分割
  • 加入

默认情况下，Snake会将令牌保留为原始形式，如果没有，则更容易分别转换容易分离的单词。

在PHP中使用元编码以充分利用它是很常见的，其中包括相当数量的基于字符串的运行时多态性。最终您很可能会遇到这样一种情况：使用蛇比想要动态编码的骆驼受益更多。

如果CamelCase真的是那样，那么每个人都将像在此那样在StackOverFlow上回答编程问题。如您所见，但最短的短语简短表格很快就变成了累人。您通常可以在程序设计中以小剂量获取并在白色空间中获取它。如果您有缩写或单字母单词，则使用驼峰式案例时会出现另一个烦恼。 itNotAllGood。

在语义上，人们还倾向于使用蛇来命名空间，并且不将其与短语配合使用。相反，骆驼通常用于小的短语或句子，这些短语或句子顺序地以简单的英语阅读或作为标题。这在OOP中尤为常见，在该类中，类名倾向于提供分类的第一个也是最需要的层，而如今，它倾向于越来越多地允许嵌套的名称空间（在PHP中完全受支持）。如果您要进行分类操作，那就是按顺序组合不同类别中的单词，而不是组合英语单词来创建短语，那么习惯就是使用蛇。在这种情况下，您更有可能会进行元编码。

例如database_statement_read_row_next()实际上不是有效的英语短语。最后的Database\Statement::readNextRow变成有效的英语表达形式。<​​/ p>

尽管英语更加舒适和熟悉，但它仍然存在某些问题。事情不一定总是以相同的顺序或以相同的方式说（不一致），这可能再次使元编码变得更加尴尬，因为在这种情况下使用单词集并组合在一起很自然，而不必担心有时需要两个而不是一个单词，一个命令或一个单词，词组轮换等。

如果根据经验将名称写成普通英语的片段，则应主要使用骆驼，因为这是绝大多数使用的约定。如果您不太在意单词的顺序与英语应匹配的顺序，但在乎分类和组织时，则显式分隔符将成为标准。

关于骆驼，他们没有告诉您的是，按照惯例，几乎总是希望您编写骆驼，同时还要遵守英语语法规则，这种语法规则在某些情况下并不总是很适合锻炼和分类命名。

更正确的术语是：

  • 下划线定界= alpha_beta
  • 以大小写分隔的= alphaBeta
  • 大写字母分隔的案例= AlphaBeta

在最后一种情况下，第一个大写字母不定界。

在编程世界中，通常使用区分大小写（大小写混合）是OOP的标准。通常来说，您通常也会最终更加一致地坚持使用PHP，特别是对于任何与OOP相关的名称，例如方法。

相反，在程序，函数和局部变量中，流行语言中存在一种使用蛇的强烈趋势。

无论您选择哪种方法，都应尽可能保持一致，并且在存在差异的地方，应同时具有其理由和约定。如果将两者混合使用，则可以将其放在立面后面。骆驼倾向于供人类食用，并被读为有效的英语，在这种情况下，如果需要进行元编码，则像蛇一样，您可以将其嵌套在门面后面。

专门针对您的建议：

变量/属性：

  • userid将变得难以阅读，并且最终还会产生其他单词。也无法将其转换为另一种标准格式。
  • user_id很好。
  • userId很好
  • userID不好。它将转换为user_i_d而不是user_id。

课程：

  • MyCustomClass是一个通用且非常一致的标准，在类名是标题且应大写的情况下也很有意义。
  • myCustomClass可能会让某人想放一个类名时看起来像放了一个方法。

函数/方法：

  • my_custom_function这是可能的最简单的事情（由于一定原因），尽管出于惯例，不遵循英语语法，而是将英语单词用于命名空间，您可以将其称为function_custom或function_default。
  • my_Custom_Function并不是最简单的可行方法。大写是多余的，没有任何用途，因为大写显示了专用字符定界的隐藏好处，可以保留大小写。

有些人可能会不喜欢使用两者来提供一个或多个嵌套级别。无论出于什么目的，它都会变得丑陋。与CSV或二维数组中的CSV的概念相同。骆驼和蛇都用来表示单个单词的数组。如果要表示两个单词数组，则需要一些特殊的东西，例如两个或多个分隔符的组合，其中可能包含多个字符分隔符。如果您处于这种情况，那么很可能会遇到YAGNI，因为实际上骆驼或蛇几乎总是足够的。如果您要混合使用它们，那么它应该是策略的一部分，该策略不仅是肤浅的，而且有据可查或显而易见。

与此相关的示例可能是get_by_username|get_by_email情况。我可能会决定始终拥有[$operation, $field]。可能需要用一个以上的单词来描述操作和字段。这可能会导致将骆驼用于野外作业，而将蛇用于野外作业。例如，这将给出getBy_username，deleteBy_username或getBy_firstName。它虽然不漂亮，但可能被认为具有实际用途。从蛇开始提供名称空间，然后以骆驼结束，这在某种程度上也是常见的，这实际上是使用OOP名称空间，类和方法所获得的。如果有充分的理由将各种东西混合在一起是没有错的，但更多的是，这种风格的混合往往会变成一种不好的代码气味，导致您无法上厕所。

答案 2 :(得分：0)

根据我们使用的框架，它可能会有所不同。我们应该遵循我们用于开发应用程序的框架所遵循的命名约定。

每个框架遵循不同的命名约定。示例：

  • Zend 不允许使用下划线
  • Symfony 也鼓励使用驼峰式命名法
  • Wordpress 鼓励下划线，不喜欢驼峰式
  • CodeIgniter 也促进下划线

所以：使用您的框架使用的任何内容或创建您自己的命名约定。

但是对于 PHP 开发人员的基本命名约定，我发现它可以使用。

对于变量

我们可以使用小写下划线。喜欢

$first_name = "John";
$last_name = "Doe";

（大多数 php 开发者和 LV 等框架都使用这个。wordpress 也使用这个命名约定来声明变量。）

对于常量

我们可以使用 ALL CAPS 案例。喜欢

define('DB_HOST', 'localhost'); 
define('DB_USER', 'db_user');

（大多数 php 开发者和框架以及 CMS 使用这个命名约定来声明 php 常量。）

对于类名

我们可以使用pascal case。喜欢

class UserDetails {
    // 
}

（像 LV 这样的 PHP 框架使用这个约定，许多 php 开发者使用这个命名约定。）

对于函数和类方法名称

我们可以使用骆驼套。喜欢

function getName() {
    // Do something
}

（像 LV 这样的 PHP 框架使用这个约定，许多 php 开发者使用这个命名约定。）

注意：但wordpress遵循小写under_score来声明函数。

function get_name() {
    // Do something
}

您可以获得更多详情here。

相关问题
最新问题