アカウント名:
パスワード:
可読性が悪くても、スパゲッティになっていても、動いてナンボだと思います。
そもそも良いコードと悪いコードに違いって何でしょうか。
すでに述べられていることなので、マトメ的な話になろうかと思いますが、
一度だけ動けばいいのであれば、好悪は全く問題になりません。たとえば perlなどで onelinerなプログラムは 記載量が少ないことが正義であって可読性などは全く求めません。動けば捨ててしまえばいいコードですね。
二度以上動いて欲しいなら、それは間違った動作をするかもしれないし、将来的には若干違う動きをしてほしいかもしれない。となれば、未来の自分を含めた第三者が理解できるように記載しなくては、それは「悪いコード」となります。
コードコードといいますが、やってることは 自然言語と同じく、命令を連ねることによる主張そのものですから、何をやっているかをきちんと人間が分かるように書く必要があります。とすれば、「読みやすい」ことが良いコードの条件の1つになります。コメントがその補助になるなら記載すべきでしょう。
あとは保守を考えた場合、同じことを 様々なところに記載してしまうと問題が起きた場合に、修正箇所の特定が難しくなるばかりか、修正の網羅性が疑われる状況が発生してしまいます。エンバグも起こりやすくなります。随時 リファクタリングをして、同じコトを別箇所で書く、ということが発生しないようにしなくてはいけません。ひいては、できるだけ 小さく処理を分けて、メソッドやプロシージャで分けておくようにしておくこと、が求められます。モジュール化しておけば、DBやら各種入出力などの変更があってもビジネスロジックを守る(そのまま使える)ことができます。この「保守性」も 良いコードの条件となります。
最後に忘れがちですが、「パフォーマンス性」、というのも条件のひとつです。まず、計算量が高い箇所を特定するにはコードがシンプルであることが必要です。また、高頻度に稼働する箇所が不必要な処理で計算量が上がっているなら、そこだけ別の単純な処理に換えてやる、というようなことをすればいいわけで、このようなことを考えれば strategyパターンが適用できるところはないか、などと考えながらコーディングすることが重要になるでしょう。
これ位、丁寧に背景説明をしてくれて、その上で「規約を守れ」なら良いのですが、普通は「守れ、以上」なのが現状では無いでしょうか?
残念ながら、こういったことを説明したとしても理解いただけない方が多い、というのが現状ですね。
初めてプロジェクトに参加される方には80:20の法則はもちろん、計算量を減らすために何をすればいいか、基本的なアルゴリズムの性質から、CPUの構造まで落としこんで説明するようにしていますが、なかなか いいコードはでてきません。大規模になれば、コードレビューする余裕もないのが普通でしょう。
幸い、静的なコード解析ツールや、beautifier、コーディング規約の準拠度を調べるようなツールがありますので、一定以上のレベルには落とし込めるのですが、それでもコメントの整備などは、どうしてもうまくいきませんね。ペアプロや BDDを実践すれば、否応なくコメントが集まるのでしょうが、小規模以上のプロジェクトで試みるのは躊躇してしまいます。
自分は一人でプログラムを作っていても、後段のテストなどに役に立つ資料が作れるのでは無いかと考え、ボイスレコーダ(3千円程度。安くなったものです。)を買い、プログラム中に口述を試したのですが、いつもコメントに書いている事以上の事は思いつきもしませんでした。
もしかすると、コメントを書けない人は、もっと反射的なは虫類の脳を使ってプログラミングをしているのでは無いでしょうか?だとしたら、ペアプロやBDDをさせると非常に高負荷がかかり、拷問にも似た状態になってしまう可能性すら有ります。
それくらい専門学校で教えられてると期待するのは無理なんでしょうか。(専門学校出てない方は、自分で学習してね)個々の規約が好ましいかどうかの議論は別。
仮に教えているとして「教わっている」と「覚えている」「身についている」は別の話ですし……(無駄に教育内容に敵意を持ってバカにする人とかも湧くし)
セキュリティー的にはどうなのでしょうか?
6;
と書いてあるより、
//因数の1つは26;
と書いてある方が、分かり易いですが、セキュリティー的にはがたがただと思います。
コメントそのものがセキュリティ上の問題になる、という指摘でしょうか。これはプロジェクトの性質にもよると思いますが、3つの返答ができるでしょう。・コーディング規約上は、「リテラルをコード上に記載するなかれ」 というのを入れておきましょう。"6"なるものが地の文に出てくること 自体をなくします。・コードを納入したりライブラリとして共有することがあるのならば、 逆にこういったコメント記載はより必要性が高いでしょう。・Webなどでソースをさらさないといけ
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
人生unstable -- あるハッカー
動いてナンボ (スコア:0)
可読性が悪くても、スパゲッティになっていても、動いてナンボだと思います。
そもそも良いコードと悪いコードに違いって何でしょうか。
Re:動いてナンボ (スコア:1)
すでに述べられていることなので、マトメ的な話になろうかと思いますが、
一度だけ動けばいいのであれば、好悪は全く問題になりません。
たとえば perlなどで onelinerなプログラムは 記載量が少ないことが
正義であって可読性などは全く求めません。動けば捨ててしまえばいい
コードですね。
二度以上動いて欲しいなら、それは間違った動作をするかもしれないし、
将来的には若干違う動きをしてほしいかもしれない。
となれば、未来の自分を含めた第三者が理解できるように
記載しなくては、それは「悪いコード」となります。
コードコードといいますが、やってることは 自然言語と同じく、
命令を連ねることによる主張そのものですから、何をやっているかを
きちんと人間が分かるように書く必要があります。
とすれば、「読みやすい」ことが良いコードの条件の1つになります。
コメントがその補助になるなら記載すべきでしょう。
あとは保守を考えた場合、同じことを 様々なところに記載してしまうと
問題が起きた場合に、修正箇所の特定が難しくなるばかりか、
修正の網羅性が疑われる状況が発生してしまいます。
エンバグも起こりやすくなります。
随時 リファクタリングをして、同じコトを別箇所で書く、ということが発生
しないようにしなくてはいけません。
ひいては、できるだけ 小さく処理を分けて、メソッドやプロシージャで
分けておくようにしておくこと、が求められます。
モジュール化しておけば、DBやら各種入出力などの変更があっても
ビジネスロジックを守る(そのまま使える)ことができます。
この「保守性」も 良いコードの条件となります。
最後に忘れがちですが、「パフォーマンス性」、
というのも条件のひとつです。
まず、計算量が高い箇所を特定するにはコードがシンプルで
あることが必要です。また、高頻度に稼働する箇所が
不必要な処理で計算量が上がっているなら、そこだけ
別の単純な処理に換えてやる、というようなことをすれば
いいわけで、このようなことを考えれば strategyパターンが
適用できるところはないか、などと考えながらコーディング
することが重要になるでしょう。
Re: (スコア:0)
これ位、丁寧に背景説明をしてくれて、その上で「規約を守れ」なら良いのですが、
普通は「守れ、以上」なのが現状では無いでしょうか?
Re: (スコア:0)
さらに守る価値もない規約だったりすることがよくありますね。
Re: (スコア:0)
残念ながら、こういったことを説明したとしても理解いただけない方が多い、というのが現状ですね。
初めてプロジェクトに参加される方には80:20の法則はもちろん、計算量を減らすため
に何をすればいいか、基本的なアルゴリズムの性質から、CPUの構造まで落としこんで
説明するようにしていますが、なかなか いいコードはでてきません。
大規模になれば、コードレビューする余裕もないのが普通でしょう。
幸い、静的なコード解析ツールや、beautifier、コーディング規約の準拠度を調べるような
ツールがありますので、一定以上のレベルには落とし込めるのですが、
それでもコメントの整備などは、どうしてもうまくいきませんね。
ペアプロや BDDを実践すれば、否応なくコメントが集まるのでしょうが、小規模以上の
プロジェクトで試みるのは躊躇してしまいます。
Re: (スコア:0)
自分は一人でプログラムを作っていても、後段のテストなどに役に立つ資料が作れるのでは
無いかと考え、ボイスレコーダ(3千円程度。安くなったものです。)を買い、プログラム中に
口述を試したのですが、いつもコメントに書いている事以上の事は思いつきもしませんでした。
もしかすると、コメントを書けない人は、もっと反射的なは虫類の脳を使ってプログラミングを
しているのでは無いでしょうか?
だとしたら、ペアプロやBDDをさせると非常に高負荷がかかり、拷問にも似た状態になって
しまう可能性すら有ります。
Re: (スコア:0)
それくらい専門学校で教えられてると期待するのは無理なんでしょうか。
(専門学校出てない方は、自分で学習してね)
個々の規約が好ましいかどうかの議論は別。
Re: (スコア:0)
仮に教えているとして
「教わっている」と「覚えている」「身についている」は別の話ですし……
(無駄に教育内容に敵意を持ってバカにする人とかも湧くし)
Re: (スコア:0)
セキュリティー的にはどうなのでしょうか?
6;
と書いてあるより、
//因数の1つは2
6;
と書いてある方が、分かり易いですが、セキュリティー的には
がたがただと思います。
Re: (スコア:0)
コメントそのものがセキュリティ上の問題になる、という指摘でしょうか。
これはプロジェクトの性質にもよると思いますが、3つの返答ができるでしょう。
・コーディング規約上は、「リテラルをコード上に記載するなかれ」
というのを入れておきましょう。"6"なるものが地の文に出てくること
自体をなくします。
・コードを納入したりライブラリとして共有することがあるのならば、
逆にこういったコメント記載はより必要性が高いでしょう。
・Webなどでソースをさらさないといけ