PHP-FIG 是指PHP Framework Interop Group(PHP框架互操作性小组),是一个由PHP社区成员组成的团体,旨在为PHP项目制定标准和规范,以提高不同PHP框架之间的互操作性和可移植性。该小组的成员来自不同的PHP框架和项目,如Symfony、Laravel、Zend Framework等。
PSR 是PHP Standard Recommendation的简写,它其实应该叫PSRs,即系列推荐标准:目前通过的规范有PSR-0(Autoloading Standard)、PSR-1(Basic Coding Standard)、PSR-2(Coding Style Guide)、PSR-3(Logger Interface)、PSR-4(Improved Autoloading)。它不是PHP官方标准,而是从如Zend、Symfony2等知名PHP项目中提炼出来的一系列标准,目前有越来有
首先恭喜大家,包括我自己,坚持到了现在。这篇文章之后,Composer的基础原理就清晰明了咯。也就是说,Composer所利用的正是spl_autoload_register()和PSR4规范,然后通过线上服务器存储包,来实现包管理的功能。spl_autoload_register()的作用我们已经清楚了,主要就是动态加载我们所需要的文件。然而我们的文件不可能都乱七八糟的随便找个目录放下,然后注册一堆的spl_autoload_register()来加载吧,要真这么写,估计你的老板会废了你。在这个时候,PSR路径规范的作用就显示出来咯!!
本文档是PHP互操作性框架制定小组(PHP-FIG :PHP Framework Interoperability Group)制定的PHP编码规范(PSR:Proposing a Standards Recommendation)中译版。
不管是什么框架,就拿 ThinkPHP 框架来说,官方文档明确说明:ThinkPHP5.1遵循PSR-2命名规范和PSR-4自动加载规范。这就引出了本篇博文的内容:PSR 是什么?PSR 由谁规定的? PSR是PHP Standards Recommendation的简称,意为 PHP 推荐标准、PHP 开发的实践标准。要想了解 PSR,首先得知道制定这一标准的人/组织是谁: PHP-FIG PHP-FIG全称为PHP Framework Interop Group,是一个组织,这个组织的成员由一些 PH
在说啥是PSR-[0-4]规范的之前,我觉得我们有必要说下它的发明者和规范者:PHP-FIG。就是这个联盟组织发明和创造了PSR-[0-4]规范
1.3 注意事项 Hyperf 依赖swoole并基于cli,不需要使用nginx与php-fpm,所以即使本地没有这2个服务依旧可以运行起来 Hyperf在每次更新代码时都需要重载文件,即关闭进程重新执行php bin/hyperf.php start命令 Hyperf中存在很多与laravel框架中也在使用的composer包,所以也可以在必要的时候去参考laravel文档,当然也有不同,会在下文进行举例 关于注解与切面的知识点,可以提前了解,如果不是了解也不会很影响正常的业务功能开发 在此之前你需要了
ModernPHP读书笔记(二) ——PHP开发标准 (原创内容,转载请注明来源,谢谢) 本文主要讲述PHP-FIG(PHP FrameworkInteroperability Group(PHP框架可互用性小组))发布的四套开发标准,该标准主要目的是为了让各类PHP框架相互兼容,降低PHP开发人员的学习难度,让致力于框架研发改造的开发者可以集中精力于开发,而不在于学习新的框架。我个人也曾忙于学习各框架的实现过程,而仿佛落入大海中,忽略了框架的内核与中心。如果该标准推广,所有框架的基本形式均相同,会非常
一、PSR0简介 下文描述了若要使用一个通用的自动加载器(autoloader),你所需要遵守的规范: 一个完全标准的命名空间(namespace)和类(class)的结构是这样的:\<Vendor Name>\(<Namespace>\)*<Class Name> 每个命名空间(namespace)都必须有一个顶级的空间名(namespace)("组织名(Vendor Name)")。 每个命名空间(namespace)中可以根据需要使用任意数量的子命名空间(sub-namespace)。 从文件系统中加载源文件时,空间名(namespace)中的分隔符将被转换为 DIRECTORY_SEPARATOR。 类名(class name)中的每个下划线_都将被转换为一个DIRECTORY_SEPARATOR。下划线_在空间名(namespace)中没有什么特殊的意义。 完全标准的命名空间(namespace)和类(class)从文件系统加载源文件时将会加上.php后缀。 组织名(vendor name),空间名(namespace),类名(class name)都由大小写字母组合而成。 参考:http://www.php-fig.org/psr/psr-0/ 以下,列出PSR0构建的规范类的几种形式:
本规范的主要目的,是为了让日志类库以简单通用的方式,通过接收一个 Psr\Log\LoggerInterface 对象,来记录日志信息。 框架以及CMS内容管理系统如有需要,可以对此接口进行扩展,但需遵循本规范, 这才能保证在使用第三方的类库文件时,日志接口仍能正常对接。
来源/https://www.startutorial.com/articles/view/modern-php-developer-psr
PSR 是由 PHP FIG 组织制定的 PHP 规范,是 PHP 开发的实践标准,这是具体的地址:
团队开发约定使用PSR-2的编码风格规范,但是并不是所有人都严格按照PSR-2来提交代码的
composer init或者直接install之后,自动生成了一个vendor目录,这时您需要在文件中手动的require这个vendor目录下的autoload.php文件,其实这个文件又载入了vendor/composer/autoload_real.php。
composer (一) – 依赖管理 前面这篇文章介绍了 composer 对依赖的安装及更新。
副作用:(side effects),一个文件只做一件事情,如果做了其他事情就是产生了副作用
说明:本文主要以Laravel的容器类Container为例做简单说明Composer的自动加载机制。
本机环境:win10 集成环境:studyphp(方便学习使用Windows下集成环境) 数据库可视化操作软件:sqlyog
当自动加载类如Foo\\Bar\\Baz时,命名空间Foo指向一个名为src/的目录意味着自动加载器将查找名为src/Bar/Baz.php文件并引用它。
在团队开发中,每个人的代码风格都不一样,为了日后方便更新和维护,必须考虑协作和编码规范。
本规范的主要目的,是为了让日志类库以简单通用的方式,通过接收一个 Psr\Log\LoggerInterface 对象,来记录日志信息。 框架以及 CMS 内容管理系统如有需要,可以 对此接口进行扩展,但需遵循本规范,
本篇文章中介绍的扩展是 vscode-phpcs,用于项目开发中 PHP 代码的编码规范。
团队开发约定使用 PSR-2 的编码风格规范,但是并不是所有人都严格按照 PSR-2 来提交代码的
本篇规范制定了代码基本元素的相关标准,以确保共享的 PHP 代码间具有较高程度的技术互通性。
PSR(Proposing a Standards Recommondation 建议重新修订标准), 即PHP编码规范,目前PSR更新为2016.5.26的PSR4,后续我们将持续关注。
虽然在[PSR-4-Meta]中指出PSR-4是对PSR-0规范的补充而不是替换,但是在[PSR-0]中已经写到PSR-0于2014.10.21被废弃,并在[PSR-4-Meta]中详细写明了PSR-0的不足,已经不能满足面向package的自动加载。
PSR-4 描述了从文件路径中 自动加载 类的规范。 它拥有非常好的兼容性,并且可以在任何自动加载规范中使用,包括 PSR-0。 PSR-4 规范也描述了放置 autoload 文件(就是我们经常引入的 vendor/autoload.php)的位置。
良好的代码规范可以提高代码可读性,团队沟通维护成本。最推荐大家遵守的是 php-fig(PHP Framework Interop Group) 组织定义的 PSR-1 、 PSR-2 两个。不了解的同学可以先通过连接点击过去阅读下。 PHP-CS-Fixer 项目地址: https://github.com/FriendsOfPHP/PHP-CS-Fixer 用来自动格式化你的代码。 通过安装 Composer 安装 composer.phar global require fabpot/php-cs-f
入职两天了,继续研究Swoole的框架,新公司有内部wiki,对于一些代码规范还是很重视的
笔者在6月份加入新团队,新团队这边刚组建起来,基础一些东西还处于待完善状态,比如笔者组内同学约定使用PSR-2的编码风格规范,但是并不是所有人都严格按照PSR-2来提交代码。
PHP 正在重生。作为一门专注WEB开发的语言,它不断吸取其他语言的优点,如命名空间,闭包,性状,操作码缓存等特性,PSR 规范和Composer 包管理以及 PHP 7 的性能提升,PHP 正在变成一门现代化的语言,让我们一起聊聊 PHP 有哪些新的变化!
当我们编写面向对象的程序时,通常是将类分别放在不同的文件中。但这样一来,当我们调用其他类的时候,则需要先手动引入该文件(否则会因为当前程序中没有该类名的类而报错)
在 HTML 和各种 API 格式的上下文中,超媒体链接已经变成 Web 越来越重要的一部分。然而遗憾的是,没有一种通用单一的超媒体格式,也没有一种通用的方式来表示链接间的格式。 该规范旨在为 PHP 开发人员提供一种简单的、通用的方式来表示一个独立于所使用的序列化格式的超媒体链接。 这反过来又允许系统将超媒体链接的响应序列化为一种或多种有线格式,而不依赖于决定这些链接应该是什么的过程。
『Composer 一统天下的时代已经到来!』——白岩松 『Composer 将会是未来PHP主流!』——马云 『不会包管理的程序员会被淘汰!』——近平 『一起来学composer搭建框架!』——李文凯 “一个时代结束了,另一个时代开始了。” Framework Interoperability Group(框架可互用性小组),简称 FIG,成立于 2009 年。FIG 最初由几位知名 PHP框架开发者发起,在吸纳了许多优秀的大脑和强健的体魄后,提出了 PSR-0 到 PSR-4 五套 PHP 非官方规范
仔细的缕了一下关于PHP代码的书写规范,我发现我确实有很多不足的地方,需要改进,PHP代码遵循PSR(PHP Standard Recommendation)规范,之前忘了看那本书到psr4,psr4优化的是composer的依赖倒置,现在已经到psr18了,官网链接 php-fig 。
每个人的显示器分辨率不一样。既然不超过一屏也会出现别的同事一屏会超出的情况。所以,即使未超过一屏,也尽量保证代码行在 40 行以内。如果发现自己的代码超过了 40 行,那么就需要考虑自己的代码是不是有拆分不合理的地方。特殊情况允许超过 40 行。但是,整个方法里面的代码必须是简单的判断逻辑。不包含复杂的业务判断逻辑。因为,不同的业务判断最佳实践是单独封装一个方法。
PSR 是 PHP Standard Recommendation 的简写,即PHP推荐标准。PSR 不是PHP官方标准,而是从如Zend、Symfony2等知名PHP项目中提炼出来的一系列标准。
设定 ContainerInterface 的目的是为了标准化框架或类库如何使用容器来获取对象和参数(本文其它部分称之为 实体 )。
Composer 作为 PHP 的包管理工具,为 PHPer 们提供了丰富的类库,本文来一步步剖析 Composer 的原理
本文译自 Matt Stauffer 的系列文章. ---- Laravel 的主版本号之所以从 4 升到 5. 一个很重要的原因是目录结构的改变. 这个改变实际上不只是文件组织方式的变化, 而是思想上的一个重大转变. 新的目录结构能够更好地反映 Laravel 开发者的工作方式或者说推荐的工作方式. 不仅如此, 新的目录结构也能够减少有关 "最佳实践" 这个话题的争论. 此外, 从新的目录结构也能更好地理解 Laravel 的工作机制. 新版本的目录结构 app Commands Cons
TP5和TP6版本之间的差异: ThinkPHP6.0运行环境要求PHP7.1+,不支持5.1的无缝升级
在前段时间的文章:在PhpStorm中安装使用PHP_CodeSniffer编码规范检查工具中提到过phpcbf脚本
是的,既然我们在使用一个composer扩展的时候根据一份composer.json来安装依赖包,那么我们发布扩展包的时候,也应该先有一份描述自己的清单 - composer.json。
这是一篇社区协同翻译的文章,已完成翻译,更多信息请点击 协同翻译介绍 。 讨论请前往:https://laravel-china.org/topics/8690 文章的标题真是自命不凡,不是吗?是的,虽然我们使用 PHP 工作很多年,但是我们能够说出哪些是最佳实践和最好的工具吗?我不能,但是我将要去这么做。 我看到开发者们使用 PHP 工作的方式正在发生真正的变化,不仅因为 PHP 新的版本和自身逐步的完善,让 PHP 语言发生了巨大变化,变得更加成熟和健壮,更重要的是整个生态系统也在不断地改变。 为了
一、能愿动词 MUST 必须 MUST NOT 一定不能 SHOULD 应该 SHOULD NOT 不应该 二、概览 文件必须(MUST)只用<?php或者<?=标签。 php代码必须使用UTF-8
这篇文章来说一下为什么在生产环境下使用 Composer 加载包后要再使用 dumpautoload 呢?
Composer是PHP的依赖管理工具。它允许您声明您的项目所依赖的库, 并且它将为您管理 (安装/更新) 它们。它以每个项目为基础管理它们, 并将它们安装在项目内的目录 (如 vendor) 中. 默认情况下, 它不会在全局范围内安装任何内容。因此, 它是一个依赖关系管理器。
1. Composer 第一点就要提 Composer ,自从 Composer 出现后,PHP 的依赖管理可以变得非常简单。程序内依赖一些类库和框架,直接使用 Composer 引入即可,通过使用 composer update 安装依赖的包。解决了过去加载外部库的各种难题。Composer 也有国内镜像,速度非常快。现在绝大部分 PHP 开源的项目都提供了 Composer 的支持,建议大家在项目中使用 Composer 来解决 PHP 代码包管理的问题,不要再使用下载源码、手工 include 的原
领取专属 10元无门槛券
手把手带您无忧上云