Laravel：我应该坚持使用骆驼案例名称来表达Eloquent关系吗？

Question

Laravel鼓励我们使用snake_case，例如： first_name，用于模型属性名称。特别是，当使用snake case从类外部访问属性时，它将自动查找名为getFirstNameAttribute的访问器。

然而，当谈到模型关系时，使用驼峰的情况似乎更自然。例如，如果体育场有多个接入点，则accessPoints()类可能具有$stadium->accessPoints方法。我可以将此方法称为属性（$stadium->accessPoints()）以检索访问点列表，或者我可以将其称为方法（{{1}}）以获取基础查询构建器的实例。

这与我通常采用命名约定的方式不同。我通常会使用相同的case（snake_case或camelCase）来命名属性，而不管属性是如何实现的。

我现在正在开展一个大型的Laravel项目。我应该坚持使用两种不同的语法，还是我可能会在轨道上后悔？

Answer 1

没有真正的惯例，就像刺客信条的说法那样，

  

“没有什么是真的，一切都是允许的”

Laravel遵循PSR-2编码标准。资料来源：https://laravel.com/docs/5.5/contributions

将我们重定向到https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-1-basic-coding-standard.md

（来自https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-2-coding-style-guide.md说：代码必须遵循PSR-1中列出的所有规则。）

它说：

  

无论使用何种命名约定，都应该在合理的范围内始终如一地应用。该范围可以是供应商级别，包级别，类级别或方法级别。

从该声明中，这与环境级约定之间的分离有关，例如数据库设计约定和代码约定。大多数数据库设计约定都鼓励使用蛇案例列名，大多数代码约定都使用驼峰式方法名称，类名等。

在定义模型时，为了声明模型属性与数据库列相关，编码约定从 camelCase 更改为 snake_case 。

Answer 2

嗯，这是一个惯例，所以你应该使用你更熟悉的方法。

我个人仅在列属性上使用snake_case，在其他所有内容上使用camelCase（类名，关系ecc）。

请注意，类名和方法的camelCase基本上是必需的，因为所有laravel和外部模块类和方法都使用camelCase。如果你使用snake_case，你将在camelCase的snake_case和framework方法中实现一些方法。

对于人际关系，你基本上只会使用你自己定义的关系，所以我相信你可以选择你喜欢的关系。