我什么时候应该在PHP命名中使用驼峰大小写/驼峰大小写或下划线？

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

类名必须在StudlyCaps（即：PascalCase）中声明。

类常量必须以所有大写字母声明，并带有下划线分隔符。

方法名称必须在骆驼案例中声明。

本指南有意避免了有关使用$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()
    {

    }
}

许多人有许多不同的偏好，在大多数情况下，他们通常只是偏好。除了人们习惯的东西或流行的东西之外，很少有任何押韵的理由来解释为什么普通人更喜欢某种特定的风格。不幸的是，这往往不会让您知道在涉及更实际的问题时为什么要使用任何特定的约定。

许多人依赖PSR，这减轻了必须建立约定的任务。在任何开发团队中，都应建立约定以简化一致性。与自己动手相比，PSR可以节省一些时间。虽然这是一个有用的开始，但你不应该觉得PSR建议是权威的。这最终取决于你如何编写你的PHP，但如果你从头开始，你应该首先调查其他人是如何做到的。这并不意味着你必须以同样的方式去做，但这是一个开始。

PSR 具有某些限制：

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

撇开这一点不谈，骆驼壳（骆驼）和蛇壳（蛇）之间有一些语义和实际差异。

直接的区别在于，骆驼较少使用字符来分隔单词;它更紧凑。如果您将对象转换为 JSON，然后将其压缩以发送到浏览器，则可能并不总是如此。虽然在大多数情况下，差异可以忽略不计，但在某些情况下，骆驼会或多或少地压缩。您不太可能担心这一点。一般来说，两者之间有一个非常微不足道和微不足道的性能差异。

紧凑性是有代价的，无论是从人的角度还是从程序化的角度来看。分离和使用术语可能更加困难。在再次压缩文件之前，我们解压缩文件以处理它们是有原因的，尽管更微妙的是，相同的原则在这里适用，但紧凑更难。从某种意义上说，它也是有损的，那就是分隔符使角色变异。这很不方便，因为它并不总是适用于第一个字符。您不能简单地按案例拆分和加入。其中一个重要原因是动态访问或元编码，其中属性和方法可以自动确定，例如通过组装一组令牌。

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

如果我有，那么我会为该字段传递用户名或电子邮件，这些是原始表单。在这种情况下，我在创建类时必须对每个字段进行操作。更进一步，如果我通过动态提供这些呢？在这种情况下，每次我需要转换骆驼时，至少使用蛇壳，我所要做的就是将其固定在绳子的末端，它将一对一映射，而不会变形或担心它是在最后还是开始。考虑映射到两个字段（如操作和字段）到类成员：(get_by|getBy)($field, $value)ucfirst__calllcfirst

• lcfirst 如果追加或大写，则按大小写拆分，将 lcfirst 映射到第二个
• 拆分，如果以其他方式附加到休息，则将 ucfirst 映射到所有，concat

对：

• 分裂
• 加入

默认情况下，Snake以原始形式保留令牌，如果不是，则更容易单独转换容易分离的单词。

在PHP中使用元编码来充分利用它是很常见的，这将包括相当数量的基于字符串的运行时多态性。你最终很可能会遇到这样一种情况，即你会发现蛇比骆驼更有益，因为你想动态编码。

ifCamelCaseWereReallyThatGreatEveryoneWouldBeAnsweringProgrammingQuestionsOnStackOverFlowLikeThis.asYouCanSeeForAnythingButTheShortestPhrasesShortFormQuicklyBecomesTiring.youCanUallyGetAwayWithItInProgrammingAsItsInSmallDosesAndInASeaOfWhiteSpace.另一个烦恼与CamelCaseIsWhenYouHaveAbbreviationsOrSingleLetterWords.它不一切正常。

从语义上讲，人们也倾向于使用snake到命名空间，而不是将其与短语一起使用。相反，骆驼倾向于用于以纯英语顺序或作为标题阅读的小短语或句子。这在OOP中尤其常见，其中类名倾向于提供第一个也是最常用的分类层，并且今天倾向于越来越多地允许嵌套命名空间（在PHP中完全支持）。如果你正在做一些绝对的事情，那就是按顺序组合来自不同类别的集合中的单词，而不是组合英语中的单词来创建一个短语，那么惯例是使用snake。在这种情况下，你更有可能发现自己在做元编码。

