安装
 

 wget -c 
 http://static.phpmd.org/php/latest/phpmd.phar
 

 mv phpmd.phar /usr/bin/phpmd
 

 chmod +x /usr/bin/phpmd
 
  
 

  使用：
 
 
 

  # phpmd 代码路径 报告格式 规则xml文件  并使用 > 命令将问题报告输出到文件
 
 
 

  eg:
  
 
 
 
 

  phpmd /Library/WebServer/Documents/php/app/ html codesize,unusedcode,naming > ~/Desktop/res.html
 
 
 

  
 
  
 #使用选项
  
 
  

   zjs:php jun$ phpmd
  
 
  

   Mandatory arguments:
  
 
  

   1) A php source code filename or directory. Can be a comma-separated string
  
 
  

   2) A report format
  
 
  

   3) A ruleset filename or a comma-separated string of rulesetfilenames
  
 
  

   
 
  
 
  

   
 
  
 
  

   Available formats: xml, text, html.
  
 
  

   Available rulesets: cleancode, codesize, controversial, design, naming, unusedcode.
  
 
  

   
 
  
 
  

   
 
  
 
  

   Optional arguments that may be put after the mandatory arguments:
  
 
  

   --minimumpriority: rule priority threshold; rules with lower priority than this will not be used
  
 
  

   --reportfile: send report output to a file; default to STDOUT
  
 
  

   --suffixes: comma-separated string of valid source code filename extensions, e.g. php,phtml
  
 
  

   --exclude: comma-separated string of patterns that are used to ignore directories
  
 
  

   --strict: also report those nodes with a @SuppressWarnings annotation
  
 
  

   --ignore-violations-on-exit: will exit with a zero code, even if any violations are found
  
 
  
 
 
 

之前在学校的时候，写的代码基本都是自己看、自己用，没有协同开发的问题，也不用接着别人的代码继续开发，所以就没有认识到代码规范性的重要性。
 
去企业之后，很多时候都是在现有项目的基础上进行继续开发。来新浪微博之后，就是这样。给我的第一个任务是制作微博现场的生成工具，就是在前人开发的代码基础上，进行修改和添加功能。
 
那么，我要开始吐槽了！代码写的真渣啊！人见人骂！没注释，没文档，命名不规范，还有各种坑，害我遇到各种莫名其妙的bug。我第一周什么也没干，就在看代码。
 
造成这种问题的原因，我想大概跟新浪的企业文化有关吧。上次听一个机器学习的讲座，主持人说新浪是一家务实的公司，所谓务实就是只要功能或者需求都实现就可以了，而不管是如何是实现的。
 
那么具体到代码质量问题上，只关心功能是不是都实现了，而不太在意代码的质量高不高。所以，新浪的代码是没有code review这个质量控制环节的。比如我开发的代码，线下测试所有功能没有问题了，就可以上线了。
 
己所不欲勿施于人，己所欲施于人。一个项目往往是由很多波程序员来完成的，低质的代码对于之后的继续开发是非常大的困难。所以，以后我写的代码一定要有清晰的注释、规范的命名、美观的格式。
 
愿所有程序员都能自觉要求自己，让天下没有难读的代码！程序员们一定要相爱相惜啊！

最近为了规范化代码风格，项目组内启用了VSCode插件eslint，了解eslint的同学都知道，它是在 ECMAScript/JavaScript 代码中识别和报告模式匹配的工具，给出一些代码规范建议，其目的是为了保证代码的一致性和避免一些可能出现的错误。在许多方面，它和 JSLint、JSHint 相似。比如，在书写下面的代码时会提示警告（见下图中波浪线）：
 
 
其中的错误信息是json字符串结构，具体内容如下：
 
{
	"resource": "/g:/project/*/main.js",
	"owner": "eslint",
	"code": {
		"value": "camelcase",
		"target": {
			"$mid": 1,
			"external": "https://eslint.org/docs/rules/camelcase",
			"path": "/docs/rules/camelcase",
			"scheme": "https",
			"authority": "eslint.org"
		}
	},
	"severity": 8,
	"message": "Identifier 'indexURL_test' is not in camel case.",
	"source": "eslint",
	"startLineNumber": 91,
	"startColumn": 7,
	"endLineNumber": 91,
	"endColumn": 20
}
 
意思就是没有使用驼峰命名法，根据提示建议，修改如下：
 
 
警告⚠️消失了，其实，这并不是说之前的写法有什么错误。eslint之所以给出相应的提示是为了在多人维护同一份代码或工程时，能够统一命名规范，这样能够便于大家互相理解彼此代码的意思，提升工作效率。当然，这只是一种警告和提示而已，你也可以不理睬，但是这样的话就失去了你启用这个插件的意义。
 
