コードを書く際の指針として見返すサイトまとめ - Qiita
お勧めの記事がありましたらコメントなどで教えて頂けると幸いです。 Guidelines プログラマが知るべき97のこと 技術的負債 不慣れなコードベースで短期間に生産性を高めるための7つの方法 何も知らない人を育てるために(新人教育情報キュレーション) 保守開発に開発者として入って困ることのまとめ(実体験) 技術系の名言まとめ++ 真似をする前にバッドプラクティスかどうかを調べてみよう 読まれない名著「人月の神話」を本気で読み込んでみた（まとめ） 技術的負債とどうやって戦うか 楽しいコーディングのための CUPID - SOLID 原則に対するアンチテーゼ エンジニア基礎(新人研修資料) Coding Style モデルやメソッドに名前を付けるときは英語の品詞に気をつけよう 関数名や変数名に使えそうな動詞・名詞・形容詞のメモ Naming -名前付け- DRY原則をもう一度 -コンカレント
Online JavaScript beautifier
End script and style with newline? Support e4x/jsx syntax Use comma-first list style? Detect packers and obfuscators? (unsafe) Preserve inline braces/code blocks? Keep array indentation? Break lines on chained methods? Space before conditional: "if(x)" / "if (x)" Unescape printable chars encoded as \xNN or \uNNNN? Use JSLint-happy formatting tweaks? Indent <head> and <body> sections? Keep indentat
コーディングガイド by @mdo
HTMLシンタックス インデントには半角スペース2個分のソフトタブを使用すること。これが全ての環境で全く同じように見せる唯一の方法。 ネストされた要素はかならず1段階だけインデント(半角スペース2個)すること。 いつもダブルクォートを使うこと。属性値に対してシングルクォートを使わないこと。 閉じタグの無い要素に対して、末尾のスラッシュは省く事。HTML5仕様に省略して良いと書いてある。 省略できる閉じタグを省略しないこと。(例えば</li>とか</body>)。 <!DOCTYPE html> <html> <head> <title>Page title</title> </head> <body> <img src="images/company-logo.png" alt="Company"> <h1 class="hello-world">Hello, world!</h1> </
Google HTML/CSS Style Guide
Revision 2.1 This style guide contains many details that are initially hidden from view. They are marked by the triangle icon, which you see here on your left. Click it now. You should see “Hooray” appear below. Hooray! Now you know you can expand points to get more details. Alternatively, there’s a “toggle all” at the top of this document. This document defines formatting and style rules for HTML
米国人からコーディングについての怒りのメールを頂戴した - その手の平は尻もつかめるさ
"米国人からコーディングについての怒りのメールを頂戴した" の補足 - その手の平は尻もつかめるさ ↑の方で補足いたしました。(2012.09.04 追記) 最近、英語のメールでよく怒られます。moznion です。 海を隔てて共同作業しているアメリカ人から、僕のコーディングについてお叱りのメールを頂いたので、 自戒の念を込めて邦訳して記します。 書いてあることは「当然」とも言うべき内容ですが、僕はその「当然」も守れていなかったのかぁ〜と反省。 以下、邦訳(意訳)です。 1. 郷に入っては郷に従え 既にソースコードが存在しているって事は、そこには同時にコーディングスタイルも存在しているってことだ。 その既存のソースコードに手を加える場合、別のコーディングスタイルを導入してはならない。 もし君がバックエンドのソースコードを弄っているなら、バックエンドのコーディングスタイルで記述するんだ。 フ
あなたのソースを汚くして生産性も下げている、たったひとつの間違い - よくわかりません
この内容には私も全面的に賛成で、クラスやフィールド、メソッド、名前空間など、とにかく文字として表れる名前には、必ず、例外なく、正しく誤解のない命名を徹底することが非常に重要だ。 http://blog.livedoor.jp/lalha/archives/50261226.html 先のエントリは、danさん*1やlalhaさんにまで言及いただき大変光栄で、なにより多くの人に読んでもらえた。多謝。 一方で、自分で読み直すと「先のエントリ」は、いくぶん観念的でいまいちよく分からないところもあるかなと思った。というわけで、より実践に結びつきやすいように、「何に気をつければいいのか」「どういう考え方でコードを書けばいいのか」を書いてみる。 lalhaさんがエントリで強調したかったという (1) 適当に書いたコードは後でとても大きな被害をもたらす可能性が高い への包括的な対策であり、 (2) たく
Zend Framework: Documentation: Zend Framework PHP 標準コーディング規約 - Zend Framework Manual
このドキュメントは、Zend Framework に貢献してくださる開発者個人 (あるいはチーム) のためにコードの書式やドキュメント作成の指針を示すものです。 Zend Framework を用いて開発をする人たちにとってもこのコーディング規約は有用でしょう。 これに従えば、Zend Framework のコードとの一貫性が保てるからです。 そのためには、ここで完全なコーディング規約を示す必要があります。 注意: 詳細なレベルまでの設計指針を示すこと以上に、 それを標準規格として確立することが大切だと考えています。 Zend Framework コーディング規約の指針は、 これまで ZF プロジェクトでうまく回っていた方針をまとめたものです。 このライセンスのもとで、 そのまま使用するなり多少変更して使用するなりすることができます。 ZF コーディング規約では、次のような内容を扱います。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://post.simplie.jp/posts/34
はてなブログ | 無料ブログを作成しよう