好的设计要求每个函数只写一次。 在 PHP 中，我通过使用包含文件（如 Utils.php 和 Authenticate.php）以及 PHP 命令 include_once 来完成此操作。 但是我还没有找到 PHP 包含文件的任何标准或最佳实践。 StackOverflow 您会提出什么建议？
我正在寻找：
- 命名标准
- 代码标准
- 设计模式
- 定义常用函数返回类型的建议
（现在我只是使用关联数组）。
Good design dictates only writing each function once. In PHP I'm doing this by using include files (like Utils.php and Authenticate.php), with the PHP command include_once. However I haven't been able to find any standards or best practices for PHP include files. What would you at StackOverflow suggest?
I'm looking for:
- Naming Standards
- Code Standards
- Design Patterns
- Suggestions for defining return types of common functions
(now I'm just using associative arrays).
发布评论
评论（4）
我喜欢使用的一种约定是将每个类放入其自己的名为 ClassName.class.php 的文件中，然后设置 自动加载器 以包含类文件。 或者有时我会将它们全部放在classes/子目录中，并将它们命名为ClassName.php。 取决于我期望包含多少类与非类。
如果您将实用程序函数组织到类中并使其成为静态方法，则只需编写一个 require_once() 在你的顶级文件中。 这种方法可能适合也可能不适合您的代码或编码风格。
至于返回类型，我尝试遵循内置函数中使用的约定。 返回适合请求的类型，或者失败时返回 false。 只需确保在检查时使用 === 运算符结果为假。
事实上，您对惯例的关注表明您已经走在正确的轨道上。 如果您熟悉任何其他 OOP 语言，如 Java、C++、C# 等，那么您会发现，由于 PHP5 中的 OOP 优点。
One convention I like to use is to put each class in its own file named ClassName.class.php and then set up the autoloader to include the class files. Or sometimes I'll put them all in a classes/ subdirectory and just name them ClassName.php. Depends on how many class vs. non-class includes I'm expecting.
If you organize your utility functions into classes and make them static methods instead, you can get away with writing only a single require_once() in your top level files. This approach may or may not be appropriate for your code or coding style.
As for return types, I try to follow the conventions used in the built-in functions. Return a type appropriate to the request, or return false on failure. Just make sure you use the === operator when checking for false in the results.
The fact that you're concerned about conventions suggests you're already on the right track. If you are familiar with any other OOP language like Java, C++, C#, etc., then you'll find you can follow a lot of the same conventions thanks to the OOP goodness in PHP5.
无论您最终使用什么命名约定（我更喜欢尽可能从 Java 或 C# 中获取线索），请确保您使用的包含文件在包含时实际上不会执行任何代码，并且永远不要两次包含同一文件。 （使用 include-once 或 要求一次)
Whatever naming convention you end up using (I prefer to take cues from either Java or C# wherever possible) make sure if you use include files for functions that they do not actually execute any code upon including, and never include the same file twice. (use include-once or require-once)
一些此类标准已经编写。 大多数大型项目都会遵循自己的标准。
这是 Zend 编写的一个，是 Zend 框架中使用的标准。
http://framework.zend.com/manual/en/coding-standard。此外
，PEAR 始终有一些相当严格的编码标准：
http://pear.php.net/manual/en/standards.php
不过，我更喜欢的答案是，对于您自己的项目，您应该使用您觉得舒服的东西，并保持内部一致。 对于其他项目，请遵循他们的规则。 一致性可以实现最大的代码可读性。 我自己的标准和PEAR的不一样。 我不会缩进四个空格（我使用制表符），而且我从不使用像函数名称这样的驼峰式大小写，但尽管如此，如果我正在编辑另一个项目中的某些内容，我会选择该项目所做的任何事情。
Some such standards have been written already. Most large projects will follow and standard of their own.
Here is one written by Zend and is the standard used in the Zend framework.
http://framework.zend.com/manual/en/coding-standard.html
Also, PEAR always had some fairly strict coding standards:
http://pear.php.net/manual/en/standards.php
My preferred answer though is that for your own project you should use what you feel comfortable with, and be internally consistent. For other projects, follow their rules. The consistency allows for greatest code readability. My own standards are not the same as the PEAR ones. I do not indent with four spaces (I use tabs) and I never use camel case like function names, but nonetheless if I am editing something from another project I'll go with whatever that project does.
我已经做了以下事情。 首先，我创建了一个拦截过滤器，以拦截所有网络请求，我还创建了一个可以使用命令行命令的版本。
两个拦截器都会进入引导文件，该文件将设置自动加载器。 该文件作为自动加载函数和哈希值。 对于哈希，键是类名，值是类文件的文件路径。 自动加载函数将简单地获取类名并对文件运行要求。
一些性能提示（如果需要），在定义文件时使用单引号，因为它们不被解释，因此速度稍快，还使用 require/include，而不是它们的 _once 版本，这保证运行一次，并且前者要快一些。
上面的内容很棒，事实上，即使有一个包含大量类的大型代码库，哈希值也不是那么大，而且性能也从来不是一个问题。 更重要的是，我们并没有接受一些疯狂的伪名称空间类命名约定，请参见下文。
另一个选项是分隔名称、伪名称空间技巧。 这不太有吸引力，因为名称空间将随 5.3 一起提供，而且我认为这很恶心，因为在代码库中重命名这些名称空间会变得不那么有趣。 不管怎样，这就是它的工作原理，假设你的所有代码都有一个根。 然后，所有类都根据到达那里所需的目录遍历来命名，用字符分隔，例如“_”，然后是类名本身，但是文件将以类命名。 这样，类的位置就被编码在名称中，自动加载器就可以使用它。 除了 real_long_crazy_class_names_MyClass 之外，此方法的问题在于每次调用都有相当多的处理，但这可能是过早的优化，并且名称空间又来了。
例如。
I've done the following. First, I created an intercepting filter, to intercept all web requests, I also created a version which would work with command line commands.
Both interceptors would go to a boot strap file, which would setup an autoloader. This file as the autoloading function and a hash. For the hash the key is the class name, and the value is the file path to the class file. The autoload function will simply take the class name and run a require on the file.
A few performance tips if you need them, use single quotes in defining the file, as they're slightly faster since they're not interpreted, also use require/include, instead of their _once versions, this is guaranteed to run once, and the former is a fair bit faster.
The above is great, in fact, even with a large code base with a tonne of classes, the hash isn't that big and performance has never been a concern. And more importantly we're not married to some crazy pseudo name space class naming convention, see below.
The other option is delimited name, pseudo name space trick. This is less attractive as name spaces will come with 5.3 and I see this being gross as renaming these across the code base will be less fun. Regardless, this is how it works, assume a root for all your code. Then All classes are named based on the directory traversal required to get there, delimited by a character, such as '_', and then the class name itself, the file will be named after the class, however. This way the location of the class is encoding in the name, and the auto loader can use that. The problem with this method besides really_long_crazy_class_names_MyClass, is that there is a fair bit of processing on each call, but that might be premature optimisation, and again name spaces are coming.
eg.