很多站长朋友们都不太清楚Php美化代码格式，今天小编就来给大家整理Php美化代码格式，希望对各位有所帮助，具体内容如下：
本文目录一览： 1、 什么是psr-0，psr-1，psr-2标准 2、 phpstorm怎么格式化代码 3、 php怎么让一段美化代码只显示在主站，分站不显示也不使用 4、 PHP PHP 5、 我是网站前台美工，我不懂PHP，只懂HTML，那如何美化php页面啊？ 什么是psr-0，psr-1，psr-2标准转自：
FIG组织在制定跟PHP相关规范，简称PSR，PSR旨在通过讨论我们代码项目的共同点以找出一个协作编程的方法。
什么是psr0强调自动加载的方式
下文描述了若要使用一个通用的自动加载器(autoloader)，你所需要遵守的规范：
规范
一个完全标准的命名空间(namespace)和类(class)的结构是这样的：\*
每个命名空间(namespace)都必须有一个顶级的空间名(namespace)("组织名(Vendor Name)")。
每个命名空间(namespace)中可以根据需要使用任意数量的子命名空间(sub-namespace)。
从文件系统中加载源文件时，空间名(namespace)中的分隔符将被转换为 DIRECTORY_SEPARATOR。
类名(class name)中的每个下划线_都将被转换为一个DIRECTORY_SEPARATOR。下划线_在空间名(namespace)中没有什么特殊的意义。
完全标准的命名空间(namespace)和类(class)从文件系统加载源文件时将会加上.php后缀。
组织名(vendor name)，空间名(namespace)，类名(class name)都由大小写字母组合而成。
示例
\Doctrine\Common\IsolatedClassLoader => /path/to/project/lib/vendor/Doctrine/Common/IsolatedClassLoader.php
\Symfony\Core\Request => /path/to/project/lib/vendor/Symfony/Core/Request.php
\Zend\Acl => /path/to/project/lib/vendor/Zend/Acl.php
\Zend\Mail\Message => /path/to/project/lib/vendor/Zend/Mail/Message.php
空间名(namespace)和类名(class name)中的下划线
\namespace\package\Class_Name => /path/to/project/lib/vendor/namespace/package/Class/Name.php
\namespace\package_name\Class_Name => /path/to/project/lib/vendor/namespace/package_name/Class/Name.php
以上是我们为实现通用的自动加载而制定的最低标准。你可以利用能够自动加载PHP 5.3类的SplClassLoader来测试你的代码是否符合这些标准。
实例
下面是一个怎样利用上述标准来实现自动加载的示例函数。
<?php
function autoload($className)
{
$className = ltrim($className, '\\');
$fileName = '';
$namespace = '';
if ($lastNsPos = strrpos($className, '\\')) {
$namespace = substr($className, 0, $lastNsPos);
$className = substr($className, $lastNsPos + 1);
$fileName = str_replace('\\', DIRECTORY_SEPARATOR, $namespace) . DIRECTORY_SEPARATOR;
}
$fileName .= str_replace('_', DIRECTORY_SEPARATOR, $className) . '.php';
require $fileName;
}
SplClassLoader实现
下面的gist是一个按照上面建议的标准来自动加载类的SplClassLoader实例。这是依据这些标准来加载PHP 5.3类的推荐方案。
什么是psr1，定义基本代码规范
本节我们将会讨论一些基本的代码规范问题，以此作为将来讨论更高级别的代码分享和技术互用的基础。
RFC 2119中的必须(MUST)，不可(MUST NOT)，建议(SHOULD)，不建议(SHOULD NOT)，可以/可能(MAY)等关键词将在本节用来做一些解释性的描述。
1. 概述
源文件必须只使用 和 这两种标签。
源文件中php代码的编码格式必须只使用不带字节顺序标记(BOM)的UTF-8。
一个源文件建议只用来做声明（类(class)，函数(function)，常量(constant)等）或者只用来做一些引起副作用的操作（例如：输出信息，修改.ini配置等）,但不建议同时做这两件事。
命名空间(namespace)和类(class) 必须遵守PSR-0标准。
类名(class name) 必须使用骆驼式(StudlyCaps)写法 (译者注：驼峰式(cameCase)的一种变种，后文将直接用StudlyCaps表示)。
类(class)中的常量必须只由大写字母和下划线(_)组成。
方法名(method name) 必须使用驼峰式(cameCase)写法(译者注：后文将直接用camelCase表示)。
2. 文件
2.1. PHP标签
PHP代码必须只使用长标签()或者短输出式标签(<?= ?>)；而不可使用其他标签。
2.2. 字符编码
PHP代码的编码格式必须只使用不带字节顺序标记(BOM)的UTF-8。
2.3. 副作用
一个源文件建议只用来做声明（类(class)，函数(function)，常量(constant)等）或者只用来做一些引起副作用的操作（例如：输出信息，修改.ini配置等）,但不建议同时做这两件事。
短语副作用(side effects)的意思是 在包含文件时 所执行的逻辑与所声明的类(class)，函数(function)，常量(constant)等没有直接的关系。
副作用(side effects)包含但不局限于：产生输出，显式地使用require或include，连接外部服务，修改ini配置，触发错误或异常，修改全局或者静态变量，读取或修改文件等等
下面是一个既包含声明又有副作用的示例文件；即应避免的例子：
<?php
// 副作用：修改了ini配置
ini_set('error_reporting', E_ALL);
// 副作用：载入了文件
include "file.php";
// 副作用：产生了输出
echo "<html>\n";
// 声明
function foo()
{
// 函数体
}
下面是一个仅包含声明的示例文件；即应提倡的例子：
<?php
// 声明
function foo()
{
// 函数体
}
// 条件式声明不算做是副作用
if (! function_exists('bar')) {
function bar()
{
// 函数体
}
}
3. 空间名(namespace)和类名(class name)
命名空间(namespace)和类(class)必须遵守 PSR-0.
这意味着一个源文件中只能有一个类(class)，并且每个类(class)至少要有一级空间名（namespace）：即一个顶级的组织名(vendor name)。
类名(class name) 必须使用StudlyCaps写法。
PHP5.3之后的代码必须使用正式的命名空间(namespace) 例子：
<?php
// PHP 5.3 及之后:
namespace Vendor\Model;
class Foo
{
}
PHP5.2.x之前的代码建议用伪命名空间Vendor_作为类名(class name)的前缀
<?php
// PHP 5.2.x 及之前:
class Vendor_Model_Foo
{
}
4. 类的常量、属性和方法
术语类(class)指所有的类(class)，接口(interface)和特性(trait)
4.1. 常量
类常量必须只由大写字母和下划线(_)组成。 例子：
<?php
namespace Vendor\Model;
class Foo
{
const VERSION = '1.0';
const DATE_APPROVED = '2012-06-01';
}
4.2. 属性
本指南中故意不对$StulyCaps，$camelCase或者$unser_score中的某一种风格作特别推荐，完全由读者依据个人喜好决定属性名的命名风格。
但是不管你如何定义属性名，建议在一个合理的范围内保持一致。这个范围可能是组织(vendor)级别的，包(package)级别的，类(class)级别的，或者方法(method)级别的。
4.3. 方法
方法名则必须使用camelCase()风格来声明。
什么是PSR2定义代码风格
代码风格指南
本手册是基础代码规范(PSR-1)的继承和扩展。
为了尽可能的提升阅读其他人代码时的效率，下面例举了一系列的通用规则，特别是有关于PHP代码风格的。
各个成员项目间的共性组成了这组代码规范。当开发者们在多个项目中合作时，本指南将会成为所有这些项目中共用的一组代码规范。 因此，本指南的益处不在于这些规则本身，而在于在所有项目中共用这些规则。
RFC 2119中的必须(MUST)，不可(MUST NOT)，建议(SHOULD)，不建议(SHOULD NOT)，可以/可能(MAY)等关键词将在本节用来做一些解释性的描述。
phpstorm怎么格式化代码phpstorm格式化代码的快捷键：Ctrl + Alt + L
设置代码样式：File -> Settings -> Code Style ->PHP
（根据个人php代码规范和个人喜好设置 PHP 等代码的样式结构。）
phpstorm可以设置：1、等号对齐；2、中括号显示方式；3、空格 显示方式等...
一、phpstorm格式化代码代码示范：
二、对 phpstorm 设置好后，可以把设置信息导出，以便后续安装后再次使用。
导出设置方法：File -> Export Settings
导入设置方法：File -> Import Settings
php怎么让一段美化代码只显示在主站，分站不显示也不使用是同一个程序绑定的不同域名么，如果可以分开的最好，不是分开的就得判断是不是分站就行了
PHP PHP你写的没有错，保存成PHP格式可以
一般保存成.PHP格式后，php的代码会变颜色
不然你就新建一个PHP格式的网页，然后把你刚才的所有代码全部复制进去就可也了
我是网站前台美工，我不懂PHP，只懂HTML，那如何美化php页面啊？有好的美工基础，也能美化好PHP程序，但并不是一定能够美化好PHP程序。
出于行业分工不同，php程序员对于html、css、js有一定的了解，但出于工作时间和兴趣，很多php程序员并不是太喜欢在这方面做太多的努力，这些都交给美工。所以美工应该对这些都要掌握，当然有的企业甚至专门有js程序员。
以前，程序员把html和php代码混合编写，导致美工与程序员无法分清，影响了工作效率，降低了产品质量。为解决这个问题，开始使用模板技术。使用模板以后，美工只管做静态页面，动态输出的内容，则使用表达式代替。如{#文章内容#}。
模板技术并不能够完全解决页面的美化问题。实际上，有许多情况下，美工对于程序员这些复杂的表达式，是很有束缚的，很难设计出富有人性化和创造力的页面。就我个人的一些经验，我提出我的一些看法：
1、网站美工先行。美工应该在程序员之前，设计出网站所需要的各种静态页面。对于同一类的，只需要设计一种，比如提示信息、出错信息。做得多无所谓，尽可的做得多。真正的工作量，可能不是页面的图片和页面的表格，而是页面复杂的表单信息和追求人性化的JS代码。
美工和程序员在动手之前，实际上脑海中都有对于项目应用的了解，只是双方的侧重各有不同，但对于静态页面，程序员其实也是清楚的，只是美工想到的是美观，而程序员想到的是实用。
2、美工应该对PHP特性多一些了解。因为受php官方的影响，php的程序员是质朴的，简洁的。所以不要去埋怨他们。即便你是美工，实际上你也不要有惧怕源码的观念，html、css、js都是源码，你不懂它们，很难做好一个页面，php也不是很复杂，了解一下有必要。正如程序员一样，他们对于美工也都有一定的了解。另外，任何程序化的页面，最难的在于处理循环。就是说，一样东西，要显示很多次。频道，有时候是1个，有时候是5个，菜单，有时候是2个，有时候是8个，还有表格的行数，诸如此类。所以美工要考虑这些动态内容的显示，既要兼顾美观，又要兼顾循环。对这些循环的东西，无法用图片直接表示，也不宜做得太复杂。根据第一条的经验，我觉得美工就是先做下去，然后程序员觉得这地方不好弄，美工再改。
3、对于php的成品，如果需要美化，还是参照第一条，把所有的php页面看清楚，用html做出来，然后交由程序员去整合。php成品，纯粹美工，是搞不定的。即便这些成品使用了模板技术，如果前期没有美工的介入，有时仍需要程序员去修改他的php代码。
绿色产品，手工打造。绝无复制，版权保留。
关于Php美化代码格式的介绍到此就结束了，不知道本篇文章是否对您有帮助呢？如果你还想了解更多此类信息，记得收藏关注本站，我们会不定期更新哦。
查看更多关于Php美化代码格式 php 美化的详细内容...