約 2,409,135 件
https://w.atwiki.jp/sevenlives/pages/2631.html
■ PHP PEARコーディング規約? Zend Framework PHP 標準コーディング規約? PHP-FIG?
https://w.atwiki.jp/inugasuki7/pages/12.html
無作為に作ってしまうのも良いのだけど、後から見直すとどうしても見難いものです。 プログラムをするにも一連したルールがあると、ルールに基づいて見る事が出来き比較的見やすくなるものです。 文書の書式にこだわるのと似たような物です。 ただ、コーディング規約を充実させれば、不用意なバグ回避の手段にもなります。 バグの多くは、人が作り出すものですから。 end.
https://w.atwiki.jp/taizo0401/pages/19.html
h1. ▼コーディング規約 h2. ・改行コード p((. 改行コードはLF（Linux）で保存。文字列出力時に改行を出力する場合は、 PHP_EOL を使用する $str= aaa . PHP_EOL; print $str; h2. ・変数名 p((. 変数名は全て小文字で表記。単語節はアンダースコア _ で区切る $player $team_id $world_id p((. クラスのインスタンスを取得する場合は、頭文字を大文字にする $Team = new Team(); $Team = ClassRegistry init( Team ); h2. ・引数 p((. メソッドで定義される引数の変数名はアンダースコア _ で始める public function hoge($_arg1, $_arg2, $_arg3) { } h2. ・メソッド名 p((. メソッド名は頭文字を小文字としたキャメルケースとする public function getHogeFoo() { } p((. プライベートメソッドは、メソッド名の最初にアンダースコア２つ __ をつける private function __kokoDakenoHanashi() { } h2. ・コメント（メソッド） p((. メソッド宣言上部に以下の形式でコメントを残す。 /** * hogehoge 内で fugafuga する文字列を返す ⬅ メソッドの説明を記載する * * @access public ⬅ メソッドのアクセス権を記載する（public / protected / private ） * @param string $str1：ふがふがする前の文字列1 ⬅ メソッドの引数の型/変数名/説明を記載する * @param string $str2：ふがふがする前の文字列2 * @return string：ふがふがした文字列, null 処理異常 ⬅メソッドの戻り値。戻り値の型/パターン/説明を記載する */ public function hogeFoo($str) { return $str; } h2. ・トランザクション p((. APIにおけるトランザクションの開始と終了は、基本的にControllerのメソッドにて行い、その他の処理では行わない。 class Controller extends Controller { public function index() { try { $this- Model- begin(); … $this- Model- commit(); } catch ( Excaption $e ) { $this- Model- rollback(); } } } h2. ・エラー処理 p((. API処理中に異常があった場合は、例外(Exception)を発生させる。 例外は基本的にControllerのメソッドにてキャッチする。 class Component extends Component { public function getXXX() { $ret = $Model- find( all , $param ); if( $ret == null ) { throw Exception( $msg, $error_code ); } } }
https://w.atwiki.jp/ryouga0415/pages/47.html
更新日：2009-04-08 目的 既存ソースのリファクタリングを行うことで、見栄えのよいソースにし、メンテナンス性を向上させる。 また、コーディング規約のような注意事項を設けることで複数の方が開発する場合でもコーディングの ずれが少なくなる。新規で開発する場合も以下の事を踏まえて作成する規約とする 注意事項 1) リファクタリングと高速化の因果関係はありません。ただ、遅延している箇所が特定しやすくなります。 2) 機能追加とリファクタリングは同時に行うことを禁止します。リファクタリング期間を設けて実施すべきである。 3) なるべく、リファクタリングツール等を利用し、機械的にリファクタリングを行う。 4）リファクタリング時はコメントアウト/解除を行うことが多いのでキー操作で行う。 コメントアウト Ctrl + E + C コメント解除 Ctrl + E + U リファクタリングツール(無償) ASP.NET用 http //devexpress.com/Products/Visual_Studio_Addin/RefactorASP/ VB.NET用 http //devexpress.com/Products/Visual_Studio_Add-in/VBRefactor/ コード変換ツール( VB ⇔ C# ) http //www.developerfusion.com/tools/convert/vb-to-csharp/ DBアクセス関連の速度UP 1)SQL文を格納する記述がある場合 String型より、StringBuilder型に格納する 2)WHERE句の記述順序 絞り込める量が多い、条件の厳しいものから先に行う ⇒ 高速UP 3)HAVING句は極力利用しない 4)単純なSQL文でもテーブル別名を付加する ×SELECT id, name FROM user WHERE active=1 ○SELECT u.id, u.name FROM user u WHERE u.active=1 5)1つのテーブルにデータが大量になる場合はテーブルを分ける 6)Fromはレコード数が多い順に並べる ×FROM jusho j, user u ○FROM user u, jusho j 7)BETWEEN句は使えたら使う 8)COUNT(*)よりCOUNT(id)を使う 9)なるべく*は使わない。行を指定した方が速い ×SELECT * FROM SomeTable; ○SELECT id FROM SomeTable; 記述の工夫での高速UP 1) Withブロックを使う 旧) Button1.Text = "Withですか？" Button1.BackColor = Color.LightBlue Button1.TextAlign = ContentAlignment.MiddleRight 新) With Button1 .Text = "Withですか？" .BackColor = Color.LightBlue .TextAlign = ContentAlignment.MiddleRight End With 命名規則 1) 変数名にプレフィックスをつける 型 変換 int i string s bool b double d list lst Combo cmb Form frm Label lbl textBox txt CheckBox chk メンバ m_ 2) 変数名のつけ方 省略前 省略後 意味 message msg メッセージ directory dir ディレクトリ error err エラー delete del 削除 count cnt カウント format fmt フォーマット flag flg フラグ アクセシビリティを意識する Public 同じプロジェクト、他のプロジェクトからのアクセス可能 Proteted 同じクラス、派生クラスからのアクセスのみ可能 Friend 同じプロジェクトからのアクセスのみ可能 Private 同じクラスからのみアクセス可能 ArrayならHashtableを使用する インデックス指定だけならArrayかArrayListを使うのが最適だが キーと値を関連付けたいならHashtableが便利だ。また高速でもある。 速度比較) 16個のアイテムから全アイテムを検索するを１万回ループ Ayyay 94ms Hashtable 172ms 256個のアイテムから全アイテムを検索すると1万回ループ Ayyay 10469ms Hashtable 2906ms HashtableならDictionaryを使用する .NET Framework 2.0ではDictionaryジェネリック・クラス （System.Collections.Generic名前空間） が追加され、より効率的かつ安全にハッシュテーブルを扱えるようになっている 1000000個のアイテム取得 Hashtable 15ms Dicitionary 3ms 全角/半角の変換はStrconvを使用する Replace関数は文字に依存してしまうのでStrConvが便利 × sText = sText.Replace(" ","’") ○ sText = StrConv(sText,VbStrConv.Wide) Debug.Printは残さない 速度に影響するので残さない。 変数の初期化と宣言は同時に行う ×Dim sSayHello As String sSayHello = "Hello World" ○Dim sSayHello As String = "Hello World" 判定の書き方 1)空文字判定 IF text Is Stringempty Then … End IF 2)Nothing判定 IF IsNothing(text) = True Then … End IF 3)空文字でない判定 IF text IsNot StringEmpty … End IF データの存在確認メソッドはBoolean型を使用する ×戻り値をString型で「データ有」などの文字列にしない ○戻り値はTrue/Falseを利用する 長いメソッドや記述は改行する Private Function test(ByVal s As String _ ByVal m As String) String同士の比較はEquals()メソッドを使用する ×If sText = "?" Then ○If sText.equals("?") Then
https://w.atwiki.jp/libjo/pages/30.html
プログラムの書式 文字コード [UTF-8 BOMなし] 行末はラインフィード(LF)のみにする。 PHPの開始タグには ?は使用せず ?phpを使用する。 PHPの終了タグは使用しない [ ? ] ライブラリ 11/18 ソースコードにJavadoc風のコメントをつける 必ずつけるものは@author,@parm,@version,@info @authorは作成者か更新者の名前 @parmは引数の説明 @versionはバージョン @infoはモジュールの説明 Smarty 11/18 PHP側で表示するテンプレートのファイル名はPHPファイルと同じにする index.phpの場合はindex.tplとする。 命名規則 ファイル名 使用可能な文字は[英数字]と[アンダーバー(_)]のみ 拡張子は必ず[.php]でなければならない 英単語のみの構成を推奨 変数 使用可能な文字は英数字のみ コメント １行コメントは// コーディングスタイル オブジェクト指向はまだならっていなので、手続き型でコーディングする。（保留） 画面に出力するのはSmartyを使用する OOを「習っていないから」という理由で避けるのは無理がある。MySQLもSmartyも（もっといえば、PHPも）習ってないものだから -- fuck (2008-10-05 22 48 13) 名前 コメント
https://w.atwiki.jp/former5jproject/pages/29.html
バックアップです。 うっかりコーディング規約のページを削除してしまいそうになったので、バックアップページを作りました。 コーディング規約 ファイル構成 １．ファイル名 publicクラスはそのクラスの1ファイルにする。 例：public class Customer は Customer.cs に入れる。 非パブリッククラスはそのクラスが主に使われるパブリッククラスのファイルに含めてよい。 例外クラスは、1ファイルに複数クラスをまとめてもよい。 ２．ファイルの位置 プロジェクトのルートディレクトリを決め、名前空間の “.” をディレクトリ階層に置き換えた位置に入れる。但し、ソリューション / プロジェクトに対応している名前空間の階層は、ソリューション名 / プロジェクト名をディレクトリ名に使用する。 命名規約 １．英語と日本語 全ての識別子の名前は英語を用いること。 ２．名前空間 企業略式名.組織略式名.テクノロジー名.機能名を使用する。また、テクノロジー名にはソリューションが、機能名にはプロジェクトが対応していること。 using Project5j.Bomberman... ３．クラス名 単語ごとに先頭大文字。 例：class PascalCasing ４．例外クラス名 最後をExceptionとしたクラス名。 例：class ClassNameEndsWithException ５．インターフェイス名 クラス名に同じ。また常に最初にIを付ける。 例：interface INameOfInterface また、クラスにある能力を加える様な利用の場合、その能力を示す形容詞とし、-ableを接尾にする。 例 IEnumerable, ICloneable, IXmlSerializable, … ６．抽象クラス名 抽象クラス名に適当な名前が無いとき、 Abstract から始まりサブクラス名を連想させる名前を付ける。 例：abstract class AbstractBeforeSubClassName ７．非パブリックメンバ 先頭に"_"を付加する。 単語の先頭は小文字。それ以降、単語ごとに先頭大文字 例：private object _objectName; ８．パブリックメンバ 単語ごとに先頭大文字。 例：public object ObjectName; ９．定数(const) 大文字もしくは大文字を"_"でつないだもの。 例：const int UPPERCASE = 0; const int UPPERCASE_WITH_UNDERSCORES = 0; １０．列挙型(enum) 単語ごとに先頭大文字。 例：enum PascalCasing １１．列挙値 単語ごとに先頭大文字。 例：PascalCasing １２．イベント名 単語ごとに先頭大文字。 例：event PascalCasingEvent() １３．デリゲート名 単語ごとに先頭大文字。変数名の末尾にHandlerを付加する。 どのような場合に呼び出されるか変数名を見てわかる名前をつけること。 悪い例：public delegate void StateHandler(); public delegate void TimeOutHandler(); 良い例：public delegate void StateChangedHandler(); public delegate void ThreadTimeOutHandler(); １４．メソッド名 先頭小文字。あとは単語ごとに大文字。 例：void pascalCasing(); object pascalCasing(); １５．ファクトリメソッド(オブジェクトをnewするもの) createの後に先頭が小文字で始まるオブジェクト名を付加する。 例：ObjectName createObjectName(); １６．コンバータメソッド(オブジェクトを別のオブジェクトに変換するもの) to, fromの後に先頭が小文字で始まるオブジェクト名を付加する。 例：void toObjectName(); ObjectName fromObjectName(object obj1); １７．プロパティ名 単語ごとに先頭大文字。 例：object PascalCasing { } １８．Boolean変数を返すメソッド Is + 形容詞、Can + 動詞、Has + 過去分詞、三単元動詞、三単元動詞 + 名詞。 良い例：bool IsEmpty() bool CanGet() bool HasChanged() bool Contains(object x) bool ContainsKey(string key) 悪い例：bool Empty() //「空にする」という動詞的な意味に取れる。 bool CheckXXX() // trueがどちらの意味か分かりづらい。 理由 ：if, while文等の条件が読みやすくなる。 またtrueがどちらの意味か分かりやすい。 １９．bool変数 形容詞、is + 形容詞、can + 動詞、has + 過去分詞、三単元動詞、三単元動詞 + 名詞。 例：bool _isEmpty; bool _dirty; bool _containsMoreElements; ２０．名前の対称性 クラス名、メソッド名を付ける際は、以下の英語の対称性に気を付ける。 Add / Remove Insert / Delete Get / Set Start / Stop Begin / End Send / Receive First / Last Push / Pop Up / Down Upper / Bottom Show / Hide Source / Target Open / Close Source / Destination Increment / Decrement Lock / Unlock Old / New Next / Previous ２１．ループカウンタ スコープ（通用範囲）が狭いループカウンタには i, j, k という名前をこの順に使う。 ２２．スコープが狭い名前 スコープが狭い変数名は，型名を略したものを使って良い。 例： DataSet ds = new DataSet(); ２３．意味がとれる名前 変数名から役割が読み取れる名前をできる限り指定すること。 悪い例：Copy(string s1, string s2) 良い例：Copy(string source, string destination) ガイドライン １．public Variable インスタンス変数は、極力publicにせず、妥当なプロパティを設ける。 理由：オブジェクト指向の標準。クラスの内部状態に勝手にアクセスさせるのはよくない。ただし、以下の条件をすべて満たす場合、インスタンス変数をpublicにし、直接アクセスさせてもよい。 ●そのインスタンス変数が他のインスタンス変数と独立であり、単独で変更されても内部の整合性をくずさない。 ●どちらにしても，get / setアクセサを書く。 ●インスタンス変数の実装が将来に渡って変更されないことが確定している。 ２．状態取得と状態変更の分離 メソッドは，「1つの事」を行うように設計せよ。特に、状態変更と状態取得の２つのサービスを１つのメソッドで行わない。状態を変更するメソッドの return 値はvoidにせよ。 理由1：１つの事を行うメソッドの方が分かりやすい。 理由2：並行性の制御、例外の安全保証がしやすい。 理由3：サブクラス化による拡張がしやすい。 ３．オブジェクトの同値比較 オブジェクトの比較では Equals() メソッドを使い、== , != を使うな。特に、Stringの比較では == , != を使用してはならない。 理由：もし実装者がEquals()を用意しているなら、それを使ってほしくて実装したはず。また、Stringの比較では設定により大文字/小文字が区別されない場合があるため。 ４．宣言と初期化 ローカル変数は、初期値と共に宣言すること。 ５．大小比較演算子 大小の方向を統一することを目的として、 “ ”、 “ =” を使い、” ”、 “ =” はなるべく避けること。 ６．メソッド引数の変更は悪 原則としてメソッドの引数は入力であり、出力としては使わないこと。すなわちメソッド内部で引数の状態を変更するメソッドを呼ばないこと。出力引数に新たなオブジェクトを代入しないこと。 悪い例 void MoveX(Point p, int dx) { p.X = p.X() + dx; // 引数を変更している(なるべく避ける) } void MoveX(Point p, int dx) { Point p = New Point(p.X + dx, p.Y); // これは呼び出し側に伝わらない } 例外：パフォーマンスを気にする場合。 ７．パフォーマンス調整は二の次 複雑な処理の場合、最初からパフォーマンスを気にしたコーディングをするべきではない。先に可読性、保守性を優先する。 コメント １．クラス summary から始まり /summary で終わるNDoc(*)形式を採用する。 クラスやインターフェイスなどを継承している場合は remarks から始まり /remarks で終わるNDoc形式を採用する。 例：/// summary ///概要 /// /summary /// remarks ///このクラスはProject5j.Bomberman.Class1を継承している。 /// /remarks public class Class2 Project5j.Bomberman.Class1 { } ２．メンバ summary から始まり /summary で終わるNDoc形式を採用する。 例：/// summary ///概要 /// /summary object _objectName; ３．プロパティ・インデックス value から始まり /value で終わるNDoc形式を採用する。 getアクセサを実装している場合は「取得する」と記述して、setアクセサを実装している場合は「設定する」と記述する。 例：/// value ///値を取得する。 /// /value object ObjectName { get { return _object; } } /// value ///値を取得・設定する。 /// /value object ObjectName { get { return _object; } set { _object = value; } } ４．メソッド summary から始まり /summary で終わるNDoc形式を採用する。 例：/// summary ///概要 /// /summary /// param name="obj1" オブジェクト１ /param /// return 戻り値の説明 /return public object methodName(object obj1) { } ５．メソッド内部 いかなる場合でも、半角スペースを前後に使用した/* ... */を採用する。 例：/* 処理１ */ ・・・ /* * 処理１ * ここんところをこう、こう、こう。 */ (*)NDoc：ソースコードのコメントをXML, HTML形式でのドキュメントに変換するツール。 初版 2006.09.17 Y.Kawauchi
https://w.atwiki.jp/former5jproject/pages/25.html
ファイル構成 命名規約 ガイドライン コメント 2006.09.17 Y.Kawauchi 第一版作成 2006.09.20 R.Iguchi ツリー構成に変更 2006.12.06 Y.Kawauchi 命名規約 - 14.を修正
https://w.atwiki.jp/electronautsstudio/pages/24.html
コーディングのガイドライン 命名規約 名前 コメント Today - Yesterday - Total -
https://w.atwiki.jp/abapdevstd/pages/14.html
クラス レポートプログラム 汎用モジュール クラス レポートプログラム 汎用モジュール
https://w.atwiki.jp/nenaiko/pages/23.html
◆クラス内での変数名 // 単語頭大文字 class TestClass { int Handle; }; ◆クラス内での変数名（例外） // 短すぎる変数名（3文字以内？）は単語頭小文字 class TestClass { double x; double y; }; ◆クラスのメンバ関数の引数 // 単語頭小文字 int TestClass TestFunk(int handle)