例如，不完全是一个有效或典型的英语短语。其中，如最后成为有效且标准的英语表达。database_statement_row_read_next()Database\Statement::readNextRow

虽然英语更舒适和熟悉，但它有一定的问题。当它们可能（不一致）时，事情并不总是以相同的顺序或以相同的方式说，这再次可能使元编码变得更加尴尬，其中使用单词集并将它们组合在一起是很自然的，而不必担心有时需要两个而不是一个单词，顺序或单词，短语的转折， 等。

如果你写出的名字是简单英语的片段作为经验法则，你应该使用骆驼，主要是因为这绝对是使用的惯例。如果你不严格关心单词的顺序与它们在英语中应该出现的顺序相匹配，但关心分类和组织，那么明确的分隔符往往是标准。

他们没有告诉你关于骆驼的是，按照惯例，你几乎总是被要求写它，同时还要遵守英语语法规则，这些规则并不总是在偶尔的情况下锻炼和分类命名。

更正确的术语是：

• 下划线分隔 = alpha_beta
• 大小写分隔 = 阿尔法贝塔
• 大写大小写分隔 = AlphaBeta

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

在编程世界中，通常使用大小写分隔（大写和非大写的混合）往往是OOP的标准。一般来说，在PHP中，你通常也会更加一致，特别是对于任何与OOP相关的名称，比如这样一种方法。

相反，对于程序变量，函数变量和局部变量，流行语言中有一种相当强烈的倾向，即它们使用snake。

无论你选择什么，尽量保持一致，在有差异的地方，你应该有一个理由和一个惯例。如果你把两者混合在一起，那么你可能会把一个放在门面后面。骆驼往往是供人类消费的，并被解读为有效的英语，如果需要元编码，就像蛇一样，你可以在门面后面嵌套。

专门针对您的提案：

变量/属性：

• userid将变得难以阅读，并最终创建其他单词。也不可能将其翻译成另一种标准格式。
• user_id很好。
• userId很好
• userID很糟糕。它将转化为user_i_d而不是user_id。

类：

• MyCustomClass是一个通用且非常一致的标准，也是有道理的，因为类名是标题，应该大写。
• myCustomClass可能会让它看起来像有人在打算放置类名时放置了一个方法。

功能/方法：

• my_custom_function这是最简单的事情，可以工作（在合理范围内），尽管出于不坚持英语语法的惯例，而是将其用于命名空间的英语单词，您可以称之为或.function_customfunction_default
• my_Custom_Function这不是可能起作用的最简单的事情。大写是多余的，没有任何目的，它揭示了专用字符分隔的隐藏好处，它可以保留大小写。

有些人可能会被骗使用两者来提供一个或多个级别的嵌套。无论你为了什么，它最终都会变得丑陋。它与 CSV 或二维数组中的 CSV 概念相同。骆驼和蛇都用来表示一系列单个单词。如果你想表示两个单词数组，那么你需要一些特殊的东西，比如两个的组合或多个分隔符，其中可能包括一个多字符分隔符。如果你处于这种情况，很可能是YAGNI的情况，因为在实践中，骆驼或蛇本身几乎总是足够的。如果你要把它们混为一谈，那应该是一个战略的一部分，这个战略不仅仅是肤浅的，要么是有据可查的，要么是显而易见的。

这方面的一个相关例子可能是这种情况。我可能会决定总是有.操作和字段可能需要分别使用多个单词进行描述。这可能导致将骆驼用于田间和操作，但蛇将田地和操作分开。例如，这将给出 ，或 。它并不美丽，但可能会被认为是为了达到实际目的。从 snake 开始提供一个命名空间，然后以 camel 结束也很常见，这基本上就是你使用 OOP 命名空间、类和方法得到的。如果出于充分的理由，把事情混为一谈是没有错的，但更多时候，像这样的风格混合往往是一种难闻的代码气味，导致你进入一个未冲洗的厕所。get_by_username|get_by_email[$operation, $field]getBy_usernamedeleteBy_usernamegetBy_firstName