• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
PHP Developer Coding Standards
 

PHP Developer Coding Standards

on

  • 7,031 views

PHP Developer Coding Standards, presented to Burlington, VT PHP UG on 23 April 2008. First in a series of PHP Developer Best Practices presentations.

PHP Developer Coding Standards, presented to Burlington, VT PHP UG on 23 April 2008. First in a series of PHP Developer Best Practices presentations.

Statistics

Views

Total Views
7,031
Views on SlideShare
6,804
Embed Views
227

Actions

Likes
7
Downloads
233
Comments
0

8 Embeds 227

http://milkythinking.com 107
http://www.mostofreddy.com.ar 84
http://www.linkedin.com 16
http://www.slideshare.net 15
url_unknown 2
http://feed.feedsky.com 1
http://translate.googleusercontent.com 1
https://www.linkedin.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as OpenOffice

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

PHP Developer Coding Standards PHP Developer Coding Standards Presentation Transcript

      • PHP Developer Best Practices Burlington, VT PHP UG
      • 23 April 2008
    Matthew Weier O'Phinney Software Architect Zend Technologies, Ltd.
  • About Me
    • Software Architect, Zend Framework
      • Development Lead: MVC, Zend_Form, Server components
      • Scope Releases
      • Promote and Implement best practices for team and contributors
    • Open Source Contributor
      • PEAR
      • Solar
      • Cgiapp
  • About You
    • Can you read your own code? Can others?
    • Is your software tested?
    • Is your software documented?
    • Are you using source control?
    • Does your team work efficiently?
    • Do you push buggy software into production?
    • Do you have a deployment plan? Does it include contingencies for rollbacks?
  • What we'll cover tonight Coding Standards
  • Purpose of Coding Standards
    • Efficiency
    • Maintainability
    • Collaboration
  • Efficiency
    • You know you don't have a standard when:
      • You always need to reformat code originating with others
      • Code you wrote 6 months ago has a different visual structure than code you write today
      • Whenever you modify old code, it breaks -- usu. due to newly introduced syntax errors
        • e.g., missing braces in conditionals, missing commas in lists, etc.
  • Maintainability
    • When following a coding standard, your code has a predictable layout both in the file system and in the layout. Easier to read code is easier to:
    • understand
    • maintain
    • refactor
  • Collaboration When a team follows a coding standard, any individual developer can pick up another developer's code and understand it, which will help them maintain and possibly refactor it. This leads to more efficient development... and thus happier customers.
  • Coding Standards Provide...
    • Consistency of file system layout
    • Consistency of code layout
  • Use Public Standards Don't invent your own standard for you or your company. You are not special, and your PHP source code is not unique. Others have already argued the issues and you can benefit from their collective knowledge.
  • Why use a public standard?
    • Objectivity
      • Choices are no longer based on subjective preferences, but on empirical experience.
    • Requirement when hiring or outsourcing
      • Easily judge the candidate experience and code quality.
    • Compatibility
      • Use a standard that follows that of the libraries you use.
  • What Choices Exist?
    • PEAR Coding Standards*
    • Zend Framework Coding Standards
    • eZcomponents Coding Standards
    • PHPLIB
      • * PEAR CS actually derives from Horde
  • What We'll Cover
    • PEAR
      • PEAR standards are the most widely used and accepted coding standards, in large part due to the number of people using PEAR as well as the general quality and explicitness of the standard.
    • Zend Framework
      • Only to note the additions it makes to PEAR standards.
  • PEAR Overview
    • Popular component library
    • Issues have already been debated
    • Well known and accepted (used more than any other standard)
    • Basis for many other projects
      • Horde (actually, based on Horde)
      • Solar
      • Zend Framework
      • AdoDB
  • PEAR Naming Conventions
    • Class Names
      • MixedCase
      • Initial Cap
      • Underscores separate logical package and code boundaries
    • Examples
      • Spreadsheet_Excel_Writer
      • Services_Google_AdWords
  • PEAR Naming Conventions
    • Files
      • 1:1 correspondence between class name and file name; one class per file
      • '.php' suffix
      • Class name underscores become directory separators
        • Spreadsheet_Excel_Writer
        • Spreadsheet/Excel/Writer.php
      • No loose PHP code
  • PEAR Naming Conventions
    • Variables
      • camelCased
      • initial character lowercase
    • Constants
      • ALL_CAPS
      • underscores for word separators
    • Private and protected properties
      • initial _underscore prefixes variable name
  • PEAR Naming Conventions
    • Functions and Methods
      • camelCased
      • Initial character lowercase
    • Private and protected methods
      • Initial _underscore
  • PEAR Code Formatting
    • Indentation
      • Spaces only; no tabs
      • Four (4) spaces per level of indentation
      • Purpose is consistency of viewing
      • looks the same regardless of editor
    • Line length
      • Suggested 75-85 character limit
    • No shell comments (#)
  • PEAR Block Formatting
    • One True Brace
      • Functions and Classes have the opening brace on the line following the declaration, at the same indent level
      • Control structures keep the opening brace on the same line as the declaration
    • All control structures use braces, no exceptions
  • PEAR Coding Standards
    • More information
    • Current standards:
      • http://pear.php.net/manual/en/standards.php
    • Proposed standards for PEAR2:
      • http://pear.php.net/manual/en/pear2cs.php
  • Zend Coding Standards
    • Follow PEAR for the most part
    • Additions
      • Omit closing ?> on any file containing only PHP code
      • Abstract and Interface classes
        • Should contain the keyword in the class name
          • Zend_Form_Decorator_Interface
          • Zend_Form_Decorator_Abstract
    • More information:
      • http://framework.zend.com/manual/en/coding-standard.html
  • Summary
    • Use a public coding standard
    • Use it always