良いプログラムとされるプログラムはどんな特徴でしょうか？ 「良いプログラム」の条件を挙げてください。

良いプログラムとされるプログラムはどんな特徴でしょうか？
「良いプログラム」の条件を挙げてください。

No.1 回答者： daaa- 回答日時： 2023/01/01 14:15

仕様書通りに動きバグが無い。

No.2 回答者： bari_saku 回答日時： 2023/01/01 15:05

他人が見てわかりやすい。

No.3 回答者： kamiyasiro 回答日時： 2023/01/01 17:38

#2さんと同じですが、「可読性が高い」

一行に詰め込まず、何行にもコマンドを分けて書いてあれば、処理の流れが追えますし、デバッグもしやすいです。

もうひとつ、「他のモジュールやアプリから独立性が高い」

たとえ、冗長になっても、変数の定義や読み込みをいちいち行っていれば、他のモジュールの設計変更があっても影響が及ばず、改修作業が楽です。それはすなわち修正ミスによるバグの発生防止にもつながります。

ただ、プラットホーム・プログラミングの場合は、変数の受け渡しが仕様書にしっかり書いてあるので、よっぽどだ丈夫とは思いますが・・・。

No.4 回答者： cametan_42 回答日時： 2023/01/01 22:48

「良いプログラム」って何だろうね?

ぶっちゃけた事を言うと、それは「貴方が決める事」であって、他人に問うことではない、と言う事は言える。
まぁ、なんかのSurveyのつもりかもしれないけど。

例えば、だぜ。
大まかにユーザーとプログラムする側に分けてみよう。
ユーザーが言う「良いプログラム」とかは、単に「バグがなく」「動作が早く」「UIが分かりやすい」ってのになるだろ。
ユーザー的に言うと「出来たプログラム」がどういう動作なのか、が重要なんであって、「どう書かれてるのか」ってのは関係ねぇんだよな。
言っちゃえば「何の言語で書かれてるのか」も関係がない。「可読性」なんかも関係がない。
と言う事は、プログラマ側が考える「良いプログラム」とユーザーが評価する「良いプログラム」ってのは全く関係がない、ってこった。
どっちの立場で言ってるのか、ってのが明確じゃないとどうにも答えづらい話になるわな。

例えば、だぜ。
ユーザーの立場から言うと、「ディスク専有スペースが少なく」「メモリ占有率も低く」「高速に動作する」プログラムが「良いプログラム」って事になるだろう。
ここで例えばモジュール化、ってのを見てみよう。関数だろうがクラスだろうが構わないけど。
構造化プログラミング言語の雄、C言語がAT&Tで初めて作られた際。AT&Tの連中はC言語を使う事を嫌がったそうだ。何故なら、「構造化プログラミング」技法で書かれたプログラムは低速化する、と信じてた人たちが多かったから、だそうだ。
事実、C言語開発者のデニス・リッチー達はその事実を知ってたそうだ。現代のコンピュータは速いんで全然気にならないレベルになってるけど、モジュール化するとプログラムは遅くなる。つまり明らかに「当時のハードウェアのレベル(って事はメインフレームだ)」だとユーザーが不利益を被ってたわけだよな。
デニス・リッチー達は「そんな事は起こり得ない」と「嘘を言って」まずはAT&T内で自分達以外のプログラマを説得しまくったそうだ。
当時のプログラマは圧倒的にマシン語/アセンブリ言語を使ってて、良くってFortranを使ってた。今で言う「バッチ式のプログラム」を書いてて、それで高速なプログラムを書く事が「良い事だ」って思ってて、それはそれでメリットがあったわけだよな。それが「良いプログラム」だった。
一方、デニス・リッチー達の「布教」のお陰で、徐々にAT&T内でのC言語の使用率が上がっていった。モジュール化すると「書きやすい」って事にプログラマ側が気づいていった、って事だ。
ただし、そこではトレードオフが生じる。それは、ユーザー側がある意味「不利益を生じる」って事だよな。出来たプログラムはアセンブリ/マシン語で書かれたプログラムより低速化する。
分かる?「プログラマ側にとって書きやすくわかりやすくなった」開発環境が直にユーザー側にメリットがある、とは限らない、と言う事を。今はハードウェアが速くなったから気にならなくなったけど、立場によっては「良いプログラム」の意味が変わるんだ。
同じような事は90年代初頭までのゲーム機でも起きてたでしょ?当時のゲームプログラマはアセンブリゴリゴリ書いてたし。「コンパイラで高級言語で書かれたソースコードをコンパイルする」ってのはゲームの低速化に繋がる、って信じられてたし事実そうだった。だから殆どのゲームプログラマはバリバリのアセンブリユーザーだったし、「コンパイラが自動生成したアセンブリのコード」なんざ全然信用してなかった。「絶対低速化する無駄がある」って思ってたし、そんな軟弱な事をするんだったらアセンブリを直書きするのが性技もとい正義だった。

