PHP: Clean Code (clean-code-php) 蜜柑薬 - Qiita
もくじ はじめに 変数 関数 オブジェクトとデータ構造 クラス S: 単一責任の原則 (SRP) O: オープン/クローズドの原則 (OCP) L: リスコフの置換原則 (LSP) I: インターフェイス分離の原則 (ISP) D: 依存逆転の法則 (DIP) 同じことを繰り返すな (DRY) はじめに この記事はRobert C. Martinの本「Clean Code」のソフトウェアエンジニアリングの法則をPHPに適合させたものです。これはスタイルガイドではありません。読みやすく、再利用しやすく、そしてリファクタリングしやすいPHPコードを書くためのガイドです。 ここで挙げられるすべての原則は厳密に守らなくてはいけないわけではなく、少し守らなかったところで一般には許容されます。あくまでガイドラインですが、Clean Codeの著者たちがみな長年に渡って経験してきたことです。 この記事(
モダンPHPアンチパターン - Qiita
アンチパターンなので、見出しの内容はすべてバッドノウハウです。 前に書いたやつ PHPのモダンな開発環境を紹介する - Qiita PHP - Functoolsを作った - Qiita PHPのlist()はタプル展開のための機能 - Qiita 関係ないけどこれも: シェル、ターミナル、コンソール、コマンドライン 追記: 本文中でとりあげた「怖い話」について、ちゃんと説明しました PHP - namespaceとBOMに何の関係があるのさ - Qiita ファイルの最後に?>を書く PHPコードは<?phpで始まり?>で締める。それがPHPの常識(ｷﾘｯ ……そんなことはもう綺麗さっぱり忘れよう。PHPはテンプレートエンジンではあるが、Webアプリケーションを書く上では、もはやテンプレートエンジンとしての機能は求められなくなりつつある。 不要な?>を書いてはいけない理由は明確で、<?p
PSR-2に準拠した PHP コードを書いてみて気づいたこと | バシャログ。
現在ではロガーのインターフェイスに関する規約を定める PSR-3、PSR-0にとってかわる PSR-4、HTTP メッセージの取り扱いを定める PSR-7が追加されています。また、PSR-4の追加に伴って PSR-0は非推奨となりました。 PSR-3～7の概要については次の記事が参考になります。 PSR-3 Logger Interfaceの話: Architect Note PSR-4 Improved Autoloadingについて調べてみたメモ | kanonjiのブログ PHP - Psr7を使ってみた（というか不変オブジェクトを初めて使った感想） - Qiita さて、冒頭にも書いたとおり、ある長く続く開発プロジェクトで PSR-2をコーディング規約として採用することになりました。「採用する」というのは、これまで口約束や慣習で成り立ってきたものを明文化されたものに置き換えるという
PSR-0, 1, 2を日本語に翻訳してみました｜技術ブログ｜北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ
PSR-0, 1, 2を日本語に翻訳してみました はじめまして。onoと申します。 このたび唐突にPHP-FIGのPSR内容を日本語に翻訳してみました。 1. PSRとは 一言で表すと、PHPの標準コーディング規約です。 それならもう色々あるよねってお話なんですが、 PHP-FIG（PHP Framework Interop Group）というグループには各フレームワークだったりライブラリだったりの関係者が参加しています。 SymfonyだったりZFだったりPEARだったり。 そんな豪勢なメンバーが共通点を見つけながら、ルールを組み立てていきましょう！という背景のもと、共通内容を整理した規約集がPSRということになります。 1-1. 公開します 今回PSR翻訳してみましたが、様々なツッコミを恐れずに公開することにします。 PSR-0 – オートローディング規約（原文） PSR-1 – 基本
PHP: The Right Way
ようこそ 時代遅れの情報がウェブ上にあふれている。そんな情報を見たPHP初心者は戸惑ってしまうだろう。そして、まずい手法やまずいコードが広まってしまう。 そんなのはもうやめよう。PHP: The Right Way は気軽に読めるクイックリファレンスだ。PHPの一般的なコーディング規約、 ウェブ上のよくできたチュートリアルへのリンク、そして現時点でのベストプラクティスだと執筆者が考えていることをまとめた。 大事なのは、 PHPを使うための正式なお作法など存在しない ってこと。 このサイトの狙いは、はじめて PHP を使うことになった開発者に、いろんなトピックを紹介すること。 経験豊富なプロの人にとっても、これまで深く考えることなく使ってきた内容について、新鮮な見方を伝えられるだろう。 このサイトは、決して「どのツールを使えばいいのか」を教えるものじゃない。 いくつかの選択肢を示して、それぞ
PSR-0 を和訳してみた - hnwの日記
先週の土日にPHPMatsuriに行ってきました。ナイスなイベントでしたね。その感想はまた改めて書きますが、Nate Abeleによるセッション「Practical PHP 5.3」で触れられていたPSR-0を適当に訳してみました。これはPHP5.3の名前空間とクラス名に関する標準化の試みで、少なくともZendFrameworkとsymfonyの中の人が関わっているようです。 うまく訳出できなくて苦し紛れのところもあるので、修正すべき箇所があれば教えてください。 元の文章は http://groups.google.com/group/php-standards/web/psr-0-final-proposal にあります。以下はその和訳です。 PSR-0 最終提案 以下で、オートローダーの相互利用性を確保するための必須要件について記述します。 必須要件: 名前空間とクラスの完全な名前とし
PHP のソースコードを読みやすくするための工夫あれこれ
PHP Advent Calendar 2011 に参加しています。 PHP に関する記事を日替わりで書こうというイベントですね。 昨日の redsnow_ さんからバトンを受け取ってこの記事が14日目。 読みやすいってどういうこと ソースコードは読みやすい方がいいし、 あとから修正しやすい方がいい。 難読化したい場合を除けば、 この点では誰もが一致するんじゃないかと思います。 でも、じゃあどういうのが読みやすいか どのようにしてあればメンテナンスが楽かについては 人によって意見がわかれそう。 ということで、普段こういうふうにやってるよ、という例と どうするのがいいかなあ、と思っているところと 人様のコードを見て「おおこれはいいね」と思ったものを書いてみます。 同じものを見て「そりゃあンた当たり前だろう」と思う人もいれば 「そんな書き方してる人がいるのか！」と驚く人もいるかもしれない。 そ
GitHub - php-fig/fig-standards: Standards either proposed or approved by the Framework Interop Group
素のPHPをテンプレートエンジンとして使うときのコーディング規約
プログラムとしてPHPを書くときのコーディング規約は、PEARやZendなど代表的なものがたくさんありますが、テンプレートエンジンとしてPHPを使う場合にはそのまま適用しにくいものです。 テンプレートエンジンのコーディング規約って、検索してもあまり見つからなかったので、個人的に採用しているものを晒してみます。あんまり語る人を見たことがないので、「俺はこうしてるよ」とか「ここキモくね？」とかご意見いただけるとうれしいです。 目指すところ 複雑なロジックをテンプレートに書かない / 書けないように規約で縛る 少しでも読みやすさを追求する できあがりのHTMLの美しさも追及する <%= $this->doctype() %> <html> <head> <%= $this->headMeta() %> <%= $this->headLink() %> <%= $this->headTitle()
PEAR 標準コーディング規約
注意 PEAR 標準コーディング規約は、 PEAR の公式ディストリビューションに含まれるコードに適用されます。 コーディング規約 (Coding standards) は、開発者たちの間ではよく CS と略されます。この規約の狙いは、コードの一貫性を保つことと PEAR の開発者たちがコードを保守しやすくすることにあります。 インデント 空白 4 つのインデントを使用します。タブは使いません。 これにより、diff や patch、CVS history や annotations の際に問題が発生するのを避けることができます。 Emacs を使用する場合、indent-tabs-mode を nil に設定する必要があります。 Emacs を設定するモードフックの例を次に示します (PHP ファイルを編集する際に これがコールされるようにする必要があります)。 (defun php-
PHP 標準コーディング規約 | アイビースター
ＰＨＰでプログラムを作っていくと ｢変数名はどうしよう？｣ などと、たいしたことではないのに凄く悩むときがあります。 PearとZend Frameworkには標準コーティング規約というものがあります。プログラムを書く上でのルール決めです。いずれも内容的には一致しているところも多く大変勉強になります。 ただ、かなり細かく書いてあるので全てを網羅するには結構大変です。下記にそれぞれのコーティング規約を1つにまとめてみました。 ファイル 一行の長さは80文字以内とする。最高でも120文字いないとする 改行はラインフィード( LF )を使用する ファイル名は英数字、アンダーバー( _ )、ダッシュ( – )以外は使用しない インデント インデントはタブを使用しないで半角空白4文字とする 制御構造 if, for, while, switch等で制御キーワード(if等)と括弧の間は1文字開ける i
PHP best practices
Best practices This guide will give you solutions to common PHP design problems. It also provides a sketch of an application layout that I developed during the implementation of some projects. php.ini quirks Some settings in the php.ini control how PHP interpretes your scripts. This can lead to unexpected behaviour when moving your application from development to the productive environment. The fo
FrOSCon "PHP best practices"資料 (SOLVALOU.NET)
ワールドカップで盛り上がるドイツで行われたPHPのワールドカップ(嘘)「FrOSCon」での”PHP best practices”と題されたスピーチの資料が公開されました。 PHP best practices - The dos and don'ts http://talks.php.net/show/php-best-practices/ ※カーソルの左右でページ移動できます（→ 進む / ← 戻る） おおまかな内容はこんな感じ。 一般 typeセーフなコーディングをする opentagには"<?php ?>"を使う エラーレベルはE_STRICTにする Exceptionはメモリリークを起こすことがあるので注意 デバッガを使う(Xdebugがオススメ) コーディング規約に従う ドキュメントを書く(phpDocumentor) セキュリティ ユーザからの入力を信
Zend Framework標準コーディング規約:phpspot開発日誌
Zend Framework PEARの標準コーディング規約というのがありますが、Zend Frameworkにも定められています。 頭に留めておくため、簡単に列挙してみました。 PHPのみのコードは最後の ?> を含めないようにする タブ文字は使わず4文字の半角スペースでインデント 1行を80文字以内に抑えるようにする。長くても120文字 改行コードはLFで統一 クラス名は英字で定義するのを推奨。ZendパッケージのクラスはZend_を最初につける。 インターフェースは名前の最後に_Interfaceを付与する。 例）Zend_Controller_Dispatcher_Interface ファイル名は拡張子をphpにする。incは使わない。 クラス定義したファイルは次のように階層的に設置する Zend_DB → Zend/Db.php メソッド名にアンダースコア( _ ) は含めない。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
株式会社 社会式株 PHPコーディング規約