PHP - 函数/变量命名

发布于 2024-07-10 18:31:42 字数 155 浏览 10 评论 0原文

我读过很多开源 PHP 项目的流行标准手册。

很多强制变量空格使用下划线,很多强制使用驼峰命名法。

全局函数和变量的命名是否应该与类方法/属性不同?

我知道最重要的是一致性,但我想听听对此的一些想法。

你会推荐什么?

I have read a lot of popular standards manuals for open source PHP projects.

A lot enforce underscores for variables spaces, and a lot enforce camelCase.

Should global functions and variables be named differently to class methods/properties?

I know the most important thing is consistency, but I'd like to hear some thoughts on this.

What would you recommend?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(8

惜醉颜 2024-07-17 18:31:43

在 PHP 本身中,几乎每个本机函数都用下划线分隔。 文档中的大多数 PHP 代码示例都用下划线分隔。

在大多数语言中,我认为 Camel 或 Pascal 大小写更合适,但我认为在 PHP 中使用下划线分隔有明确的历史。

In PHP itself, almost every native function is underscore separated. Most of the PHP code examples in the documentation are underscore separated.

In most languages I think Camel or Pascal Casing is more appropriate, but I think there's clear history for using underscore separation in PHP.

↙温凉少女 2024-07-17 18:31:43

Zend Frameworks 命名约定(基于 PEAR )可能是 PHP 世界中最接近标准的。 就我个人而言,我更喜欢使用小写下划线作为变量名,但除此之外我主要遵循 ZF 的约定。

十周年更新:

如今,有一个标准,在社区内得到了广泛接受。 你应该坚持这一点:

https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-1-basic-coding-standard.md

Zend Frameworks naming convention (Which is based on PEAR) is probably the closest you come to a standard in the PHP world. Personally, I prefer to use lowercase_underscore for variable names, but otherwise I mostly follow ZF's convention.

Update on 10 year anniversary:

These days, there is a standard, which is largely accepted within the community. You should stick with that:

https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-1-basic-coding-standard.md

挽梦忆笙歌 2024-07-17 18:31:43

是的,最重要的是一致性。 如果您是孤独的开发人员,请坚持使用一种方法。 如果您与团队合作,请与其他团队成员交谈。 区分全局变量、函数/方法和类将使阅读代码变得更加容易。 对于某些人来说,camelCase 比 using_underlines 更容易,因此您的团队需要讨论选项并选择一种样式。

Yes, the most important thing is consistency. If you are the lone developer, stick with a method. If you are working with a team, talk to the other team members. Differentiating between globals, functions/methods and classes will make reading the code much easier. For some people camelCase is easier than using_underlines so your team needs to discuss the options and pick a style.

赠我空喜 2024-07-17 18:31:43

注意:我对 MySQL 表名使用下划线,对 MySQL 字段名称使用 UpperCamelCase:

通常我对变量名称和类属性使用 $lowerCamelCase,但如果它包含字段中的值,我会使用$UpperCamelCase 字段名称,或者如果它是表中的数据数组,我将使用 $table_name。 这样我就可以轻松地 grep 查找 SomeFieldsome_table 并找到引用它的所有内容。

您不必使用这个精确的系统,但能够搜索对字段或表的所有引用是一个巨大的好处。

Note: I use underscores for my MySQL table_names, I use UpperCamelCase for MySQL field names:

Normally I use $lowerCamelCase for variable names and class properties, but if it contains the value from a field, I use the $UpperCamelCase field name, or if it is an array of data from a table, I'll use the $table_name. This way I can easily grep for SomeField or some_table and find everything referring to it.

You don't have to use this exact system, but being able to search for all references to a field or table is a huge benefit.

裂开嘴轻声笑有多痛 2024-07-17 18:31:43

我以前更喜欢使用驼峰命名法,但为了在更大的应用程序中保持一致,我采用了 CodeIgniter 的风格指南。

即使您不使用他们的框架,您也可以欣赏定义清晰且全面的样式的工作:http://codeigniter.com/user_guide/general/styleguide.html

I used to prefer to use camelCase, but for the sake of consistency in bigger applications, I have adopted CodeIgniter's style guide.

Even if you don't use their framework, you can appreciate the work that went into defining clear and comprehensive styles: http://codeigniter.com/user_guide/general/styleguide.html

嘦怹 2024-07-17 18:31:43

我的目标 - 无论名称的具体格式如何 - 都是添加更多信息。 该名称是否可以提高对代码的理解和/或表达一些重要的内容?

如果确实如此,那就太好了,那么您就成功了。

如果这个名字没有添加任何东西,你为什么还要费心命名它呢?

我本周早些时候写过这个:

http://caseysoftware.com/blog/useful-naming -约定

My goal - whatever the specific format of the name - is adding more information. Does the name improve the understanding of the code and/or express something important?

If it does, great, then you've succeeded in it.

If the name doesn't add anything, why did you bother naming it?

I wrote on this one earlier this week:

http://caseysoftware.com/blog/useful-naming-conventions

我爱人 2024-07-17 18:31:43

我建议阅读 PEAR 编码标准。 由于 PEAR 是官方的 PHP 扩展和应用程序存储库,因此可以将其视为该语言的官方编码标准。

I would recommend reading the PEAR Coding Standards. Since PEAR is the official PHP Extension and Application Repository, it can be considered the language's official coding standard.

阪姬 2024-07-17 18:31:42

我发现驼峰式打字更舒服一些,因为我发现下划线打字有点尴尬。

不要使用全局变量。

我避免使用 PHP 进行过程性编码,我发现 OOP 更容易让事情井井有条。 此外,PHP 的全局命名空间中还没有足够的东西吗?

一般来说,我尝试坚持:

  • 类是 StudlyCaps 单数或复数名词,视情况而定:ItemRowDBItems< /代码>。
  • 变量是小写名词、单数或复数,具体取决于它们所包含的内容:$column$name
  • 常量是单数大写名词:DEBUGTYPE_FOO
  • 方法采用驼峰式命名法,以单数动词(getperformdo)开头,后跟描述其内容的名词(单数或复数)操作或返回 (getThing(), getThings())

这绝对取决于您要编码的内容。 如果我编写 PHP 或 PEAR 代码,我会使用驼峰命名法。 如果我使用 Python/Django,我会使用下划线。 如果我正在编写 ELisp,我会使用虚线分隔符。

I find camelCase a little more pleasant to type, because I find the underscore a bit awkward to type.

Don't use global variables.

I avoid procedural coding in PHP, I find OOP is easier to keep things organized. Besides, doesn't PHP have enough stuff in it's global namespace already?

Generally I try to stick to:

  • Classes are StudlyCaps singular or plural nouns, as appropriate: Item, Row, DB, Items.
  • Variables are lowercase nouns, singular or plural depending on what they hold: $column, $name
  • Constants are singular upper-case nouns: DEBUG, TYPE_FOO.
  • Methods are camelCase, and begin with singular verbs (get, perform, do), followed by a noun (singular or plural) describing what it operates on or returns (getThing(), getThings())

It definitely depends on what you're coding for. If I'm coding PHP or PEAR, I use camelCase. If I'm doing Python/Django, I use under_scores. If I'm writing ELisp, I use dashed-separators.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文