コードを特に良いものとするのは何？ 98
ストーリー by headless
品質 部門より
品質 部門より
本家/.「Ask Slashdot: What Makes Some Code Particularly Good?」より
何がソースコードを特に「良い」ものとするのかについて開発者が話すとき、一握りの特徴が繰り返し言及される傾向がある(動作する、読みやすい、テストできる)。皆さんなら何をリストに加えるだろうか。
元記事のITworldでは良質なコードの特徴として、以下の8つを挙げている。
- 正しく動作すること
- 読みやすいこと
- テストできること
- メンテナンスしやすいこと
- きれいに整形されていること
- 変更しやすいこと
- シンプルであること
- 効率が良いこと
標準ライブラリを正しく使うこと (スコア:4, すばらしい洞察)
車輪の再発明はしないこと
追加で (スコア:4, すばらしい洞察)
コメントが過不足なく記述されてること。
コードの意図が汲み取り易く書かれていること。
八つ？ (スコア:2)
1,3も一つに出来そう。
よって、三パターンで収まるでしょう。
Re:八つ？ (スコア:1)
さすがにそれは乱暴じゃね。
たとえばレガシーコードなんかで、「正しく動作してるけどテスト不可能」なんて珍しくも無い希ガス
Re: (スコア:0)
その理屈だと、正しく動作していればそれでいいという主張に近い。
確かに、レガシーコードなど、変更の必要がないものは 1 だけで良さそうに見えますね。
そして、レガシーコードを修正する羽目になるときに、恨み言の一つや二つを吐きたくなるという話は時々あります。
レガシーコードでない、変更が頻繁に必要になるコードでテスト不可能というのは、良質なコードの特徴の資格を欠いているといわざるを得ません。
よいチームが一番 (スコア:2, すばらしい洞察)
結局、悪いコードを指摘してくれて、議論をできるチームが一番。
変に気を使って指摘できない雰囲気や、
勝手に怒り出すバカが混ざると、コードの品質はがた落ちだとおもう。
結合度 (スコア:2)
自分が知らなくてもよいことは知らない、相手が何をしてくれるひとかは知っているけど、具体的に何をどうやっているのかは知らない。
プログラマでこういう概念をわかってくれる人は結構少ない。
Re:結合度 (スコア:1)
結合度の低さは確かに重要ではありますけど、このリストに挙げられる目標と言うより、実現するための手段なんじゃないですかね？
「結合度の低さ」そのものが目標になってはいけないと思います。
余裕を持ったスケジュールにすること (スコア:2)
欲を言えば予算にも余裕を持ったスケジュールだと嬉しいですね
よいデータ構造が一番 (スコア:1)
きちんと設計されたデータ構造があればコードなんてクソでもよくね？
Re: (スコア:0)
二次元配列なんてxとyどちらから走査しても良いと。
Re: (スコア:0)
プログラム＝データ構造＋アルゴリズム
Re:よいデータ構造が一番 (スコア:1)
プログラム＝データ構造＋アルゴリズム
コンピュータ・システム開発を仕事にする続にコの業界の人たちの使う
「ロジック」
という隠語は上記のうちどの部分を意味する・含む/含まれるものなのでしょうか?
// あるいは包含関係などない捩れの位置にあるとか世界線の彼方の事象であるとか。。。
Re:よいデータ構造が一番 (スコア:1)
どっちかというと「アルゴリズム」寄りな考え方ですが、
データ構造、アルゴリズムなどプログラム・コードレベルの概念とは切り離して考えたほうが良い言葉ですね。
ロジックは文字通り「論理」です。
開発者は、システムをうまく制御するための論理を考えます。
その論理を実現するために適切な「データ構造」と「アルゴリズム」を決めて、それをコードに起こす訳です。
そのため、「ロジック」に誤りがあった場合、コードレベルでは「データ構造」、「アルゴリズム」の双方に修正が必要になることもよくあります。
という訳で、「ロジック」というのは「大まかなプログラムの処理手順」ぐらいの理解でよいかと思います。
Re: (スコア:0)
プログラム＝ロジック＋コントロール
しっかりエラーチェックをしている (スコア:1)
「mallocの返り値チェック」は有名かと思いますが、そういったエラーチェックを丁寧にやっているかどうか。
例外のある言語で、例外のハンドリングをきちんと(ルールを決めて)やっているか。
「実際に使われるアプリケーションのソースコードの半分は、本来の処理ではなくエラーチェック」的な話もどこかで見た覚えがありますので、基本かもしれませんが。
基本を守るのが難しい、ということはあるかもしれません。
私も、c++で"out of range"をやらかすことがあるので、気をつけなければ。
Re:しっかりエラーチェックをしている (スコア:1)
mallocの戻り値をチェックしていてもreallocの戻り値をチェックしてないことが多い
Re: (スコア:0)
「mallocの返り値チェック」は有名かと思いますが、そういったエラーチェックを丁寧にやっているかどうか。
思わぬところ [www.moae.jp]で晒されたりしてもカッコ悪いですね。
Re: (スコア:0)
確かにチェックしてねえ
十分な休息かと (スコア:1)
休息。休息。休息。
私は休息に１票入れます。
上記の条件を備えたエスプレッソマシン (スコア:4, おもしろおかしい)
正しく動作すること
>コーヒーが出てくる。
読みやすいこと
>取扱説明書が。(セブンイレブンコーヒーのHOT/COOLボタンの話ではなく)。
テストできること
>テスト用の豆が添付されているとベスト(そこなのか？)。
メンテナンスしやすいこと
>洗いやすい(超重要)。
きれいに整形されていること
>見た目が綺麗だと嬉しい。味に関係ないことはよくわかっているが見た目が良いに越したことはない。
変更しやすいこと
>コーヒーの味のバリエーションが。
シンプルであること
>操作が。
効率が良いこと
>豆の使用量が少ない。
ごめんなさい、単にわたしが職場にほしい物を書いただけです。
Re: (スコア:0)
マジレスするとエスプレッソマシンでは味のバリエーション変更できないぞ。
役割を超えたコード書くのは間違いだ。
Re: (スコア:0)
エスプレッソマシンみたいなバッチ処理機で、豆を変更しようと、コーヒーの味のバリエーション変更できないとする論拠を伺いたい。
Re: (スコア:0)
そう、豆や焙煎を変えるのが基本で次にメッシュの荒さ、タンピング、バスケットの変更で微調整。
エスプレッソマシンがロブスタベースのブレンドをマンデリンベースと感じるように変更する事はできないし、試みるのも間違っている。
Re:上記の条件を備えたエスプレッソマシン (スコア:1)
＞ロブスタベースのブレンド
それはコーヒーじゃないから話が別（原理主義者）
Re:上記の条件を備えたエスプレッソマシン (スコア:1)
＞＞ロブスタベースのブレンド
何度もこの味じゃないという実感があったので
わたしは自分自身を原理主義者だと思っていないですが
強く同意します。
// どうしてベトナム産はああなんだろう。近寄りたくない。
http://futures-s.com/lobster/index.html [futures-s.com]
Re:上記の条件を備えたエスプレッソマシン (スコア:1)
全国展開でなくてもいいけどパッケージ入り各社製の安いブレンドの粉コーヒーを買うと原産地を配合比を多い順に記載していますよ。
ごくたまに懐に余裕があるときにインドネシア産・ベトナム産とかロブスタの産地として知られているところを排除して買うとか、原産地別に豆を扱っているときに飲み味わったときと比較すればコレジャナイ感を知ることはできるんじゃないでしょうか。そんなこんな。
あと高確率で確実なのはアイスコーヒー用と銘打ってある粉ブレンドをホットコーヒーにして淹れるとか。
Re:十分な休息かと (スコア:1)
一度目の休息は自分の為。
二度目の休息はみんなの為。
三度目の休息は念の為。
でしたっけ？
#存在自体がホラー
Re:十分な休息かと (スコア:1)
Re: (スコア:0)
それから十分な賃金が支払われていること
Re: (スコア:0)
十分な実力を備えた人員は？
テストに着目すると…… (スコア:1)
「正しく動作すること」というのは、「良質なコードの特徴」といってもコードを見ただけでは分からないですよね。
そういう訳で、全体的に「特徴」というよりも「希望(うすいのぞみ)」として捉えたほうが腑に落ちます。
＊ ＊ ＊
1,3は一つにまとめたい気がする。テストができないのに正しく動作すると言い張られても嫌だし。
> 1. 正しく動作すること
> 3. テストできること
→ 正しく動作することを確認するテストがあること。
もうすこし具体的に言うなら、こうかな。
- すべての機能が自動化されたテストで正しく動作することを確認できること
- 自動化されたテストを現実的なコストで追加できるように関数・モジュール設計をしていること
悪い例ならすぐにいくつも思いつくだろ？ (スコア:1)
自分が最近見たやつだと、pcsensorのCソース。これは酷かった。
Raspberry Piで常時温度計測しようと思ってRDing Temper買ってきて、Linuxから使おうとGithubからpcsensor落としてきたら、あまりの酷さに絶句した。
ただ落としてきてビルドするだけだったら気づかなかったんだろうけど、libusbの0.1系に依存して書かれてるから1.0系に書き直そうかと思って中見たら・・・。
あれは本当に凄いよ。
たった1ファイル。それもたった450行のソースでありながら、リファクタしようという気力を根刮ぎ圧し折られるほどの圧倒的コーディング。
一体どのような精神状態の元、あんなコードを書き上げられたんだろうと逆に興味が湧いてくるほど。
Re: (スコア:0)
”pcsensor github"でぐぐって [google.co.jp]出てきたの見たけど別にぜんぜん大したことないなあ。おれならもっと酷いコード平気で書ける自信あるわ。
Re: (スコア:0)
ざっと見た限り、初見でも何やってるのかわかる読みやすいコードだと感じましたが、どの辺りが酷いと感じたのか興味あります。
一点 bsalirという変数の名前の意味がわからなかったのですが、salirがスペイン語で「出る」というような意味らしいのでだいたいそういう意味かと。
Re: (スコア:0)
(このツリーでクソコード自慢が始まる予感がする)
言語の選択 (スコア:1)
良いコードを書くためになによりまず必要なのは、良いプログラミング言語を使うこと。
良い言語で書かなければ、良いコードを模索しても徒労に終わる。
クソ言語で良いコードを目指すというのは、犬のクソを美味しい料理に調理する方法を考えるようなものだ。
まずは良い言語を選び良いフレームワークを選ぶ。話はそれからだ。
クソ言語を使わざるをえない状況なら、少しでも良いコードを目指すことがまったくの無駄だとは言わないけど、
その努力を他に振り向けたほうがはるかに幸せになれる
Re: (スコア:0)
1～8が実践できないプログラム言語があると言っているのか、
あるいは、1～8のリストに追加する項目があるのかどちらでしょうか？
後者だとした場合、どういった特徴の言語仕様、あるいはフレームワークを使うべきなのでしょうか。
Re: (スコア:0)
どっちでもないよ。
「少しでも良いコードを目指すことがまったくの無駄だとは言わない」って言ったように、どんな言語でも良いコードを目指す余地はあり、
当然「1～8が実践できないプログラム言語がある」などということにはならない。
それに「1～8のリストに追加する項目がある」なんてことは俺はまったく言っていないな。
俺はそのどちらかの話をしてるとなぜあなたが思ったのか、さっぱりわからない。
Re: (スコア:0)
コード以前に人生の無駄だからね
PHPとかPHPとか
自己満足 (スコア:1)
客のために仕事をしようとすると、納品と検収がゴールになり、それに至るまでがやっつけ仕事になってしまう。
自分のために創作すると、過程を重視するし、完成度をより高めようという意欲が湧く。作品への愛着も高まる。
その結果、高品質なものができる。
経験上、客を満足させようとすると、ろくなものができない。自分を満足させようとすると良いものができる。
「自分さえ満足してしまえばそれでおしまい」というのは、悪い自己満足だ。だけど、自己満足の全てが悪だとは思わない。
自分ひとりさえ満足させられないものを、客に提供するのは、職人として不誠実なことだ。
ソフトウェアに限らず、多くの分野の職人にも当てはまるのではないだろうか。
自分に自信がありませんというシェフの作った料理を誰が食べたいと思うだろうか。
自己満足がゴールではなく、それは通過点であり、「自己満足は大勢満足の必要条件」だという発想をもてば、
良いものができる可能性が開ける。
一画面に収まること (スコア:1)
懐かしいですね、
MSX-FAN。
あれでプログラムの本質を分かった気がします。
-- 風は東京に吹いているか
9. キシリア様に送ること (スコア:1)
こんだけコメント付きながら、こういう脱線がないところにみんなの疲労感が見て取れるというか :-)
#若手によいコードを書かせるのに苦労してる年寄りばかりになったともいう
不良でない≠良質。 (スコア:0)
正しく動くことは最低限の目標です。しかし開発期間中のほとんどにおいて当面の目標となります。
Re:不良でない≠良質。 (スコア:5, おもしろおかしい)
往々にしてそれは最終の目標になります。
先頭の看板のAuthorには・・ (スコア:0)
自分の名前を書かない。
・・たぶん良い事だ。(嘘)
二点くらい追加〜 (スコア:0)
・一貫したルールが適用されていること。一部分でしか適用されないルールとか、部分によってルールの目的は同じなのに、異なるルールが適用されてたりしないこと。
・不必要なオリジナリティが無いこと。オリジナリティは、それが無ければプロダクトの優位性が失われる、という場面に限り、存分に発揮すること。それ以外のシーンでは、多少枯れた、標準的な手法に愚直なほどに忠実であること。
ええと (スコア:0)
書く前にCode completeと達人プログラマ読ませて。
言語特有のコーディングルールの本５冊読ませればいいんじゃね
Re:人類コード化計画 (スコア:1)
人員がコードの奴隷になる職場とどっちが幸せだと思う？
#存在自体がホラー
Re:適切なアルゴリズム (スコア:1)
そういう点なら、Java7やAndroidに組み込まれており、盛大にバグっている [srad.jp]ことが判明したTimSort [preferred.jp]なんかは、保守性最悪のアルゴリズムじゃないかと思ってしまいますね。