Top Related Projects
Quick Overview
The php-fig/fig-standards repository is the official home of PHP Standards Recommendations (PSRs) developed by the PHP Framework Interop Group (PHP-FIG). It contains accepted PSRs, which are coding standards and best practices aimed at improving interoperability between PHP software components.
Pros
- Promotes consistency and interoperability across PHP projects
- Provides well-thought-out standards backed by industry experts
- Improves code quality and maintainability
- Facilitates easier collaboration between developers and projects
Cons
- Some standards may be controversial or not universally accepted
- Implementing standards can require significant refactoring of existing code
- Not all PSRs are relevant or applicable to every project
- The adoption process for new standards can be slow
Code Examples
This repository doesn't contain a code library, but rather documentation and specifications. Therefore, code examples are not applicable in this case.
Getting Started
As this is not a code library, there are no specific getting started instructions. However, developers can start implementing PSRs in their projects by reading the documentation and following the guidelines provided in the repository.
To learn more about PHP-FIG and PSRs, visit the official website: https://www.php-fig.org/
Competitor Comparisons
The Symfony PHP framework
Pros of Symfony
- Comprehensive full-stack framework with extensive features and components
- Active development and frequent updates
- Large community and ecosystem with extensive documentation
Cons of Symfony
- Steeper learning curve due to its complexity
- Potentially overkill for smaller projects
- More opinionated structure compared to FIG standards
Code Comparison
FIG Standards (PSR-4 autoloading example):
namespace Vendor\Package;
class ClassName
{
// ...
}
Symfony (Controller example):
namespace App\Controller;
use Symfony\Component\HttpFoundation\Response;
class DefaultController
{
public function index(): Response
{
return new Response('Hello, World!');
}
}
Summary
FIG Standards focuses on creating and maintaining PHP standards, while Symfony is a full-featured web application framework. FIG Standards provides guidelines for interoperability, whereas Symfony offers a complete development ecosystem. FIG Standards are more flexible and can be adopted by various projects, while Symfony provides a structured approach to building applications. Both projects contribute significantly to the PHP community, with FIG Standards improving overall code quality and Symfony offering powerful tools for rapid development.
The Laravel Framework.
Pros of Laravel Framework
- Comprehensive full-stack framework with built-in features
- Active development and frequent updates
- Large ecosystem with extensive documentation and community support
Cons of Laravel Framework
- Steeper learning curve for beginners
- Potentially heavier and more resource-intensive
- May include unnecessary features for smaller projects
Code Comparison
fig-standards (PSR-4 autoloading example):
<?php
namespace Vendor\Package;
class ClassName
{
// ...
}
Laravel Framework (Route definition example):
<?php
Route::get('/user/{id}', function ($id) {
return 'User '.$id;
});
Key Differences
- Fig Standards focuses on PHP interoperability guidelines
- Laravel Framework is a full-featured web application framework
- Fig Standards is language-agnostic, while Laravel is PHP-specific
- Laravel provides a complete development ecosystem
- Fig Standards aims to standardize PHP development practices
Use Cases
- Fig Standards: Best for projects requiring adherence to PHP standards
- Laravel Framework: Ideal for rapid development of full-stack web applications
Community and Support
- Fig Standards: Backed by PHP-FIG, widely adopted across PHP projects
- Laravel Framework: Large, active community with extensive third-party packages
Dependency Manager for PHP
Pros of Composer
- Actively maintained and frequently updated
- Provides practical functionality for dependency management
- Large community and extensive ecosystem of packages
Cons of Composer
- Focused on a specific task, not a broad set of standards
- May require more setup and configuration for projects
Code Comparison
fig-standards (PSR-4 autoloading example):
<?php
namespace Vendor\Package;
class ClassName
{
// ...
}
Composer (composer.json example):
{
"require": {
"vendor/package": "1.3.2",
"vendor/package2": "1.*",
"vendor/package3": "^2.0.3"
}
}
Summary
Fig Standards focuses on defining coding standards and best practices for PHP development, while Composer is a dependency management tool. Fig Standards provides guidelines for code structure and interoperability, whereas Composer offers practical implementation for managing project dependencies. Both projects contribute significantly to the PHP ecosystem, with Fig Standards shaping the language's development practices and Composer simplifying package management for developers.
Guzzle, an extensible PHP HTTP client
Pros of Guzzle
- Provides a complete HTTP client library for PHP
- Offers extensive features for making HTTP requests and handling responses
- Actively maintained with regular updates and improvements
Cons of Guzzle
- Larger codebase and more complex than FIG Standards
- Specific to HTTP client functionality, not a general-purpose standard
Code Comparison
FIG Standards (PSR-7 HTTP Message Interface):
interface RequestInterface extends MessageInterface
{
public function getRequestTarget();
public function withRequestTarget($requestTarget);
public function getMethod();
public function withMethod($method);
public function getUri();
}
Guzzle (HTTP Client Usage):
use GuzzleHttp\Client;
$client = new Client();
$response = $client->request('GET', 'https://api.github.com/repos/guzzle/guzzle');
$body = $response->getBody();
$decoded = json_decode($body);
Summary
FIG Standards focuses on defining PHP standards and best practices, while Guzzle is a specific implementation of an HTTP client library. FIG Standards provides guidelines for interoperability, whereas Guzzle offers ready-to-use functionality for making HTTP requests. Both projects serve different purposes in the PHP ecosystem, with FIG Standards being more abstract and Guzzle being more practical for specific use cases.
Doctrine Object Relational Mapper (ORM)
Pros of Doctrine ORM
- Provides a robust Object-Relational Mapping (ORM) solution for PHP
- Offers powerful database abstraction and query building capabilities
- Supports multiple database systems and complex relationships between entities
Cons of Doctrine ORM
- Steeper learning curve compared to FIG Standards
- More complex setup and configuration required
- May introduce performance overhead for simple database operations
Code Comparison
FIG Standards (PSR-4 example):
<?php
namespace Vendor\Package;
class ClassName
{
// Class implementation
}
Doctrine ORM (Entity example):
<?php
namespace App\Entity;
use Doctrine\ORM\Mapping as ORM;
#[ORM\Entity]
class Product
{
#[ORM\Id]
#[ORM\GeneratedValue]
#[ORM\Column]
private ?int $id = null;
}
Summary
FIG Standards focuses on PHP coding standards and best practices, while Doctrine ORM is a full-fledged ORM solution. FIG Standards is more about consistency across PHP projects, whereas Doctrine ORM provides powerful database interaction tools. The choice between them depends on project requirements and complexity.
Convert designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual CopilotREADME
PHP Framework Interoperability Group
The idea behind the group is for project representatives to talk about the commonalities between our projects and find ways we can work together. Our main audience is each other, but weâre very aware that the rest of the PHP community is watching. If other folks want to adopt what weâre doing they are welcome to do so, but that is not the aim.
Proposing a Standard Recommendation
To propose a PHP Standard Recommendation (PSR):
-
fork this repo, create a branch, checkout that branch, add the PSR in
proposed/
, push the branch to GitHub, and send a pull request; or, -
create a ticket to start a discussion on GitHub; or,
-
start a conversation on the mailing list.
GitHub usage
All discussion regarding a PSR happens on the mailing list. Issues filed in GitHub are rarely monitored, and PRs are likely to be missed unless a message is sent to the mailing list regarding them. Reviews of a proposed PSR should be conducted on the mailing list, not through PR comments for the same reason.
Please do not simply file an issue or PR and walk-away. The most likely outcome is that it will never get seen or addressed.
Requesting Membership
You do not need to be a voting member to participate in discussion on the mailing list.
To become a voting member, you must send an email to the mailing list.
-
The subject line should read:
Membership Request: {$your_name} ({$project_name})
-
The body should include your name, the name of (and link to) the project you represent, and other details you feel are relevant.
-
Current members will vote on your request.
Do not combine separate membership requests in a single thread; one request per thread, please.
Language & Translations
All PSRs are written in British English or American English (Different specifications may vary, but it is consistent within the same specification). The PHP FIG does not offer official translations into other languages but other external entities are free to translate the specifications in accordance with the license.
Voting Members
The current list of voting members is available on the project website.
Top Related Projects
Convert designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual Copilot