vim php代码规范

vim 代码规范工具php-cs-fixer.phar

(参考https://github.com/FriendsOfPHP/PHP-CS-Fixer)

INSTALL

curl http://get.sensiolabs.org/php-cs-fixer.phar -o php-cs-fixer
  sudo chmod a+x php-cs-fixer
  sudo mv php-cs-fixer /usr/local/bin/php-cs-fixer

至此,你可以直接用php-cs-fixer格式化代码了

USAGE

(目前支持的level有psr0, psr1, psr2,symfony,contrib)

  php-cs-fixer fix test.php --level=psr2
   php-cs-fixer fix ./ --level=psr2

这并不能满足一个vimer的小心灵

vim-php-cs-fixer

INSTALL

Bundle ‘stephpy/vim-php-cs-fixer

CONFIGURE

.vimrc(参考:https://github.com/stephpy/vim-php-cs-fixer)

" If php-cs-fixer is in $PATH, you don‘t need to define line below
" let g:php_cs_fixer_path = "~/php-cs-fixer.phar" " define the path to the php-cs-fixer.phar
let g:php_cs_fixer_level = "psr2"              " which level ?(psr0, psr1, psr2, symfony)
let g:php_cs_fixer_config = "default"             " configuration
let g:php_cs_fixer_php_path = "php"               " Path to PHP
" If you want to define specific fixers:
"let g:php_cs_fixer_fixers_list = "linefeed,short_tag,indentation"
let g:php_cs_fixer_enable_default_mapping = 1     " Enable the mapping by default (<leader>pcd)
let g:php_cs_fixer_dry_run = 0                    " Call command with dry-run option
let g:php_cs_fixer_verbose = 0                    " Return the output of command if 1, else an inline information.

以上配置我们发现

let g:php_cs_fixer_enable_default_mapping = 1     " Enable the mapping by default (<leader>pcd)

这个配置快捷键为\pcd 实际操作中会发现极易出错,而且太长了吧

.vim/bundle/vim-php-cs-fixer/plugin/php-cs-fixer.vim

if(g:php_cs_fixer_enable_default_mapping == 1)
    nnoremap <silent><leader>pcd :call PhpCsFixerFixDirectory()<CR>
    nnoremap <silent><leader>pcf :call PhpCsFixerFixFile()<CR>
endif

可以发现

pcd是格式化目录

pcf是格式化文件

现在可以把pcd,和pcf换成自己喜欢的快捷键了

ps:是nomal模式,是一个快捷键的前缀默认是\,可在vim中用map命令查看

附录

psr0 [PSR-0] Classes must be in a path that matches their namespace, be at least one namespace deep, and the class name should match the file name.

encoding [PSR-1] PHP code MUST use only UTF-8 without BOM (remove BOM).

short_tag [PSR-1] PHP code must use the long <?php ?> tags or the short-echo <?= ?> tags; it must not use the other tag variations.

braces [PSR-2] The body of each structure MUST be enclosed by braces. Braces should be properly placed. Body of braces should be properly indented.

elseif [PSR-2] The keyword elseif should be used instead of else if so that all control keywords looks like single words.

eof_ending [PSR-2] A file must always end with a single empty line feed.

function_call_space [PSR-2] When making a method or function call, there MUST NOT be a space between the method or function name and the opening parenthesis.

function_declaration [PSR-2] Spaces should be properly placed in a function declaration.

indentation [PSR-2] Code MUST use an indent of 4 spaces, and MUST NOT use tabs for indenting.

line_after_namespace [PSR-2] There MUST be one blank line after the namespace declaration.

linefeed [PSR-2] All PHP files must use the Unix LF (linefeed) line ending.

lowercase_constants [PSR-2] The PHP constants true, false, and null MUST be in lower case.

lowercase_keywords [PSR-2] PHP keywords MUST be in lower case.

method_argument_space [PSR-2] In method arguments and method call, there MUST NOT be a space before each comma and there MUST be one space after each comma.

multiple_use [PSR-2] There MUST be one use keyword per declaration.

parenthesis [PSR-2] There MUST NOT be a space after the opening parenthesis. There MUST NOT be a space before the closing parenthesis.

php_closing_tag [PSR-2] The closing ?> tag MUST be omitted from files containing only PHP.

single_line_after_imports [PSR-2] Each namespace use MUST go on its own line and there MUST be one blank line after the use statements block.

trailing_spaces [PSR-2] Remove trailing whitespace at the end of non-blank lines.

visibility [PSR-2] Visibility MUST be declared on all properties and methods; abstract and final MUST be declared before the visibility; static MUST be declared after the visibility.

blankline_after_open_tag [symfony] Ensure there is no code on the same line as the PHP open tag and it is followed by a blankline.

concat_without_spaces [symfony] Concatenation should be used without spaces.

double_arrow_multiline_whitespaces [symfony] Operator => should not be arounded by multi-line whitespaces.

duplicate_semicolon [symfony] Remove duplicated semicolons.

empty_return [symfony] A return statement wishing to return nothing should be simply "return".

extra_empty_lines [symfony] Removes extra empty lines.

include [symfony] Include and file path should be divided with a single space. File path should not be placed under brackets.

join_function [symfony] Implode function should be used instead of join function.

list_commas [symfony] Remove trailing commas in list function calls.

multiline_array_trailing_comma [symfony] PHP multi-line arrays should have a trailing comma.

namespace_no_leading_whitespace [symfony] The namespace declaration line shouldn‘t contain leading whitespace.

new_with_braces [symfony] All instances created with new keyword must be followed by braces.

no_blank_lines_after_class_opening [symfony] There should be no empty lines after class opening brace.

no_empty_lines_after_phpdocs [symfony] There should not be blank lines between docblock and the documented element.

object_operator [symfony] There should not be space before or after object T_OBJECT_OPERATOR.

operators_spaces [symfony] Binary operators should be arounded by at least one space.

phpdoc_indent [symfony] Docblocks should have the same indentation as the documented subject.

phpdoc_no_access [symfony] @access annotations should be omitted from phpdocs.

phpdoc_no_empty_return [symfony] @return void and @return null annotations should be omitted from phpdocs.

phpdoc_no_package [symfony] @package and @subpackage annotations should be omitted from phpdocs.

phpdoc_params [symfony] All items of the @param, @throws, @return, @var, and @type phpdoc tags must be aligned vertically.

phpdoc_scalar [symfony] Scalar types should always be written in the same form. "int", not "integer"; "bool", not "boolean"; "float", not "real" or "double".

phpdoc_separation [symfony] Annotations in phpdocs should be grouped together so that annotations of the same type immediately follow each other, and annotations of a different type are separated by a single blank line.

phpdoc_short_description [symfony] Phpdocs short descriptions should end in either a full stop, exclamation mark, or question mark.

phpdoc_to_comment [symfony] Docblocks should only be used on structural elements.

phpdoc_trim [symfony] Phpdocs should start and end with content, excluding the very first and last line of the docblocks.

phpdoc_type_to_var [symfony] @type should always be written as @var.

phpdoc_var_without_name [symfony] @var and @type annotations should not contain the variable name.

pre_increment [symfony] Pre incrementation/decrementation should be used if possible.

remove_leading_slash_use [symfony] Remove leading slashes in use clauses.

remove_lines_between_uses [symfony] Removes line breaks between use statements.

return [symfony] An empty line feed should precede a return statement.

self_accessor [symfony] Inside a classy element "self" should be preferred to the class name itself.

single_array_no_trailing_comma [symfony] PHP single-line arrays should not have trailing comma.

single_blank_line_before_namespace [symfony] There should be exactly one blank line before a namespace declaration.

single_quote [symfony] Convert double quotes to single quotes for simple strings.

spaces_before_semicolon [symfony] Single-line whitespace before closing semicolon are prohibited.

spaces_cast [symfony] A single space should be between cast and variable.

standardize_not_equal [symfony] Replace all <> with !=.

ternary_spaces [symfony] Standardize spaces around ternary operator.

trim_array_spaces [symfony] Arrays should be formatted like function/method arguments, without leading or trailing single line space.

unalign_double_arrow [symfony] Unalign double arrow symbols.

unalign_equals [symfony] Unalign equals symbols.

unary_operators_spaces [symfony] Unary operators should be placed adjacent to their operands.

unused_use [symfony] Unused use statements must be removed.

whitespacy_lines [symfony] Remove trailing whitespace at the end of blank lines.

align_double_arrow [contrib] Align double arrow symbols in consecutive lines.

align_equals [contrib] Align equals symbols in consecutive lines.

concat_with_spaces [contrib] Concatenation should be used with at least one whitespace around.

ereg_to_preg [contrib] Replace deprecated ereg regular expression functions with preg. Warning! This could change code behavior.

header_comment [contrib] Add, replace or remove header comment.

long_array_syntax [contrib] Arrays should use the long syntax.

multiline_spaces_before_semicolon [contrib] Multi-line whitespace before closing semicolon are prohibited.

newline_after_open_tag [contrib] Ensure there is no code on the same line as the PHP open tag.

no_blank_lines_before_namespace [contrib] There should be no blank lines before a namespace declaration.

ordered_use [contrib] Ordering use statements.

php4_constructor [contrib] Convert PHP4-style constructors to
__construct. Warning! This could change code behavior.

phpdoc_order [contrib] Annotations in phpdocs should be ordered so that param annotations come first, then throws annotations, then return annotations.

phpdoc_var_to_type [contrib] @var should always be written as @type.

short_array_syntax [contrib] PHP arrays should use the PHP 5.4 short-syntax.

short_echo_tag [contrib] Replace short-echo <?= with long format <?php echo syntax.

strict [contrib] Comparison should be strict. Warning! This could change code behavior.

strict_param [contrib] Functions should be used with $strict param. Warning! This could change code behavior.
时间: 2024-08-09 10:40:33

vim php代码规范的相关文章

作业三: 代码规范、代码复审、PSP

(1) 是否需要有代码规范         1.这些规范都是官僚制度下产生的浪费大家的编程时间.影响人们开发效率, 浪费时间的东西.(反对) 答:首先编码规范 包括了编码风格和其它规范 一个团队遵守一些规范有很多的好处! (1). 遵守编码风格使代码更容易维护 (2). 编码风格使形成代码集体所有制(集体所有制的作用很大,它能有效的增大巴士因子——一个项目能承受多少个程序员被车撞了而不影响项目的正常进行) (3). 编码风格能消除那些长久的纷争(你不需要喜欢这种编码风格.如果你不喜欢里面的某条规

两人合作之代码规范

代码规范 现代软件经过几十年的发展,一个软件由一个人单枪匹马完成,已经很少见了,软件都是在相互合作中完成的.合作的最小单位是两个人,两个工程师在一起,做的最多的事情就是"看代码",每个人都能看"比人的代码",并且发表意见.但是每个人对于什么是"好"的代码规范未必认同,这时我们有必要给出一个基准线-----什么是好的代码规范和设计规范. 1,写干净整洁的代码 1.1 代码格式化,包括多级代码缩进.大括号(比如C系代码),为了提高代码的美观型和易读性

代码规范的重要性

一个规范的代码,通常能起到事半功倍的作用: 一.规范的代码可以促进团队合作 一个项目大多都是由一个团队来完成,如果没有统一的代码规范,那么每个人的代码必定会风格迥异.且不说会存在多个人同时开发同一模块的情况,即使是分工十分明晰的,等到要整合代码的时候也有够头疼的了.大多数情况下,并非程序中有复杂的算法或是复杂的逻辑,而是去读别人的代码实在是一件痛苦的事情.统一的风格使得代码可读性大大提高了,人们看到任何一段代码都会觉得异常熟悉.显然的,规范的代码在团队的合作开发中是非常有益而且必要的. 二.规范

最详细的 Swift 代码规范指南

1. 代码格式 1.1 使用四个空格进行缩进. 1.2 每行最多160个字符,这样可以避免一行过长. (Xcode->Preferences->Text Editing->Page guide at column: 设置成160即可) 1.3 确保每个文件结尾都有空白行. 1.4 确保每行都不以空白字符作为结尾 (Xcode->Preferences->Text Editing->Automatically trim trailing whitespace + Incl

项目经理的管理技巧-代码规范

一.系统里面存在的糟糕代码情况有: 1. 代码规范,命名规范和注释 2. 公用代码的抽取和封装 3. 性能低下的代码 4. 表现层.业务层.数据持久层位置存放混乱问题 二.问题 岗位调动,接手一个新的项目组.旧项目一踏糊涂,全部无规范和设计. 组成员各做各的,毫无团队协作能力,更别说团队凝聚力.简直不能更糟糕. 新项目.新成员,新项目重新做了明确规范和框架设计,但组员很多时候不能很好的按照规范进行开发 我有强迫症  三.开始犯的错误,也是最笨的做法 定时核查,自己看到不正确代码同时指出,让开发优

软工学习笔记——代码规范

上大学以来写了这几年的代码,却一直没怎么关注过代码规范相关的问题,直到软工课上讲了之后,才开始有所顾及.上课的时候回头看看自己写过的那些代码,真是丑死了,几个月前自己写的代码现在就已经读不懂了. 看了书上的相关章节,对于我来说,我觉得我的代码主要注意这几点: 1. 少写冗余代码,已经用不到的代码段就应该删去.(我今天刚刚发现我的昆特牌Online项目中竟然还存在有两个没用的类) 2. 多利用空行来将代码小规模地分段. 3. 大段的无用代码不要一直注释着,该删就删.(我的项目里经常会有一大堆没用的

代码规范

1.这些规范都是官僚制度下产生的浪费大家的编程时间.影响人们开发效率, 浪费时间的东西 一个项目大多都是由一个团队来完成,如果没有统一的代码规范,那么每个人的代码必定会风格迥异.且不说会存在多个人同时开发同一模块的情况,即使是分工十分明晰的,等到要整合代码的时候也有够头疼的了.大多数情况下,并非程序中有复杂的算法或是复杂的逻辑,而是去读别人的代码实在是一件痛苦的事情.统一的风格使得代码可读性大大提高了,人们看到任何一段代码都会觉得异常熟悉. 2.我是个艺术家,手艺人,我有自己的规范和原则 每一个

作业三:代码规范

对于是否需要有代码规范,请考虑下列论点并反驳/支持: 1. 这些规范都是官僚制度下产生的浪费大家的编程时间.影响人们开发效率, 浪费时间的东西. 对于以上观点我是反对的 .如果说这些规范都是官僚制度产生的,那么更应该一丝不苟的执行,官僚制度,往大了说是法,应该无条件执行,往小了说是规范,可以帮助我们规范在打代码时自身不好的习惯.也许在编辑代码时,会比随意敲打耽误些许时间,但在检查错误时,规矩的编排格式,可以一目了然的看到自己的错误,为自己节省了更多的时间,会提高开发效率. 2. 我是个艺术家,手

作业三 (一) :是否需要有代码规范

这个作业主要是讨论代码规范的,围绕以下几个问题讨论 1.这些规范都是官僚制度下产生的浪费大家的编程时间.影响人们开发效率, 浪费时间的东西. 答:首先编码规范 包括了编码风格和其它规范 一个团队遵守一些规范有很多的好处! (1). 遵守编码风格使代码更容易维护 (2). 编码风格使形成代码集体所有制(集体所有制的作用很大,它能有效的增大巴士因子——一个项目能承受多少个程序员被车撞了而不影响项目的正常进行) (3). 编码风格能消除那些长久的纷争(你不需要喜欢这种编码风格.如果你不喜欢里面的某条规