PSR-1 基础编码规范

  • 类的命名 必须 遵循 大写开头驼峰命名规范，如：StudlyCaps ；
  • 类的常量所有字母 必须 大写，单词间用下划线分割；
  • 方法命名 必须 遵循 小写开头的驼峰命名规范，如： camelCase；
  • 类的属性名 可以 遵循以下三种，但 必须 选用一种来规范代码：
  • 大写开头的驼峰式： $StudlyCaps
  • 小写开头的驼峰式： $camelCaps
  • 下划线分割试： $under_score

此处的「类」指代所有的类、接口以及可复用代码块（traits）。

一个 PHP 文件中要么全是产生副作用的代码，要么则全不是。
副作用通常是生成输出、明确使用 require 或 include、连接到外部服务、修改 ini 设置、发出错误或异常、修改全局或静态变量、读取或写入一个文件，等。而不直接声明类、函数和常量的逻辑操作。
文档中的反例：一份包含「函数声明」以及产生「副作用」的代码：

  1. <?php
  2. // 「副作用」：修改 ini 配置
  3. ini_set('error_reporting', E_ALL);
  5. // 「副作用」：引入文件
  6. include "file.php";
  8. // 「副作用」：生成输出
  9. echo "<html>\n";
  11. // 声明函数
  12. function foo()
  13. {
  14.     // function body
  15. }

PSR-2 编码风格规范

直接举例子

  1. <?php
  2. namespace Vendor\Package;
  3.    <-- 空行
  4. use FooInterface;
  5. use BarClass as Bar;
  6. use OtherVendor\OtherPackage\BazClass;
  7.    <-- 空行
  8. class Foo extends Bar implements \ArrayAccess, \Countable
  9. {  <-- 独占一行
  10.     public function sampleMethod($a, $b = null)
  11.     {
  12.         if ($a === $b) {
  13.             bar();
  14.         } elseif ($a > $b) {
  15.             $foo->bar($arg1);
  16.         } else {
  17.             BazClass::bar($arg2, $arg3);
  18.         }
  19.     }
  21.     final public static function bar($arg1, &$arg2, $arg3 = [])  <-- 有默认值的参数，必须放到参数列表的末尾。
  22.     {
  23.         public $foo = null;
  24.         protected static $foo;
  26.         for ($i = 0; $i < 10; $i++) {
  27.             // for 循环主体
  28.         }
  29.     }
  30. }
  32. bar();
  33. $foo->bar($arg1);
  34. Foo::bar($arg2, $arg3);

Laravel 命名规范

  • 控制器：使用大驼峰和复数形式来命名。
  • 局部视图增加前缀下划线是「约定俗成」的做法
  • 模型:使用大驼峰和单数形式来命名
  • 在 Laravel 中，通常模型使用「下划线命名法」与「复数形式名称」来作为数据表的名称：
  • Article 数据模型类对应 articles 表；
  • User 数据模型类对应 users 表；
  • BlogPost 数据模型类对应 blog_posts 表；

  • 种子文件：使用大驼峰式来命令

    设计原则和设计范式

  • DRY 原则：Don’t repeat yourself 。意思是不要重复自己。

  • 约定优于配置（convention over configuration），也称作按约定编程，这是一种软件设计范式，旨在减少软件开发人员需做决定的数量，获得简单的好处，而又不失灵活性。如果所用工具的约定与你的期待相符，便可省去配置；反之，你可以配置来达到你所期待的方式。

    composer

    在项目开发中，我们一般会有线上环境和开发环境，使用 composer 可以很好的来区分。
    当我们要安装一个拓展包时，加上 --dev 参数，则代表只在 开发环境 中使用： ``` composer require “barryvdh/laravel-debugbar:~3.2” —dev
  1. 这样，我们在生产环境中就不能使用 `comopser install` ，因为这样会将 `dev` 中的拓展包全部下载到线上，我们可以指定参数来达到排除 `dev`  中的拓展包：

composer install —no-dev

```