2. 良いコードとは • （エンタープライズにおける）良いコードとは、「読みやすくて 理解しやすく、修正しやすいコード」のことである • メモリ使用量やCPU使用量、I/O転送量が低いコードのことではない • 少しでも高速に動作するコードのことではない • ゲームや特殊な環境で動作するソフトウェアなどでは、こういうコードが「良 い」コードの場合もある • トリッキーな手段を駆使してなるべく短くかかれたコードのことではない • 競技プログラミングなどでは、こういうコードが「良い」コードの場合もある 3. なぜ「良い」コードを書くべきなのか • エンタープライズでは、チームで開発することが多い • 一人ですべて開発するのだとしても、３か月前の自分は他人 • エンタープライズでのコードは、「書かれる」よりも「読まれる」 ことが圧倒的に多い • エンタープライズのコードは機能拡張が常に発生するため
クソコードについてここ数日で考えたことを書いてみる。 技術的負債まわりのえらいひとたちの議論を眺めてて、技術的負債って言うとなんかプロっぽいけど、クソコードって言ったほうが示したいモノを素直に表してるし分かりやすいきがしてきた。 クソコードを書くなとは思わないけど、クソコードをいつまでも放置するのはやめようって思う。 クソコードは次なるクソコードを生み出すし、バグを隠蔽するし、メンテナンスコスト増大の悪循環のキッカケになるし、新人の教育上良くないので無くて済むならもちろんないほうがいい。 ただ、ギークな人たちを除いて、さらっと60点*1のコードなんて書けない。僕を含め大多数のエンジニアは自分自身が書いたクソコードをリファクタリングして60点以上のコードを目指すための時間が必要になる。 そのうえ、そういうコードを書いてもだいたい時間経過に伴って事情が変わって、60点のコードの挙動を壊さないよ
変数の命名規則って名前がついているのですね・・・というのをさっき知ったので・・ほんといまさら聞けない感じです・・ｗ アッパーキャメルケース (UCC)、またはパスカルケース(PascalCase)（Pascal記法） キャメルケース - Wikipedia 複合語の先頭を、大文字で書き始める。 例 ： CamelCase ローワーキャメルケース (LCC)、または単にキャメルケース キャメルケース - Wikipedia 複合語の先頭を、小文字で書き始める。 例 ： camelCase アプリケーションハンガリアン（ハンガリアン記法） ハンガリアン記法 - Wikipedia アプリケーション ハンガリアンは、間違えたコードを間違えて見えるようにする記法である。 たとえば、論理座標にRelative Positionのrp、絶対座標にAbsolute Positionのapというプレフィッ
詳しすぎる詳細設計書 - SiroKuro Page とか 詳細設計書に何を書くべきか？ - Sacrificed & Exploited 関連。 ソースコードと１対１で対応するような仕様書を書いてはならない理由。 日本語は読み上げれるかもしれないが内容を理解できるとは限らない 日本人なら日本語で書かれた相対性理論の教科書を読み上げることはできる。しかし相対性理論を理解できるというわけではない。 日本語は論理演算を表現するのに向いていない OR と XOR の区別がつかなかったり、括弧による演算順番の指定がやたら面倒くさくて見通しの悪いものになったり。 日本語は例外処理を記述するのに向いていない 法律の例外事項とかの読みにくいことと来たら。 日本語はシンタックスハイライトされない 「を」とか「は」とかカラフルになっても嬉しくないけど。 日本語はコンパイラによる静的チェックができない Wor
programmingみんなコード書いてばっかりで、読んでないんじゃないかなぁと思う所があって、なんとなーく新年あけましてだしぃ、ちょっと書いてみました。 コードを読むのは辛いそもそも、ソースコードは他人にわかるような面白い読み物として書かれていません。ソースコードは人間とPCが理解できるような中間のものとして書かれているからです。そのため、ソースコードには、小説のように順序立てられた物語はありません。 したがって、他人のソースコードを読むは大抵の場合「苦痛」を伴います。すごく長い関数とか、GCとか、GCとか…。まぁ、とにかく理解するのには時間が掛かるわけです。 コードを読む理由今、ネット上には世界中の優秀なプログラマが書いたソースコードがタダで公開されています（いい世の中ですね）。そのようなソースコードには必ず「発見」があると思うのです。「おぉっ、こんなやり方があったか」と唸るような「発
2006年10月03日01:00 カテゴリLightweight Languages プログラミング言語foobarの生産性の高さはどこまで本当か 分裂勘違い君って、コードは分裂も勘違いもしてないのね(失礼)。 分裂勘違い君劇場 - Rubyの生産性の高さはどこまで本当か？ もの人がブックマークしているこの「Rubyを仕事に使うべし！Part1 なぜ仕事で使うとうれしいのか」という記事で、Rubyのすばらしさついて、いろいろ書かれていますが、実際のところ、どの部分が、どこまで本当なのでしょうか？ 少し検証してみたいと思います。 それはとにかく、言語の生産性で最も大事なのは何かを改めて考えてみた。 出た結論は、これ。 それを手に入れたくなった時に、それが手元にある事 はっきり言って、「いろんな言語のいいとこ取り」も「構文が強力」も「楽しくプログラミング」も 「問題が起こりにくいように設計され
プロトタイピングツールとしてのLL 佐藤 伸吾 株式会社ケイビーエムジェイ 2008/10/24 「あんなことができたらいいな」と思ったら、とにかくコーディング。軽量プログラミング言語をプロトタイピングツールとして使ってみよう（編集部） 私はプライベートにおいてHacker's Cafeというグループに参加しています。所属組織の枠を超えた緩いつながりの気楽な集まりです。主に土日などの休みを使ってメンバーが集まり、各自好きなコーディングなどを楽しんでいます。 この記事ではHacker's Cafeの活動から生まれたさまざまな成果物の紹介、およびその迅速な開発を可能にした軽量プログラミング言語（LL）のメリットについて解説します。 プロトタイピングツールとしてのLL PCからのハードウェア制御はそれなりの専門知識がないと気軽には試せない分野でした。しかし、現在ではGainerというI/Oモジュ
Googleのコードレビューのプロセス、ツールの紹介がここ（Youtube）にある。55分と長いのでなかなか全部をみる時間がなかったが、休日に時間がとれたので観た。このエントリはそのときのメモだ。 Googleのコードレビューのプロセスはオープンソースのものと似ている。オープンソースのものより若干強制力のあるプロセスとそれをサポートするツール（Mondrian）があるそうだ。ビデオでプレゼンされているのは、Guido van Rossum氏、Pythonの作者でGoogleに就職して最初の仕事がMondrianの開発だったそうだ。定着しているプロセスの実行を支援するツールは非常に頼もしいだろうなぁと思う。 詳細はビデオをみていただきたいが、プレゼンの概要は以下のとおり。 プロセスはオープンソースのレビューのやり方がベースとなっている。 （前のバージョンとの差分をMLに投げるとレビュアがその
I’m Joel Spolsky, a software developer in New York City. More about me. Read the archives in dead-tree format! Many of these articles have been collected into four books, available at your favorite bookstore. It’s an excellent way to read the site in the bath, or throw it at your boss. Ready to level up? Stack Overflow Jobs is the job site that puts the needs of developers first. Whether you want
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
