タグ

*Programmingとcodeに関するwebmarksjpのブックマーク (5)

  • キミのコードが汚い理由 ― @IT情報マネジメント

    リスト1は、同じ処理を繰り返すようなコードで初心者プログラマーがよく使う幼稚なスタイルで書かれている。必ずしも複雑ではないが、筆者には散らかっていて効率が悪く見える。リスト2の方が複雑な条件になっているが、Javaを理解していれば、かなり読みやすい。唯一疑問を抱くかもしれないとしたら、最後の「else if」の中にある条件の最初の部分だけだ。このクローズに来るということは、どちらかのプレーヤーが勝ったことを意味する。 いずれのインプリメンテーションも間違ってはいない。実際、これらはどちらも非常に小さく、つまらない例にすぎないので、これらのリストでコードがいかにクリーンか論ずるのはあまり有益ではない。ただ、何をもってインプリメンテーションがクリーンなのかについて読者の興味を深めることはできるだろう。 クリーンなコードについて扱った記事、Webサイト、書籍は多数存在する。何をもってコードをクリ

  • 【ハウツー】ハイライトもGoogle流 - "google-code-prettify"でソースコードに色付けを

    google-code-prettifyとは? 統合開発環境や高機能エディタでは、編集するソースコードやテキストファイルの種類に応じてテキストがハイライト表示されることが多い。ハイライト表示はきれいで見やすくなるし、コーディング上の問題を発見しやすくなるという実用上の利点もある。 となるとWebで掲載するソースコードも、ぜひともハイライト表示させたいところだ。Web掲載するソースコードやテキストのハイライト表示化の方法はいくつもあるが、ここではGoogleで公開されている「google-code-prettify」を紹介したい。 google-code-prettifyはApache License Version 2.0のもとで公開されているシンタックスハイライトモジュール。JavaScriptモジュールとCSSファイルの2つから構成されたシンプルな成果物で、HTML文書内に直接記述され

  • 小野和俊のブログ:ソースコードのコメント率は20%を切ることが望ましい

    大学の研究室の教官は昔NTT研究所の所長をされていた苗村先生という人で(と言いつつ私は大学の研究室にほとんど顔を出していなかったのだけれど)、彼の発言のうち印象に残っているものの一つとして、昔はソースコードのコメント率が50%を切るものはドキュメント不足で品質が低いものとされた、という内容のものがあった。 今、改めて考えて、どのような言語であってもどのようなコーディング規約であっても、私はソースコードのコメント率は原則20%を切ることが望ましいと思う。可読性の意味でもメンテナビリティの意味でも、開発生産性の意味でも。私が考えるに、来コンピュータが読むためのものであるソースコードに人が読むためのコメントを付け加えなければならないのは、次の2通りの場合だけである。 1.公開されるAPI APIやソースコードそのものが公開される場合、利用者は不特定多数となり、利用者のスキルにもばらつきが出て、

    小野和俊のブログ:ソースコードのコメント率は20%を切ることが望ましい
  • suVeneのあれ: 俺的コーディングルール SQL編

    2007年01月19日 俺的コーディングルール SQLプロジェクトのコーディングルールがこうでなければいけないとか、他人に強制するわけではないが、自分自身で一貫性の無いコードを書くのは気持ち悪いので、オレオレルールを決めてたりする。大抵は デ・ファクト的なルールに沿う形で書くことが多いのだが、SQL や PL/SQL に関してはなかなかデファクトと呼べるものがないので(あるのか?)、メモ的に書きとめておく。 原則キーワード小文字オブジェクト名大文字カンマは後ろインデントは半角スペースで 2一つの SQL 文でキーワード毎にインデントしない(副問合せ除く) まず、1.2. に付いてなのだが、昔は「キーワード=大文字」という意味不明な先入観で大文字で書いていた。ただ、それだと PL/SQL のキーワードも大文字、オブジェクト名も大文字で結局ほとんど大文字になってしまうのと、Shift 押す

  • 森崎修司の「どうやってはかるの?」 > Googleのコードレビュー : ITmedia オルタナティブ・ブログ

    Googleコードレビューのプロセス、ツールの紹介がここ(Youtube)にある。55分と長いのでなかなか全部をみる時間がなかったが、休日に時間がとれたので観た。このエントリはそのときのメモだ。 Googleコードレビューのプロセスはオープンソースのものと似ている。オープンソースのものより若干強制力のあるプロセスとそれをサポートするツール(Mondrian)があるそうだ。ビデオでプレゼンされているのは、Guido van Rossum氏、Pythonの作者でGoogleに就職して最初の仕事がMondrianの開発だったそうだ。定着しているプロセスの実行を支援するツールは非常に頼もしいだろうなぁと思う。 詳細はビデオをみていただきたいが、プレゼンの概要は以下のとおり。 プロセスはオープンソースのレビューのやり方がベースとなっている。 (前のバージョンとの差分をMLに投げるとレビュアがその

    森崎修司の「どうやってはかるの?」 > Googleのコードレビュー : ITmedia オルタナティブ・ブログ
  • 1