アカウント名:
パスワード:
可読性が悪くても、スパゲッティになっていても、動いてナンボだと思います。
そもそも良いコードと悪いコードに違いって何でしょうか。
すでに述べられていることなので、マトメ的な話になろうかと思いますが、
一度だけ動けばいいのであれば、好悪は全く問題になりません。たとえば perlなどで onelinerなプログラムは 記載量が少ないことが正義であって可読性などは全く求めません。動けば捨ててしまえばいいコードですね。
二度以上動いて欲しいなら、それは間違った動作をするかもしれないし、将来的には若干違う動きをしてほしいかもしれない。となれば、未来の自分を含めた第三者が理解できるように記載しなくては、それは「悪いコード」となります。
コードコードといいますが、やってることは 自然言語と同じく、命令を連ねることによる主張そのものですから、何をやっているかをきちんと人間が分かるように書く必要があります。とすれば、「読みやすい」ことが良いコードの条件の1つになります。コメントがその補助になるなら記載すべきでしょう。
あとは保守を考えた場合、同じことを 様々なところに記載してしまうと問題が起きた場合に、修正箇所の特定が難しくなるばかりか、修正の網羅性が疑われる状況が発生してしまいます。エンバグも起こりやすくなります。随時 リファクタリングをして、同じコトを別箇所で書く、ということが発生しないようにしなくてはいけません。ひいては、できるだけ 小さく処理を分けて、メソッドやプロシージャで分けておくようにしておくこと、が求められます。モジュール化しておけば、DBやら各種入出力などの変更があってもビジネスロジックを守る(そのまま使える)ことができます。この「保守性」も 良いコードの条件となります。
最後に忘れがちですが、「パフォーマンス性」、というのも条件のひとつです。まず、計算量が高い箇所を特定するにはコードがシンプルであることが必要です。また、高頻度に稼働する箇所が不必要な処理で計算量が上がっているなら、そこだけ別の単純な処理に換えてやる、というようなことをすればいいわけで、このようなことを考えれば strategyパターンが適用できるところはないか、などと考えながらコーディングすることが重要になるでしょう。
これ位、丁寧に背景説明をしてくれて、その上で「規約を守れ」なら良いのですが、普通は「守れ、以上」なのが現状では無いでしょうか?
残念ながら、こういったことを説明したとしても理解いただけない方が多い、というのが現状ですね。
初めてプロジェクトに参加される方には80:20の法則はもちろん、計算量を減らすために何をすればいいか、基本的なアルゴリズムの性質から、CPUの構造まで落としこんで説明するようにしていますが、なかなか いいコードはでてきません。大規模になれば、コードレビューする余裕もないのが普通でしょう。
幸い、静的なコード解析ツールや、beautifier、コーディング規約の準拠度を調べるようなツールがありますので、一定以上のレベルには落とし込めるのですが、それでもコメントの整備などは、どうしてもうまくいきませんね。ペアプロや BDDを実践すれば、否応なくコメントが集まるのでしょうが、小規模以上のプロジェクトで試みるのは躊躇してしまいます。
自分は一人でプログラムを作っていても、後段のテストなどに役に立つ資料が作れるのでは無いかと考え、ボイスレコーダ(3千円程度。安くなったものです。)を買い、プログラム中に口述を試したのですが、いつもコメントに書いている事以上の事は思いつきもしませんでした。
もしかすると、コメントを書けない人は、もっと反射的なは虫類の脳を使ってプログラミングをしているのでは無いでしょうか?だとしたら、ペアプロやBDDをさせると非常に高負荷がかかり、拷問にも似た状態になってしまう可能性すら有ります。
それくらい専門学校で教えられてると期待するのは無理なんでしょうか。(専門学校出てない方は、自分で学習してね)個々の規約が好ましいかどうかの議論は別。
仮に教えているとして「教わっている」と「覚えている」「身についている」は別の話ですし……(無駄に教育内容に敵意を持ってバカにする人とかも湧くし)
セキュリティー的にはどうなのでしょうか?
6;
と書いてあるより、
//因数の1つは26;
と書いてある方が、分かり易いですが、セキュリティー的にはがたがただと思います。
コメントそのものがセキュリティ上の問題になる、という指摘でしょうか。これはプロジェクトの性質にもよると思いますが、3つの返答ができるでしょう。・コーディング規約上は、「リテラルをコード上に記載するなかれ」 というのを入れておきましょう。"6"なるものが地の文に出てくること 自体をなくします。・コードを納入したりライブラリとして共有することがあるのならば、 逆にこういったコメント記載はより必要性が高いでしょう。・Webなどでソースをさらさないといけ
良いコード: 第三者が見て理解できる (から本人がいなくても改良が容易)悪いコード: 第三者が見て理解できない (から本人がいなくなると作りなおし)
djbやKnuthの例も出てるが、あんな大学でコード書いてるような人達(いわばアーティスト連中)と、ドカタが作る大量生産品を比較しちゃいけないし、ゼネコンの商品ラインナップにアーティストの作品を混ぜても大抵はうまくいかない。
# ウォォン まるで俺は人間コンパイラだ [naver.jp]
確かに、ソースのみから元の仕様について、逆コンパイル的に情報を得ないとならないという状況下では、本家の人の言っていることはもっともだとは思います。もしそれが必要なのが鉄板だとしたら、かの人のコードは悪いと思います。
しかしその様な要件はどこにも書いてありません。ですのでやはり、本家の人の誤りだと思います。
要件が無くても、常識的に良いかどうか判定できるのには、それ以外に2点有ると思います。
1つは、正しく動く事だと思います。この点については、この俎上に上がっている人のコードは悪いとは言えないと思います。
2つは、柔軟性が有る事だとも思います。今でギリで、少しでも変更が入ったらOUTなコードは長い目で見ると悪いと思います。ただ、この点についても、この人のコードが悪いと言える証拠は有りません。
ですので、この話は良いコード、悪いコードの話ではないと思います。良い悪いを持ち出した本家/.erの人の誤りだと思います。
あなたは、だれかが書いたコードを、また別の誰かがメンテナンスする事は永久にない世界にいる。
私達はだれかが書いたコードを、いずれ別の誰かがメンテナンスするのが一般的な世界にいる。
両方にバグがないことが前提だとして
良いコード:可読性が高い悪いコード:可読性が低い
じゃないですかね、メンテナンスする側から見ると別の立場から見ると、そうですね……
経営者的には少ない金額で同じ機能、つまりは費やした時間が短い、書く量が少ないほうが良いコードと言えるかもしれないですね
>経営者的には少ない金額で同じ機能、>つまりは費やした時間が短い、
可読性が低ければメンテナンス時の読解に余分な時間を費やすので経営者的にも同じ結論じゃないですかね
ああ、こういう人がいるから汚ないコードがはびこるんだ。メテンテナンスとかプログラムの再利用とかしたことないんですか?私はあなたが書いたプログラムを読む人にはなりたくない。
いえいえ、そう単純に考えてはいけません。納期こそがすべて、というプロジェクトもありますし、実行スピード命、という状況ではだれも読めないプログラムが一番速いということも多々あります。また、統計・データ解析に使うプログラムでは、一度動けばいいというものもあります。SQLなどでは、審美眼が違う人ばかりでモメまくる、という場合もありますよね:)。そういった保守性や可読性が必要とされないフィールドをメインに活躍されている方も多くいらっしゃいますよ。
何より、動かないよりはずっといいじゃないですか。
この手の動けばいい論には、本当に動いてるの?たまたまでないの?が効きます。
テストセット一式が出てくるなら検証すればいいですし。
汚いコードって何? とういうの??
・整形されていないから読みにくい。・トリッキーな手法を使っていて理解できない?・コメントがない?etc, etc...
良い悪いって結局のところ読み手が読めるかどうかでしょ。最もな理由をつけて「悪い」としているだけじゃないか。
コードを書いた側の意見(設計方針や思想や状況)が無いから判断できないでしょ。まぁ、言い訳ぽくなるので、大抵は悪人扱いですけどね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie
動いてナンボ (スコア: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などでソースをさらさないといけ
Re: (スコア:0)
Re: (スコア:0)
正直このトピのコードみたいなのは規約で静的解析ツールとユニットテスト義務づければ100%解決するとは思うけど。
Re: (スコア:0)
良いコード: 第三者が見て理解できる (から本人がいなくても改良が容易)
悪いコード: 第三者が見て理解できない (から本人がいなくなると作りなおし)
djbやKnuthの例も出てるが、あんな大学でコード書いてるような人達(いわばアーティスト連中)と、ドカタが作る大量生産品を比較しちゃいけないし、ゼネコンの商品ラインナップにアーティストの作品を混ぜても大抵はうまくいかない。
# ウォォン まるで俺は人間コンパイラだ [naver.jp]
Re: (スコア:0)
確かに、ソースのみから元の仕様について、逆コンパイル的に情報を得ないとならないという
状況下では、本家の人の言っていることはもっともだとは思います。
もしそれが必要なのが鉄板だとしたら、かの人のコードは悪いと思います。
しかしその様な要件はどこにも書いてありません。ですのでやはり、本家の人の誤りだと思います。
要件が無くても、常識的に良いかどうか判定できるのには、それ以外に2点有ると思います。
1つは、正しく動く事だと思います。この点については、この俎上に上がっている人のコードは
悪いとは言えないと思います。
2つは、柔軟性が有る事だとも思います。今でギリで、少しでも変更が入ったらOUTなコードは
長い目で見ると悪いと思います。ただ、この点についても、この人のコードが悪いと言える証拠は
有りません。
ですので、この話は良いコード、悪いコードの話ではないと思います。良い悪いを持ち出した
本家/.erの人の誤りだと思います。
Re: (スコア:0)
あなたは、だれかが書いたコードを、また別の誰かが
メンテナンスする事は永久にない世界にいる。
私達はだれかが書いたコードを、いずれ別の誰かが
メンテナンスするのが一般的な世界にいる。
Re: (スコア:0)
両方にバグがないことが前提だとして
良いコード:可読性が高い
悪いコード:可読性が低い
じゃないですかね、メンテナンスする側から見ると
別の立場から見ると、そうですね……
経営者的には少ない金額で同じ機能、
つまりは費やした時間が短い、
書く量が少ないほうが良いコードと言えるかもしれないですね
Re:動いてナンボ (スコア:1)
>経営者的には少ない金額で同じ機能、
>つまりは費やした時間が短い、
可読性が低ければメンテナンス時の読解に余分な時間を費やすので
経営者的にも同じ結論じゃないですかね
Re: (スコア:0)
ああ、こういう人がいるから汚ないコードがはびこるんだ。
メテンテナンスとかプログラムの再利用とかしたことないんですか?
私はあなたが書いたプログラムを読む人にはなりたくない。
Re: (スコア:0)
いえいえ、そう単純に考えてはいけません。
納期こそがすべて、というプロジェクトもありますし、実行スピード命、という
状況ではだれも読めないプログラムが一番速いということも多々あります。また、
統計・データ解析に使うプログラムでは、一度動けばいいというものもあります。
SQLなどでは、審美眼が違う人ばかりでモメまくる、という場合もありますよね:)。
そういった保守性や可読性が必要とされないフィールドをメインに活躍されている
方も多くいらっしゃいますよ。
何より、動かないよりはずっといいじゃないですか。
Re: (スコア:0)
この手の動けばいい論には、
本当に動いてるの?たまたまでないの?
が効きます。
テストセット一式が出てくるなら検証すればいいですし。
Re: (スコア:0)
汚いコードって何? とういうの??
・整形されていないから読みにくい。
・トリッキーな手法を使っていて理解できない?
・コメントがない?
etc, etc...
Re: (スコア:0)
良い悪いって結局のところ読み手が読めるかどうかでしょ。
最もな理由をつけて「悪い」としているだけじゃないか。
コードを書いた側の意見(設計方針や思想や状況)が無いから判断できないでしょ。
まぁ、言い訳ぽくなるので、大抵は悪人扱いですけどね。