PHP/MySQL 命名约定：camelCase 与 under_score？
在 PHP 模型代码中（至少在我自己的此类代码中）经常会直接引用 MySQL 表和字段名称，并且由于 MySQL 标识符大部分不区分大小写，因此我通常使用下划线命名约定来使这些标识符成为更具可读性。
但与此同时，似乎大多数人在创建 PHP 类库时都使用驼峰命名约定，我也一直在尝试这样做。
最重要的是，PHP 内置函数本身不一致。其中一些使用驼峰命名法，其他使用下划线，还有一些使用 C 风格命名（例如“strtolower”）。
结果是代码的可读性往往比我喜欢的要差得多，因为混合的驼峰命名法、下划线和 C 风格的命名约定在代码中显示得非常接近。
其他人如何处理这个问题？也许人们已经找到了某种方式来组织他们的工作，以便不同的命名约定往往不会显得彼此如此接近？或者也许有一些类库，如果使用得当，往往会让事情变得更干净一些？我知道这些关于风格的讨论可能会很激烈——没必要去那里，请提供一些实用的建议！
Quite often in PHP model code (at least in my own such code) there are direct references to MySQL table and field names, and since MySQL identifiers are for the most part case-insensitive I typically use the under_score naming convention to make those identifiers a bit more readable.
At the same time however, it seems that most folks use camelCase conventions when they create PHP class libraries, and I've been trying to do that, too.
On top of that, the PHP built-in functions themselves are inconsistent. Some of them use camelCase, others use under_scores, and others use C-style naming (for example "strtolower").
The result is that the code tends to be much less readable than I prefer, what with mixed camelCase, under_score, and C-style naming conventions showing up quite near each other in the code.
How are other folks dealing with this? Perhaps there's some way people have found to organize their work so that the different naming conventions tend not to appear quite so close to each other? Or perhaps there are class libraries that if used properly, tend to make things a bit cleaner? I know these discussions of style can get heated -- no need to go there, just some practical suggestions please!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
正如 Teresko 所说，MySQL 名称在 *NIX 平台上区分大小写，在 Windows 上不区分大小写。如果您开发代码来支持两者（就像我一样），那么混合您的情况可能会导致巨大的麻烦：例如，在 Windows 上转储数据库并将其恢复到 *NIX 上，所有情况都会丢失。实际上，出于这个原因，我们不得不拼凑代码来检测并修复转储中的案例。
如果您没有使用 Windows，那么使用什么并不重要，只要保持一致即可。
As teresko says, MySQL names are case sensitive on *NIX platforms and insensitive on Windows. If you develop code to support both (as I do) then mixing your cases can cause huge headaches: for example, dump a database on Windows and restore it onto *NIX and all your cases are lost. We actually had to kludge code to detect and fix the cases in a dump just for this reason.
If you're free of Windows though it doesn't really matter what you use, as long as you keep it consistent.
当谈到模型和数据库表，您可以使用：
对于类，我通常会使用CamelCases（以大写字母开头）和camelCases作为方法（以大写字母开头）小写）。
但事实上，重要的是一致性和可读性。遵循一些众所周知且广泛实现的框架的命名约定可能是一个好主意，例如 Zend Framework （就编码标准而言，该框架提供了相当精确的指南），但是例如。 Kohana 可能也是个好主意。重新发明轮子可能不是最好的主意；）
When it comes to models & database tables, you can use:
For classes I would generally use CamelCases (beginning with upper case) and camelCases for methods (beginning with lower cases).
But, in fact, what counts is consistency and readability. It may be a good idea to follow naming conventions of some of the well known and widely implemented frameworks, such as Zend Framework (this one provides pretty precise guidelines as far as coding standard is concerned), but eg. Kohana may be also a good idea. Reinventing the wheel may not be the best idea ;)