UIに付いても考えてみよう。
例えばWindowsで良くあるGUIの「決定ボタン」とか。何らかの設定を変えて「決定ボタン」をクリックすると設定の改変が確定する。
ところが、大方のLinuxのGUIだとこの「決定ボタン」が存在しないケースが散見する。設定編集のラジオボタンなんかを選ぶともう「設定改変」が反映するようなインターフェースになってるブツが結構多いんだよ。
実の事言うと、「余計なプロセスを要求しない」Linuxのスタイルの方が「プログラムする側」としては「良い」って事になる。プログラマ側の観点としては「無駄なコードを実装しない」方がシンプルで「良い」って事になるわけだ。
一方、ユーザー側の立場から言うと「気持ち悪い」だろ(笑)。一体いつ、どのプロセスで「設定変更」が実行されたか分からん。エルゴノミクス的な観点だと、敢えての「決定プロセス」があった方がいいんだわ。

こう言うカンジで、特にユーザー側が思う「良いプログラム」とプログラムを組む方が考える「良いプログラム」はしばしば同じにならないんだ。
他にも、オープンソースでのプログラマだとEmacs愛用者が多いんだけど、Emacsのキーバインドを採用したWebブラウザとか、一体誰が使いたがるんだ、なんつー事も起きる(過去のFirefoxがそうだった)。
いずれにせよ、「一般的な話として」の良いプログラム、なんて定義出来ないよね。
貴方の立場で、貴方が考える「良いプログラム」が何なのか、って定義がないと条件なんて一般論では出てこないと思う。

No.5 回答者： kihonkana 回答日時： 2023/01/02 08:36

よいプログラムってことではないですけど、

読みやすいプログラムなら
「リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)」という本を読んでみてください。

No.6 ベストアンサー 回答者： tknakamuri 回答日時： 2023/01/02 18:14

良いプログラムの「良い」にはいろんな観点が有る。

私の今携わったいるプロジェクトでは
①機能追加が簡単
②仕様変更が容易
が良いプログラム。

枝葉末節よりプログラムの「構造」が大事。
個別のコードよりモジュール/コンポーネントの「設計」
が様々な原理やベストプラクティスを満たしていることが大事。

IOCとかをきちんと使ってモジュール間の依存性をきれいに
分離できてるプログラムは良いプログラム。
その辺がぐちゃぐちゃなのはごみ。

但し、こうした優れたプログラムは力量の無いプログラマには
難解だ。必ずしも読みやすくはない。依存性を無くすための
仕掛けはちゃんと勉強しないと何が書いてあるかわからない。
頭が痛い問題です。

No.7 回答者： kamiyasiro 回答日時： 2023/01/03 17:16

#3ですが、#6さんに１票。

確かにモジュール間の独立性を担保すると、可読性は落ちますね。
となると、最優先は、#6さんのおっしゃる通りだと思います。

今は、オンラインで機能更新とかやる時代です。それをプラグインで実現するには、モジュール間の独立性の担保が重要ですね。