Entries tagged as quality assuranceRelated tags annotations customization phpmd release announcement rule set static code analysis cbo coupling between objects php_depend software metrics checkstyle continuous integration cruisecontrol cyclomatic complexity design quality npath complexity php phpunit php_codesniffer pmd class interface size cli bug fix phpundercontrol usability conference hamburg phpugdo unconference ant arbit css dashboard ezcomponents java server pages layout lint php5 phpdoc sebastian marek testing tutorial torii portal ipc karlsruhe kore talks overview pyramid software architecture software design ext/filter phpt unit test apache software foundation book consulting qafoo toby zeta components logger optimization performance changes company crazy dortmund elephpant fabien potencier fun phpbbq phpug pirum quality static_reflection support thinkpad tools training xml xpath zce zend certified engineer git github sylvester 2007 elger mayflower php_codebrowser thorsten dbus derick tokenizer article cologne php-magazin customerMonday, March 21. 2011PHPMD 1.1.0 released
Version 1.1.0 of PHPMD was released on March the 20th 2011. The key features
for this release were two new rules. The first one utilizes the Coupling
Between Objects (CBO) metric to detect strongly coupled classes. The second
one detects the usage of PHP's questionable FeaturesBugfixes
DownloadYou can download release 1.1.0 through PHPMD's PEAR Channel Server or you can download the release as a Phar archive 
Tuesday, March 15. 2011A brief introduction to the Coupling Between Objects metricIn this blog post I will give you a brief introduction into the Coupling Between Objects metric, that is one of the metrics calculated by the static code analysis tool PHP_Depend. The Coupling Between Objects or CBO metric was originally defined by Chidamber & Kemerer in their IEEE paper "A Metrics Suite for Object Oriented Design" [1]. This software metric represents the number of other types a class or interface is coupled to. The CBO metric is calculated for classes and interfaces. It counts the unique number of reference types that occur through method calls, method parameters, return types, thrown exceptions and accessed fields. But there is an exception for types that are either a subtype or supertype of the given class, because these types are not included in the calculated CBO value. Excessive coupled classes prevent reuse of existing components and they are damaging for a modular, encapsulated software design. To improve the modularity of a software the inter coupling between different classes should be kept to a minimum. Beside reusability a high coupling has a second drawback, a class that is coupled to other classes is sensitive to changes in that classes and as a result it becomes more difficult to maintain and gets more error-prone. Additionally it is harder to test a heavly coupled class in isolation and it is harder to understand such a class. Therefore you should keep the number of dependencies at a minimum. ThresholdsBased on their research Sahraoui, Godin and Miceli [2] suggest a maximum CBO value of 14, because higher values have negative impacts on several quality aspects of a class, which includes the maintainability, stability and understandability. See also
Bibliography
Posted by Manuel Pichler
in php, php_depend, phpugdo, planet-php, projects
at
11:59
| Comment (1)
| Trackbacks (0)
Defined tags for this entry: cbo, coupling between objects, php_depend, quality assurance, software metrics
Monday, February 28. 2011PHP_Depend 0.10.2 releasedWe are proud to announce release 0.10.2 of PHP_Depend. Beside two bug fixes this release implements four new software metrics:
A detailed CHANGELOG can be found on the project's download page and a complete, detailed description of the newly implemented software metrics in PHP_Depend's metric catalog.
Posted by Manuel Pichler
in php, php_depend, planet-php, projects
at
11:25
| Comments (0)
| Trackbacks (0)
Friday, February 25. 2011Brief introduction to the Class Interface Size metricThis blog post will give you a brief introduction into the Class Interface Size metric, as it is calculated by the static code analysis tool PHP_Depend. The Class Interface Size or CIS metric is measure of the public services that a class provides. This metric was orginally defined in the QMOOD model [1] by Bansiya & Davis. The orginal version of the CIS metric was defined as the number of public methods that a class provides. Each of these methods can be seen as a service where surrounding application can send messages to or receive messages from a class. CIS = public(NOM) A newer variant of the CIS metric also includes the public attributes of a class, because theses properties can also be used to transport messages or information between a class and the surrounding application. CIS = public(NOM) + public(VARS) PHP_Depend uses the second variant and counts all public methods and attributes declared in a class to calculate its Class Interface Size metric. This metric is a good indicator for the choosen software design. Several classes with a high CIS value are a sure sign that the design of the analyzed software prefers composition over inheritance to share common functionality between different components. So in most cases a high value is a good a sign, because composition increases the reusability and flexibility. But there are also situations where wrongly used composition of functionality leads to a design that is harder to understand and maintain. Thresholds
It is not easy to define good thresholds for this metric, because those values
heavy depend on the choosen design, e.g. inheritance or composition. But in
generall we can say that is best practice to limit the public interface that
can be used to alter the internal state of an object. Therefore we suggest
Bibliography
Sunday, August 22. 2010Slides of my "Understanding Software Metrics" talk online
Posted by Manuel Pichler
in php
at
10:34
| Comments (2)
| Trackbacks (0)
Defined tags for this entry: conference, cyclomatic complexity, npath complexity, quality assurance, software metrics
Thursday, April 8. 2010Howto create custom rule sets for PHPMDIn this blog post I will describe a useful feature in PHPMD that will simplify your life when it comes to create custom rule sets for PHPMD. PHPMD can be seen as an one level down/low level equivalent to PHP_CodeSniffer. It is a simple command line tool that can be used to check your application's source code for possible bugs, suboptimal or overcomplicated code. The current release of PHPMD ships with three default rule sets. The first set of rules tests the codesize of class, methods and functions. The second rule set contains rules that check your code for unused variables, methods etc. and finally there is a rule set that tests the code against some naming conventions. Normally when you start using a quality assurance tool, you will not want to use it's default configuration. Sometimes you would like to use only a subset, because the full stack will produce too much noise, or you would like to customize some thresholds, because the factory defaults do not fit to your environment. In this blog post I give a short introduction into PHPMD's rule set syntax and howto to create your own rule set, by reusing parts of the existing default configuration. If you would like to only pick some of the rules that come with PHPMD and you want to customize some of the predefined thresholds, you can do this by creating your own rule set file that references a custom collection of rules with an individual configuration. Starting with an empty ruleset.xml fileThe simpliest way to start with a new rule set is to copy one of the
existing files and remove all the rule-tags from the document body.
Otherwise you can use the following example as a template for your own
rule set file. You should change the content of the
<?xml version="1.0"?>
<ruleset name="My first PHPMD rule set"
xmlns="http://pmd.sf.net/ruleset/1.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://pmd.sf.net/ruleset/1.0.0
http://pmd.sf.net/ruleset_xml_schema.xsd"
xsi:noNamespaceSchemaLocation="
http://pmd.sf.net/ruleset_xml_schema.xsd">
<description>
My custom rule set that checks my code...
</description>
</ruleset>
Adding rule references to the new ruleset.xml fileThe first thing we would like to do is to add all unused code rules
to the new rule set file. This can simply be done with a
<?xml version="1.0"?>
<ruleset name="My first PHPMD rule set"
xmlns="http://pmd.sf.net/ruleset/1.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://pmd.sf.net/ruleset/1.0.0
http://pmd.sf.net/ruleset_xml_schema.xsd"
xsi:noNamespaceSchemaLocation="
http://pmd.sf.net/ruleset_xml_schema.xsd">
<description>
My custom rule set that checks my code...
</description>
<!-- Import the entire unused code rule set -->
<rule ref="rulesets/unusedcode.xml" />
</ruleset>
That's it. Now the custom rule set applies all unused code rules against the analyzed source code. We would also like to use the cyclomatic complexity rule from the
existing codesize set in our custom rule set. To achieve this we can
reuse the same syntax with a
<?xml version="1.0"?>
<ruleset name="My first PHPMD rule set"
xmlns="http://pmd.sf.net/ruleset/1.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://pmd.sf.net/ruleset/1.0.0
http://pmd.sf.net/ruleset_xml_schema.xsd"
xsi:noNamespaceSchemaLocation="
http://pmd.sf.net/ruleset_xml_schema.xsd">
<description>
My custom rule set that checks my code...
</description>
<!-- Import the entire unused code rule set -->
<rule ref="rulesets/unusedcode.xml" />
<!-- Import the entire cyclomatic complexity rule -->
<rule ref="rulesets/codesize.xml/CyclomaticComplexity" />
</ruleset>
Now that the new rule set uses the cyclomatic complexity rule we would
also like to customize some of the rule's properties. First we will
increase the rule's priority to the highest possible priority value
<?xml version="1.0"?>
<ruleset name="My first PHPMD rule set"
xmlns="http://pmd.sf.net/ruleset/1.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://pmd.sf.net/ruleset/1.0.0
http://pmd.sf.net/ruleset_xml_schema.xsd"
xsi:noNamespaceSchemaLocation="
http://pmd.sf.net/ruleset_xml_schema.xsd">
<description>
My custom rule set that checks my code...
</description>
<!-- Import the entire unused code rule set -->
<rule ref="rulesets/unusedcode.xml" />
<!--
Import the entire cyclomatic complexity rule and
customize the rule configuration.
-->
<rule ref="rulesets/codesize.xml/CyclomaticComplexity">
<priority>1</priority>
<properties>
<property name="reportLevel" value="5" />
</properties>
</rule>
</ruleset>
You should know that PHPMD handles all custom settings additive. This means that PHPMD keeps the original configuration for every setting that isn't customized in a rule reference. Excluding rules from a rule setFinally we would like to reuse the naming rule set of PHPMD. But we
don't like the two variable naming rules, so that we must exclude them
from out rule set file. This exclusion can be achieved by declaring an
<?xml version="1.0"?>
<ruleset name="My first PHPMD rule set"
xmlns="http://pmd.sf.net/ruleset/1.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://pmd.sf.net/ruleset/1.0.0
http://pmd.sf.net/ruleset_xml_schema.xsd"
xsi:noNamespaceSchemaLocation="
http://pmd.sf.net/ruleset_xml_schema.xsd">
<description>
My custom rule set that checks my code...
</description>
<!-- Import the entire unused code rule set -->
<rule ref="rulesets/unusedcode.xml" />
<!--
Import the entire cyclomatic complexity rule and
customize the rule configuration.
-->
<rule ref="rulesets/codesize.xml/CyclomaticComplexity">
<priority>1</priority>
<properties>
<property name="reportLevel" value="5" />
</properties>
</rule>
<!-- Import entire naming rule set and exclude rules -->
<rule ref="rulesets/naming.xml">
<exclude name="ShortVariable" />
<exclude name="LongVariable" />
</rule>
</ruleset>
ConclusionWith PHPMD's rule set syntax it is possible to customize all aspects of rules for your own needs and you can reuse every existing rule set xml file in your own set. You should take a look at PHPMD's rule documentation if it happens that you don't know what rules exist or you don't know exactly, which settings are available for one rule, while you create your own set of rules. Another good source of information are the rule set files that are shipped with PHPMD. You can get the latest PHPMD version from its PEAR channel: pear.phpmd.org mapi@arwen ~ $ pear channel-discover pear.pdepend.org mapi@arwen ~ $ pear channel-discover pear.phpmd.org mapi@arwen ~ $ pear install --alldeps phpmd/PHP_PMD-alpha Or from our github repository: mapi@arwen ~ $ git clone git://github.com/manuelpichler/phpmd.git I would be glad if you file a ticket in PHPMD's issue tracker for all issues and/or enhancements you encounter while testing PHPMD.
Posted by Manuel Pichler
in php, phpmd, phpugdo, planet-php, projects
at
14:25
| Comments (0)
| Trackbacks (0)
Defined tags for this entry: annotations, customization, phpmd, quality assurance, rule set, static code analysis
Thursday, March 4. 2010PHPMD 0.2.3 released with @SuppressWarnings support and new rule set.We are proud to announce the 0.2.3 release of the PHP Mess Detector, a tool that takes source code and performs various tests to calculate various quality aspects from it. The measured values are a good starting point for future improvements. This release contains some new features, for example support for the @SuppressWarnings annotation, that allows you to exclude single methods or complete classes from PHPMD's analyzing process. This annotation can be used to suppress a single rule, a group of rules or PHPMD at all.
/**
* Suppress all PHPMD warnings for this class.
*
* @SuppressWarnings(PHPMD)
*/
class PHPMD_SuppressAll
{
}
class PHPMD_SuppressOnMethod
{
/**
* Do not warn about the unused parameter $bar.
*
* @SuppressWarnings(PHPMD.UnusedFormatParameter)
*/
public function foo($bar)
{
}
}
Beside several bugfixes this release comes with a new set of rules that check the naming of methods, variables etc. against common coding conventions and best practices.
You can get the latest PHPMD version from its PEAR channel: pear.phpmd.org mapi@arwen ~ $ pear channel-discover pear.pdepend.org mapi@arwen ~ $ pear channel-discover pear.phpmd.org mapi@arwen ~ $ pear install --alldeps phpmd/PHP_PMD-alpha Or from our github repository: mapi@arwen ~ $ git clone git://github.com/manuelpichler/phpmd.git
Posted by Manuel Pichler
in php, phpmd, phpugdo, projects
at
10:32
| Comments (0)
| Trackbacks (0)
Defined tags for this entry: annotations, phpmd, quality assurance, release announcement, static code analysis
Tuesday, February 23. 2010PHP_Depend-0.9.10 releasedI have just released the bug fix version 0.9.10 of PHP_Depend. This release contains several bug fixes and improvements for PHP_Depend.
As always, you can get the latest PHP_Depend version from its PEAR channel: pear.pdepend.org: mapi@arwen ~ $ pear channel-discover pear.pdepend.org mapi@arwen ~ $ pear install pdepend/PHP_Depend-beta Or you can fetch the sources from the subversion reposition: mapi@arwen ~ $ svn co http://svn.pdepend.org/branches/0.9.0/ And additionally you can find a repository mirror on github: mapi@arwen ~ $ git clone git://github.com/manuelpichler/pdepend.git
Posted by Manuel Pichler
in php, php_depend, phpugdo, planet-php, projects
at
20:36
| Comments (0)
| Trackbacks (0)
Defined tags for this entry: php, php5, php_depend, quality assurance, release announcement, software metrics, static code analysis
Tuesday, December 29. 2009PHP Mess Detector 0.2 released.Today I have released version 0.2.0 of the PHP Mess Detector or short PHPMD. PHPMD is a simple, customizable and user friendly frontend application for PHP_Depend. It takes the raw metrics measured by PHP_Depend, compares them with appropriate thresholds and generates a report that lists those software artifacts with potential problems. Such a report can be taken as a basis for human code audits or you can use it as input for an automated build/reporting tool. Most concepts behind PHPMD are based on those of the well known Java Tool PMD. It uses so called rule set files to organize different sets of rules. There are two purposes that are accomplished by these xml files. The first is to create custom sets of rules which fulfills the projects requirements. The second purpose is the configuration of each rule with thresholds, warning messages and other things. The format of these files is totally borrowed from PMD, so that the reuse existing rule sets in multi language environments should be easy. At the moment PHPMD has two build-in rule sets. One that detects software artifacts with high code size, and the second one detects unused code in your software.
Now lets start with a small How to use it. PHPMD can be called from the command line by typing mapi@arwen ~ $ phpmd Mandatory arguments: 1) A php source code filename or directory 2) A report format 3) A ruleset filename or a comma-separated string of ... Optional arguments that may be put after the mandato... --minimumpriority: rule priority threshold; rules with ... --reportfile: send report output to a file; default to ... --extensions: comma-separated string of valid source ... --ignore: comma-separated string of patterns that are ...
Now let's call PHPMD on its own source, with a simple text report on STDOUT and the mapi@arwen ~ $ phpmd ~/phpmd/source text codesize /home/mapi/phpmd/source/PHP/PMD/RuleSetFactory.php:66 \ This class has too many methods, consider refactoring it. /home/mapi/phpmd/source/PHP/PMD/RuleSetFactory.php:267 \ The method _parseSingleRuleNode() has a Cyclomatic \ Complexity of 11. /home/mapi/phpmd/source/PHP/PMD/RuleSetFactory.php:326 \ The method _parseRuleReferenceNode() has a Cyclomatic \ Complexity of 10.
The
mapi@arwen ~ $ phpmd ~/phpmd/source xml codesize,unusedcode \
--reportfile ~/pmd.xml
mapi@arwen ~ $ cat ~/pmd.xml
<?xml version="1.0" encoding="UTF-8" ?>
<pmd version="@package_version@" timestamp="...">
<file name=".../source/PHP/PMD/RuleSetFactory.php">
<violation beginline="66" endline="417" rule="TooManyMet ...>
This class has too many methods, consider refactoring it.
</violation>
<violation beginline="267" endline="315" rule="Cyclomati ...>
Method _parseSingleRule() has a Cyclomatic Complexity of 11.
</violation>
<violation beginline="326" endline="367" rule="Cyclomati ...>
Method _parseRuleReference() has a Cyclomatic Complexity of 10.
</violation>
</file>
</pmd>
This xml file is compatible with those files generated by PMD and PHPUnit's deprecated
Currently PHPMD supports the following three different report formats: Text, HTML and XML. And it has the build-in rule sets: You can get the latest PHPMD version from its PEAR channel: pear.phpmd.org mapi@arwen ~ $ pear channel-discover pear.pdepend.org mapi@arwen ~ $ pear channel-discover pear.phpmd.org mapi@arwen ~ $ pear install --alldeps phpmd/PHP_PMD-alpha
Posted by Manuel Pichler
in php, php_depend, phpmd, phpugdo, planet-php, projects
at
23:40
| Comments (2)
| Trackbacks (0)
Sunday, August 2. 2009PHP_Depend-0.9.6 releasedToday I released PHP_Depend 0.9.6, which contains many bug fixes and improvements, but the main feature of this release is behind the scene, I have started to migrate PHP_Depend's internal system from plain Token object to an Abstract Syntax Tree.
You can get the latest PHP_Depend version from its PEAR channel: pear.pdepend.org mapi@arwen ~ $ pear channel-discover pear.pdepend.org mapi@arwen ~ $ pear install pdepend/PHP_Depend-beta
Posted by Manuel Pichler
in php, php_depend, phpugdo, planet-php, projects
at
21:32
| Comment (1)
| Trackbacks (0)
Tuesday, July 7. 2009The value of complexity metrics - Cyclomatic Complexity (1/2)Software metrics are currently on everyone's lips and a frequently discussed topic. There are many conference talks, blog posts and other presentations that talk about software metrics. But to me it seems as if this subject is a closed book for many developers, so I decided to write this little post about a special category of software metrics, the complexity metrics. Complexity metrics are a theoretical approach to measure the subjective complexity of a software fragment, where the words software fragment stand for a paraphrase for functions, methods, classes and nearly every logical unit that can be found in a software system. The most prevalent procedure to calculate complexity values is static code analysis, where an application parses the raw source code of a project, counts different statements and expressions and packs up the determined results in simple classification numbers. And with this information you already know the main concepts behind most software metrics, classification numbers and counting. As you can see there is no magic behind the scene, the only thing required is a good background knowledge to interpret those values. The Cyclomatic Complexity Number or short CCN is the oldest complexity metrics. The first time this software metric was mentioned was 1976 by Thomas J. McCabe. This metric counts the available decision paths in a software fragment to determine its complexity. Each decision path starts with one of the conditional statements from the following list, so that it is fairly easy to detect them in existing source code.
A look at this list of statements may result in the questions:
Is this list wrong, it doesn't list Each decision path gets the value 1 and the sum of all these values represents the Cyclomatic Complexity of the analyzed software fragment. Note that each function and method also counts with a value of 1 With this knowlegde we can now calculate the complexity of the following example code:
Based on the previous definition the Cyclomatic Complexity
Number of the example code example is 5. But you may have
noticed that this approach does not capture all decision paths
that exist. We haven't catched those paths that came from the
by the boolean expression Now we get a complexity value of 8 when we apply the CCN2 to the previous example, what is a growt of the software's complexity of 60%.
Due to the fact that Cyclomatic Complexity Number was
originally invented for procedural programming languages,
this definition for the Cyclomatic Complexity Number still
misses one element to measure the complexity of an object
oriented software system. With the concept of exceptions a
software gets additional decision paths for each
Now that we know what the Cyclomatic Complexity Number is, what can we do with the measured information? We can find the complexity hotspots in a system, for example the top ten artifacts with the highest complexity, but this is only important during an initial analyses phase to get the big picture of an application. For a continuous inspection this information is not so important. A continuous analyses requires thresholds that help to categories calculated values. During the time four values have emerged as good thresholds for the Cyclomatic Complexity Number of a software system.
You may ask, why should I care about the complexity of a software system, where is the value of benefit in this metric? Mostly the complex parts of an application contain business critical logic. But this complexity has negative impacts on the readability and understandability of source code. Those parts will normally become a maintainence and bug fixing nightmare, because no one knows all the constraints, side effects and what's exactly going on in that part of the software. This situation results in the well known saying "Never touch a running system" which in turn mostly ends in copy&paste programming. The situation can even become more critical when the original author leaves the development team or the company. Finally a small example how to apply the new knowledge about the Cyclomatic Complexity Number, thresholds and the negative impacts of complex software to an existing development process. The following source listing shows a complex method taken from PHP_Depend's source. This method has a Cyclomatic Complexity Number of 16 and I must admit that the original author needed some time to understand what was going on in this method.
The first thing to do is to make sure that the test suite is good enough to ensure that the required refactorings will not change the public behavior of the component or class. When this is donw and we are sure our that api breaks will be detected by the test suitewe can start to extract logic into separate methods. The following example shows the result of the refactoring:
The subjective feeling of readability heavily depends on the complexity of control structures, as we can see by a comparison of the original and the refactored version of the method example. The new version with its Cyclomatic Complexity Number of 5 is much easier to read and understand. This text is the first of two blog posts. The second article will give a short introduction into the NPath Complexity You liked this article and you are interested in this and other quality assurence related topics? - Then you should now order your copy of the Book Quality Assurance in PHP Projects. The book talks about nearly all aspect of quality assurence, with practical tips and expert knowledge contributed by certain PHP professionals.
Posted by Manuel Pichler
in php, php_depend, phpugdo, phpundercontrol, planet-php, projects
at
21:20
| Comments (2)
| Trackbacks (0)
Defined tags for this entry: checkstyle, cyclomatic complexity, design quality, npath complexity, php_depend, quality assurance, software metrics
Monday, May 18. 2009PHP_Depend-0.9.5 releasedToday I released PHP_Depend 0.9.5, which contains many bug fixes and improvements. The main features of this release are PHP 5.3 namespace support and a more robust parser that ignores most kinds of syntax errors,
You can get the latest PHP_Depend version from its PEAR channel: pear.pdepend.org mapi@arwen ~ $ pear channel-discover pear.pdepend.org mapi@arwen ~ $ pear install pdepend/PHP_Depend-beta
Posted by Manuel Pichler
in php, php_depend, phpugdo, planet-php, projects
at
22:21
| Comments (0)
| Trackbacks (0)
Saturday, February 21. 2009PHP_Depend-0.9.4 releasedToday I released PHP_Depend 0.9.4, which contains many bug fixes and improvements.
You can get the latest PHP_Depend version from its PEAR channel: pear.pdepend.org mapi@arwen ~ $ pear channel-discover pear.pdepend.org mapi@arwen ~ $ pear install pdepend/PHP_Depend
Posted by Manuel Pichler
in php, php_depend, phpugdo, planet-php, projects
at
21:15
| Comment (1)
| Trackbacks (0)
Monday, January 19. 2009PHP_Depend-0.9.3 releasedJust now I released PHP_Depend 0.9.3, the primary goal for this release was focused on less memory consumption. A run of PHP_Depend 0.9.2 against eZ Publish took up to 1GB and PHP_Depend 0.9.3 analyzes the same source with a memory limit of 160Mb.
From now on you will get the latest PHP_Depend version through the new pear channel pear.pdepend.org, for a few weeks I will keep the old pear channel. Enter the following pear commands to upgrade PHP_Depend's channel. mapi@arwen ~ $ pear channel-discover pear.pdepend.org mapi@arwen ~ $ pear uninstall xplib/PHP_Depend mapi@arwen ~ $ pear install pdepend/PHP_Depend Or checkout version 0.9.3 from the PHP_Depend subversion repository. mapi@arwen ~ $ svn co http://svn.pdepend.org/tags/0.9.3
Posted by Manuel Pichler
in php, php_depend, phpugdo, planet-php, projects
at
21:44
| Comments (2)
| Trackbacks (0)
Defined tags for this entry: optimization, performance, php5, php_depend, quality assurance, release announcement
Friday, January 2. 2009PHP_Depend-0.9.2 releasedThis is a bug fix release of PHP_Depend. Version 0.9.2 fixes bug #84, which could result in a failure for all PHP versions lower than 5.3.0alpha2.
You can get the latest PHP_Depend version through its PEAR channel pear.xplib.de or as a subversion checkout of the 0.9.2 tag.
mapi@arwen ~ $ svn co http://svn.pdepend.org/tags/0.9.2
Posted by Manuel Pichler
in php, php_depend, phpugdo, projects
at
21:41
| Comments (0)
| Trackbacks (0)
(Page 1 of 2, totaling 29 entries)
» next page
|
ProjectsFurther stuffSee also
Categories |