オブジェクト指向できていますか？3. 自己紹介 1992年～1997年 某ゲーム会社 プログラマ SFC,GB,PS1,N64のゲーム開発経験 1998年～現在 日本工学院八王子専門学校 @mozmoz1972 専任講師 プログラミング教育を中心に担当 twitterもfacebookも実名です。よかったらフォローしてください。
コーディング規約をまとめてみた (Ruby編) - bojovs::blog
色々なところで見かけるコーディング規約を見て意識はしているのですが、 その時の気分で書き方を変えてしまうことが多々あったので、自戒を込めてコーディング規約をまとめてみました。 「なぜこの規約が存在するか」を明確にするために、できる限り理由も併記しています。 ただかなり主観的な部分があるので、あまり意味がないかもしれません…。 「この記事のこの規約は気に入らない。」と思うことがきっとあると思います。 その時はコメント欄などに理由も合わせて書いてくれると嬉しいです。 この記事ではRubyのコーディング規約をまとめています。 近いうちにRailsとCoffeeScriptのコーディング規約もまとめるつもりです。 Rubyのコーディング規約は以下のページを参考にまとめました。 https://github.com/styleguide/ruby https://github.com/bbatsov
JavaScriptのいろいろなコーディングルールをまとめてみた
JavaScriptの書き方はJavaScript自体がある程度自由なためいろいろな書き方ができますが、一貫性を持って書いた方がバグなども発生しにくくなるため、コーディングルールを定めておくのはよいことだと思います(特に複数人の開発の場合) 有名な企業やライブラリはコーディングルールも公開している事が多いので適当にまとめてみました JavaScript style guide – MDC Docs Mozilla/Firefox向けのものなので、一部ECMAScriptの範囲を超えたものも含まれています。 多くの人が見ていると思うので、見たことない人は一度読んでみるといいです。 jscsにこのコーディングルールをチェックするプリセットが用意されています。 Google JavaScript Style Guide Google JavaScript Style Guide 和訳 — Goo
変数とメソッドの命名ベストプラクティス15 - 杉風呂2.0 - A Lifelog -
この記事は、Cagdas Basarane 氏のブログ、 CodeBuild から 2012年2月20日の記事 "15 Best Practices of Variable & Method Naming" を翻訳したものです。 原文URL http://codebuild.blogspot.com/2012/02/15-best-practices-of-variable-method.html 十分短く十分長い変数名をスコープごとに使用する。一般的に、ループカウンタには1文字、条件やループ変数には1単語、メソッドには1-2単語、クラスには2-3単語、グローバル変数には3-4単語を使用する。 具体的な(specific)名前を使用する。例えば、"value"、"equals"、"data"といった変数名はいかなる場合も有効ではない。 意味のある(meaningful)名前を使用する。変数
php-modeのインデント設定 - つまみぐいメモ
Eclipseをやめてemacsでphpのコードを書くようにしたけれども、php-modeの標準（php-mode-force-pear tの時）のインデントがちょっと気に食わない。こういった時にささっとカスタマイズできるのがemacsの利点なんだけど、どこを直せばいいのかよくわからない、というもがemacsの欠点、そして最悪elipsを読めばなんとかなるのが利点で、elispがとっつきにくいのが欠点。 - どういうインデントになって欲しいのか まず、標準のインデントはこんな感じになる。 <?php function longLongFunctionName($arg1, $arg2, $arg3, $arg4) { } $tmp = array('key1' => 'val1', 'key2' => 'val2'); $tmp = array( 'key1' => 'val1', 'ke
PHP のソースコードを読みやすくするための工夫あれこれ
PHP Advent Calendar 2011 に参加しています。 PHP に関する記事を日替わりで書こうというイベントですね。 昨日の redsnow_ さんからバトンを受け取ってこの記事が14日目。 読みやすいってどういうこと ソースコードは読みやすい方がいいし、 あとから修正しやすい方がいい。 難読化したい場合を除けば、 この点では誰もが一致するんじゃないかと思います。 でも、じゃあどういうのが読みやすいか どのようにしてあればメンテナンスが楽かについては 人によって意見がわかれそう。 ということで、普段こういうふうにやってるよ、という例と どうするのがいいかなあ、と思っているところと 人様のコードを見て「おおこれはいいね」と思ったものを書いてみます。 同じものを見て「そりゃあンた当たり前だろう」と思う人もいれば 「そんな書き方してる人がいるのか！」と驚く人もいるかもしれない。 そ
Javaコーディングルール - Javaにおけるコーディング規約
Javaコーディングルール - Javaにおけるコーディング規約 目次 ネーミングルール 全般 英語を使え！ 大文字・小文字の違いで名前を区別しない パッケージ パッケージ名は全て小文字にする パッケージ名には意味のある名前を付ける パッケージ名は省略しない サブパッケージ名の重複は可能 クラス・インタフェース クラス名は役割を表す名前にする クラス名は単語の先頭を大文字にする 例外クラス名は末尾に「Exception」を付ける インターフェイス名はクラス名に準ずる 抽象クラス名はクラス名に準ずる 実装クラス名はクラス名に準ずる 能力付加型のインタフェース名は末尾に「able」を付ける テストクラス テストクラス名は「テスト対象クラス名＋Test」にする すべてのテスト/パッケージテストを行うクラス名は メソッド コンストラクタと同じ名前のメソッドはつくらない メソッド名は区切りのみ大文字
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
Javaプログラマが知るべき9のこと - @katzchang.contexts
はじめに ソースコードは設計であり、コードの記述は品質に直結するのは言うまでもない。ちなみに、プログラマにとって特に重要なのは保守性だ。コードは書いた直後から保守対象となるからだ。コードは要求文書の範囲で動けばいいと思っている人がいれば今すぐ、ソースコードをコピペして100klに増えるプラグインがいつの間にかインストールされる呪いをかけてあげよう。幸い、ここを読んでいる人にはそんな人はいないだろうと思うけれども。 ということで、コードの品質を下げる要因、すなわちシステム全体の品質を下げる要因となり、かつ使われやすいアンチパターンを挙げ、対策を検討していくことにする。対象は以下： 出力パラメータ 処理状態返却 意味のある配列 無意味な初期化 多すぎるtry-catch 暗黙の順序 コンパイラ警告の無視 過剰なコメント e.printStackTrace() 出力パラメータ メソッドの引数にオ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
