コミットメッセージの作法 - Qiita
gitプロジェクトのガイドラインを参考にまとめました。この作法は英語で書くことが前提となっています。 1. コミットメッセージの1行目は短い説明文(50文字以内) モジュールについての修正の場合、モジュール名: ではじめる 説明文は小文字ではじめる 説明文のピリオド(句点)を省く 2. 2行目は空行にする そうすることで、例えばコミットした内容を E-Mail に変更するツールにて、 Subjectに最初の行を使用し、残りの行を本文にすることができる。 3. 本文には意味ある内容を含める 問題点: 修正した問題点について説明する 妥当性: 行った修正について、「なぜその方法がより良いのか」を説明する 代替案: もし、他の修正方法を検討したのなら、それらについて説明する 4. 変更は命令形で表現する まるであなたがコードベースに変更を命令じているかのように書く。 [bad] "This pa
「よりよいコードを求めて命名について頭をひねる会」のログ
http://www.zusaar.com/event/438105 アプリケーションを作る英語 の著者の西野さんを交えて、クラス名とかメソッド名とか変数名とか命名で困っている課題を1つ以上持ち寄りみんなで一緒に検討する勉強会をしました。 「アプリケーションを作る英語」 電子書籍 http://tatsu-zine.com/books/english4app 紙 http://www.amazon.co.jp/gp/product/4844332848/ はじめに：西野さんからちょっとお話 The Art of Readable Code から第2章と第3章 第2章：名前に情報を詰め込むようにする どういう情報をつめこむか。 明確な言葉を選ぶ get は不明確らしい getPage(url) -> FetchPage(url) や DownloadPage(url) 特色のある（color
コーディング規約をまとめてみた (Ruby編) - bojovs::blog
色々なところで見かけるコーディング規約を見て意識はしているのですが、 その時の気分で書き方を変えてしまうことが多々あったので、自戒を込めてコーディング規約をまとめてみました。 「なぜこの規約が存在するか」を明確にするために、できる限り理由も併記しています。 ただかなり主観的な部分があるので、あまり意味がないかもしれません…。 「この記事のこの規約は気に入らない。」と思うことがきっとあると思います。 その時はコメント欄などに理由も合わせて書いてくれると嬉しいです。 この記事ではRubyのコーディング規約をまとめています。 近いうちにRailsとCoffeeScriptのコーディング規約もまとめるつもりです。 Rubyのコーディング規約は以下のページを参考にまとめました。 https://github.com/styleguide/ruby https://github.com/bbatsov
Google HTML/CSS Style Guide の推奨ガイドラインまとめ | バシャログ。
すっかり夏っぽくなり、ビアガーデンに毎日通いたいと常々感じる今日この頃、Latin です。 巷で流行っていると噂の Google HTML/CSS Style Guide についてまとめて下さっている REFLECT DESIGN さんのブログより、代表的なものをいくつか抜粋してみました。 全般的なスタイルルール 一般的な書式ルール 全般的なメタルール HTMLのスタイルルール HTMLの書式ルール CSSスタイルルール CSS書式ルール 全般的なスタイルルール プロトコルの記述 <!-- NG --> <script src="http://www.google.com/js/gweb/analytics/autotrack.js"></script> <!-- OK --> <script src="//www.google.com/js/gweb/analytics/autotrac
プログラマのためのUXチートシート — ありえるえりあ
はじめに http://msdn.microsoft.com/ja-jp/library/aa511258.aspx の 「Windows ユーザー エクスペリエンス ガイドライン」 「ガイドライン」 主に「コントロール」 の抜粋です。 以下の基準で抜粋しました Web UIに応用可能 実用的かつ具体的 自明ではない プライマリUIを目立たせる プライマリ UI 要素を強調するには、以下に従います。 - プライマリ UI 要素は、視線の通り道に配置します。 - タスクを開始する UI 要素は、左上隅または中央上に配置します。 - コミット ボタンは、右下隅に配置します。 - 残りのプライマリ UI は、中央に配置します。 - コマンド ボタン、コマンド リンク、アイコンなど、注意を引き付けるコントロールを使用します。 - 大きなテキストや太字のテキストなどの目立つテキストを使用します。 ユ
Javascriptコーディング規約を考える - Diary of absj31
社内プロジェクト開発に於ける、Javascriptのコーディング規約に関して。 Javascriptコード部分 コードそのものに関しては、これで良さげかなぁ？日本語だし分かりやすそうだし。 Dojoのコーディング規約も良いとの意見も見受けられますが、英語なので翻訳が面倒(笑) JavaScript style guide - MDC その他コード部分のルールについての記事。 JavaScript のコーディング規約 (コーディングスタイル) - Jamz (Tech) JavaScriptのコーディングスタイル 2.0 ― ありえるえりあ Javascriptドキュメント部分 あと、Javascript関連で忘れがち(忘れられがち)なのがコメント部分。 ここはCheckStyleみたいにJavadoc記述を強制するプラグイン・ツールなどは無さそうなので地道に 『コメントは忘れずに書いてね』
長音符号省略形
あれ？A社のマニュアルは「コンピューター」って書いているのに、B社のは「コンピュータ」って書いていますよ。これって間違いじゃないスか？ 気が付いた？外来語の書き表しかたにはいろんな基準があるの。目立つものは「コンピューター」と末尾を伸ばす書き方、それと「コンピュータ」って伸ばさない書き方があるの。もちろん「コンピュータ」だけじゃなく「デジタル」と「ディジタル」とかいっぱいあるわ。
スタイルシートを書く時のガイドライン - 2xup.org
2006-07-11T19:56:28+09:00 会社ではやっているのだけれど、自分のウェブサイトでもやってみよう。と簡略記述を利用する場合の値の順序やらもまとめとく必要があるのかもしれないけれど、セットフォーマットルールやプロパティの順番だけをサクッとまとめて資料にしてみました。課題は残したもののこれだけでも相当すっきり。詳細やセットフォーマットルールに関しては、ダウンロードできるようにしている資料を参考にしていただくとして、このエントリーではプロパティの順序についてまとめることに。自分自身が実際に作業を進めていくことを考慮し、その考えに基づいて設定したモデル別の順序は以下の通り。 生成 内容, 自動番号付け及びリスト (Generated content, Automatic numbering, and Lists) 利用者インターフェイス (User Interface) ビジュ
翻訳ルール - MergeDoc Wiki - MergeDoc - OSDN
最近の更新2023-05-28FrontPage 2022-04-23Pleiades対応Eclipseプラグイン一覧 2016-06-19PleiadesをEclipseプロジェクトとしてチェックアウトする 2010-03-04SideBar 2009-02-27PleiadesAllinOne3.4.2.20090225暫定ダウンロード・ページ 2009-01-26翻訳に参加する 最新リリース情報JStyle (4.5.2.0)2016-02-28 23:07MergeDoc for javadoc 1.5 (2.1.4)2007-03-05 00:11Pleiades (1.7.27)2017-06-28 08:48Servlet API Japanese Document (2.4.0)2006-03-28 20:13 WikiガイドWikiの文法 リンクの種類と文法 ブロックプロ
XHTML・CSSコーディングガイドライン | d-spica | ホームページ制作・ウェブサイト制作・Webデザイン
文書の構造を示すことを目的とする。見た目の装飾に関わることを記述しない。 宣言 特に事情がない場合は，文字コードをUFT-8にして，XML宣言を省略する。 DOCTYPEは原則的にXHTML 1.0 Strict 。 ただし，更新スタッフの事情に合わせてXHTML 1.0 Transitional，HTML 4.01 Strict，HTML 4.01 Transitionalにする場合もある。 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> head ページの性質を示し，UAに読ませることを目的とする。 最初に <meta http-equiv="Content-Type" content="text/html; ch
ITエンジニアにも必要な国語力（1）
図解の本質はここにあった ITエンジニアにも必要な国語力 第1回 名前にとことんこだわるべし 開米瑞浩（アイデアクラフト） 2005/8/10 コミュニケーションスキルの土台となる図解言語。だが筆者によると、実はその裏に隠れた読解力、国語力こそがITエンジニアにとって重要なのだという。ITエンジニアに必須の国語力とはどのようなものだろうか。それを身に付けるにはどうしたらいいのか。毎回、ITエンジニアに身近な例を挙げて解説する。 「Can you speak English?」と聞かれてあたふたしてしまう日本人も、「あなたは日本語が話せますか？」と聞かれたら「いいえ」と答えることはないだろう。しかし、「日本語が話せる」といっても、日常会話レベルの日本語力とエンジニアリングに必要な日本語力とでは次元が違う。ITエンジニアに必要な国語力をあらためて見直そう。 ■ITエンジニアにこそ国語の力が必要
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ページを開く
あなたは「サーバ」派？ それとも「サーバー」派？ ～表記を統一して、ドキュメントの信頼性をアップさせよう
bookshelf.jp
http://c2.com/cgi/wiki?JavaScriptCodingStandard