实际项目中，可以做一定的取舍。毕竟不能因为eslint而影响了撸码的心情。

 “代码的规范性与软件缺陷是有紧密联系的，质量高的代码将直接提高软件的质量”。相信每一个软件企业的研发部门都有类似于《XX语言开发规范》的文档，但究竟有多少人会去认真阅读、吃透其中的每一条款，并把其做为代码书写的“圣经”来对待(稍有违反规范的代码将及时重写)?我们需要“用技术手段去解决技术问题”。让我们在最关键的环节—代码仓库SVN—“做手脚”。试想，如果我们能在svn上增加一项功能，在程序员提交代码时进行规范性检查，如果没有通过，将拒绝代码的提交。这将使程序员无法回避“自己所犯的错误”。
 
 　　技术实现框架
 
 
 
 　　在SVN所在服务器安装一个用于代码检查的工具，此处选择checkstyle(一个开源的著名代码检查工具，可以自定义规则)。如何在commit事件发生的时候调起代码检查工具呢?此处运用svn的hook功能。Svn内置了钩子功能，当有事件发生的时候将自动调起一个程序。我们可以定制这段程序以实现自己的想要的功能。可以接受的事件包括：提交、加锁、解锁、改变等。以“提交”事件举例，当提交事件发生之前将执行hooks中的pre-commit脚本，提交事件之后将执行hooks中的post-commit脚本。于是我们就可以在pre-commit脚本里加入执行checkstyle的命令。此处我们再扩展一下，不直接执行checkstyle，而是先执行一个叫SVNChecker的工具，借助SVNChecker执行CheckStyle。SVNChecker是一个开源的检查框架，他可以做各种检查(不仅仅是代码规范性)，并针对各种检查匹配处理模块。也就是说目前虽然只是进行“代码规范性检查”，但是加入SVNChecker后，今后若想进行其他检查，就可以轻而易举的扩展了。
 
 　　安装checkstyle
 
 　　　　Checkstyle官方主页：http://checkstyle.sourceforge.net/
 　　　　Checkstyle下载页面：http://sourceforge.net/projects/checkstyle/files/checkstyle/5.3/
 
 　　请到以上页面去下载checkstyle-5.3-bin.zip，并上传到SVN服务器，解压。解压后目录结构如下：
 
  
 
 　　安装svnchecker
 
 　　SVNChecker官方主页：http://svnchecker.sourceforge.net/overview.php
 
 　　请到以上页面去下载svnchecker-0.3.tar.gz，并上传到SVN服务器，解压。解压后目录结构如下：
 
 
 
 　　配置checkstyle检查规则
 
 　　Checkstyle的规则配置文件为xml格式，其定义规则可以到checkstyle主页去查看，其内置了常用的规则，也可以自定义扩展。同时初始安装后自带sun_checks.xml(按照sun的java开发规范定义)，免去自定义的麻烦。但是此规则很全，不适用于企业的实际情况。
 
 　　下面是一段检查规则——“包名只允许出现小写字母”
 
 
 

                  
  <
  module 
  name
  ="PackageName"
  >
  
 
                          
  <
  property 
  name
  ="format"
   value
  ="^[a-z]+(\.[a-z]*)*$"
  />
  
 
                  
  </
  module
  >
 
 
 
  　　配置svnchecker检查项
 
 　　SVNChecker也可以灵活配置，包括：
 
 　　　　1. 针对被检查代码的路径进行设置，做到只检查需要检查的代码
 　　　　2. 对如何检查和如何处理进行配置
 　　　　3. 对检查规则进行配置
 　　　　4. 对成功和失败输出进行配置
 
 　　这些都保存在svncheckerconfig.ini文件中，可参考相关文档进行设置。
 
 　　下面是一段配置：
 
 
 

  [PROJECT]
  
 Main.Regex=^/appfront/src/main/java/
  
 Main.PreCommitChecks=Checkstyle
  
 Checkstyle.FailureHandlers=Console
  
 Checkstyle.Java=/usr/bin/java
  
 Checkstyle.Classpath=$CHECKSTYLE_PATH/checkstyle-5.3-all.jar
  
 Checkstyle.ConfigFile=$CHECKSTYLE_PATH/checks.xml
 
 
 
  　　对^/appfront/src/main/java/下的文件进行检查，其他文件过滤。检查器为checkstyle。失败时将把信息输出到标准输出。Checkstyle执行的java命令路径为/usr/bin/java，要加载$CHECKSTYLE_PATH/checkstyle-5.3-all.jar，检查规则文件路径为$CHECKSTYLE_PATH / checks.xml
 
 　　修改pre-commit hook
 
 　　最后，一切设置好后，最关键的就是修改钩子程序了。加入语句：
 
 　　$SVNCHECKER_PATH/Main.py PreCommit $1 $2 || exit 1
 
 　　当然不要忘记了赋予此文件的执行权限。
 
 　　总结
 
 　　当有代码提交时，此检查框架将运行，保证违反规则的代码被拒绝。程序员的将看到类似如下的信息：
 
  
 
 　　修改代码后即可提交。
 
 　　根据我企业对此框架的运用总结的经验如下：
 
 　　1. 不要一次把所有规则都加入，循序渐进，分多批次添加。否则开发人员的修改量会很大。
 
 　　2. Svnchecker本身会有些bug，有时候需要手工改svnchecker的代码实现自己的需求。
 
 　　3. Svnchecker项目已不维护，改为RepoGuard(http://repoguard.tigris.org/)，有兴趣的同学可以进一步研究此框架。
 
 　　4. 既然决定用此技术来规范起代码，那么就应该坚持的走下去，即使开发人员提出是否可以放宽要求，也要坚持自己的原则。