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

Question

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

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

思考:

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

• 课程:MyCustomClass或myCustomClass

• 功能/方法:my_custom_function()或my_Custom_Function()

任何想法都赞赏.

Answer 1

来自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()
    {

    }
}

Answer 2

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

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

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

例如database_statement_row_read_next()，不是完全有效或典型的英语短语。凡为Database\Statement::readNextRow在年底成为一个有效的和标准的英语表达。

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

如果根据经验将名称写成普通英语的片段，则应主要使用骆驼，因为这是绝大多数使用的约定。如果您不严格关心单词的顺序与应以英语排列的单词的顺序匹配，但确实关心分类和组织，那么显式分隔符将成为标准。

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

更正确的术语是：

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

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

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

相反，在程序，功能和局部变量中，流行语言中存在使用蛇的相当强烈的趋势。

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

特别针对您的建议：

变量/属性：

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

类：

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

功能/方法：

• my_custom_function这是最简单的方法，尽管不遵循英语语法，而是使用英语作为名称空间的英语单词，您可以将其命名为function_customor ，这是可能的（在一定程度上）function_default。
• my_Custom_Function不是最简单的可行方法。大写是多余的，没有任何用处，因为它揭示了专用字符定界的隐藏好处，可以保留大小写。

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

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