いろいろな言語のコーディング規約，スタイルガイドのリスト — TRIVIAL TECHNOLOGIES 2.0
みんなのIoT/みんなのPythonの著者。二子玉近く160平米の庭付き一戸建てに嫁/息子/娘/わんこと暮らしてます。月間1000万PV/150万UUのWebサービス運営中。 免責事項 プライバシーポリシー プログラミング言語(C#，VB，PHP，C/C++，Python，Java，Ruby，JavaScript，Objective-C)やHTMLのコーディングスタンダードを集めたリストを発見しました。日本語訳があるものはできるかぎり探し出して，括弧のなかに併記して補ってあります。微妙に古いのが混じってるかな。Rubyは日本発のコーディング規約がある気がする(まつもとさんの日記を見つけた)。 元記事にPerlのスタイルガイドがなかったんだけど，モダンなPerlスタイルガイドがあったら教えて欲しいです:-)。 PythonにはPEP8というコーディングスタイルガイドがあってよく読まれることは
)
クラス ライブラリ開発者向けのデザイン ガイドライン
.NET Framework のマネージ環境を使用すると、開発者は幅広い機能をサポートするようにプログラミング モデルを拡張できます。この .NET Framework デザイン ガイドラインの目的は、一貫性があり、予測しやすいパブリック API を推奨すると共に、Web および複数言語の統合を実現できるようにすることです。.NET Framework を拡張したクラスおよびコンポーネントを開発するときは、これらのデザイン ガイドラインに従うことを強くお勧めします。一貫性のないデザインは、開発者の生産性をも損ないます。開発ツールおよびアドインでは、これらのガイドラインの一部が事実上の規定とされている場合もあるため、ガイドラインに準拠していないコンポーネントの価値は低下します。非準拠コンポーネントも機能はしますが、性能を完全には発揮できません。 これらのガイドラインは、クラス ライブラリのデ
UIデザインガイドラインのまとめ : could
UIUXガイドライン UIデザインガイドラインのまとめ デザインガイドラインは、実際同じようなガイドラインを作るときだけでなく、UIデザインを考える際にも役立つ貴重な資料です。今まで個別で紹介したことはありますが、今回は一挙にまとめてリストアップしてみました。 Introduction to Apple Human Interface Guidelines 個人的に UI デザインガイドラインといえばこれ。日本語訳も大変便利です Apple User Experience Guides ソフトウェア開発向けですが、イントロダクションあたりは参考になります iPhones Human Interface Guidelines 会員登録すると見れる PDF 資料ですが、上記のリンクからブラウザ上で観覧することが出来ます Windows User Experience Interaction G
SVN repository management
[例] メインブランチの最新版にアクセスするURL (userはsourceforge.netのアカウント名) https://user@svn.sourceforge.net/svnroot/sakura-editor/sakura/trunk/ Note: TortoiseSVNではuser@を指定しなくてもCommitの際にユーザ名とパスワードを聞かれますので，そこで入力できます． Commit 2006.03.25 Commit手順の検討メモ にて検討を加えて書き直しました． 正 式branchへのCommit手順 ファイルに変更を加えたときには必ず別の人のReview processを経ること．(ただし，更新履歴についてはこの限りでない) 変更→パッチ作成→レビュー→(必要に応じて作業ブランチを作成)→問題がな ければtrunkへ trunkへのレビュー前のCommitは禁止す
C++ Style Guide
Benjy Weinberger Craig Silverstein Gregory Eitzmann Mark Mentovai Tashana Landray 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 an "expand all" at the top o
例外との正しいつきあい方
例外ってなに? プログラムを書いていると、try ... catch を書くのがめんどうになったことはありませんか。 たとえば、リスト 1 はファイルを読み込んで単に標準出力に出力を行うプログラムです。これを javac でコンパイルすると、図 1 のようにコンパイルエラーが起きて、コンパイルできません。そこで、「しょうがない、try ... catch を書くか」といって、リスト 2 のように書いたとします。「これでコンパイルはできたから OK」と済ませていませんか。 これでは例外から得ることのできるさまざまな有用な情報を捨ててしまっています。それだけでなく、想定していた動作を行うことができないかもしれません。 逆にいえば、例外を有効に使いこなせるようになれば、プログラムの堅牢性を高めることができ、また保守性も向上させることが可能です。そんな例外の基本から例外を使いこなす
suVeneのあれ: 俺的コーディングルール SQL編
2007年01月19日 俺的コーディングルール SQL編 プロジェクトのコーディングルールがこうでなければいけないとか、他人に強制するわけではないが、自分自身で一貫性の無いコードを書くのは気持ち悪いので、オレオレルールを決めてたりする。大抵は デ・ファクト的なルールに沿う形で書くことが多いのだが、SQL や PL/SQL に関してはなかなかデファクトと呼べるものがないので(あるのか?)、メモ的に書きとめておく。 原則キーワード小文字オブジェクト名大文字カンマは後ろインデントは半角スペースで 2一つの SQL 文でキーワード毎にインデントしない(副問合せ除く) まず、1.2. に付いてなのだが、昔は「キーワード＝大文字」という意味不明な先入観で大文字で書いていた。ただ、それだと PL/SQL のキーワードも大文字、オブジェクト名も大文字で結局ほとんど大文字になってしまうのと、Shift 押す
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
変電工 - Google C++スタイルガイド日本語訳