クソコードとは何か

**デフォルトの名無しさん** · 2021/01/30(土) 17:33:05.78

このスレはクソコードとは何かを考えるスレです。

・親クラスが子クラスに依存する処理を持つコード
例...社員クラスを継承した正社員クラスと派遣社員クラスがあり、社員クラスが正社員クラスの知識を持つ状況

・staticにするべきではないモデルにまでstaticにする人
例...社員クラスのメソッドを全てstaticにしたり、社員クラスにシングルトンパターンに相応するものを適用する人

等、クソコードを見た時に「あっ、これクソコードだ」って認識する根拠を挙げていきましょう。

**デフォルトの名無しさん** · 2021/03/01(月) 06:52:02.27

>>805
おいお前話を広げろ、今のお前は他人のヘイトやってるだけのクソ野郎だからそうじゃないところを見せろ

**デフォルトの名無しさん** · 2021/03/01(月) 06:56:37.18

あ、間違ってたも
>>805は僕に同意してたわけね
でも僕は敏感な人間だから僕に言われてることだと思った、だけれども紛らわしい言い方した君が悪い、僕は絶対に悪くないからこの件は以後言及することを禁止します、以上

**デフォルトの名無しさん** · 2021/03/01(月) 07:06:26.34

上に出てるパターン・ランゲージってアレクザンダーの都市計画理論だろ、プログラミングの本じゃない、そんなたとえ話のようなものでわかった気になるのは危ない

Twitterでも建築の本読んでオブジェクト指向がどうとか言ってる人いるけどポストモダンなソーカル野郎としか思えないんだよなあ、関係のないことを関係づけてそこに気づいた自分が賢いと思いこんでしまうクルクルパー、地頭の良い人が陥りやすい穴のように見える

**デフォルトの名無しさん** · 2021/03/01(月) 08:09:59.68

40年近く前の本だしFORTRAN, PL/1が題材だから今の言語に合わない箇所もあるけど名著だと思う

プログラム書法第2版 / Brian W.カーニハン P.J.Plauger 著木村泉訳 | 共立出版
https://www.kyoritsu-pub.co.jp/bookdetail/9784320020856

**デフォルトの名無しさん** · 2021/03/01(月) 08:21:42.09

プログラミング作法の方が良いと思うよ

**デフォルトの名無しさん** · 2021/03/01(月) 11:23:05.55

中国行くと肛門PCR検査

**802** · 2021/03/01(月) 12:23:46.76

コミュ症の自覚がない>>803

**デフォルトの名無しさん** · 2021/03/01(月) 17:40:20.81

>>803
まーた、詭弁デメテルバカが発狂してるよ
一番勉強が足りてないお前が勉強してないっていうねw
頼むから、一生ROMってろ

**デフォルトの名無しさん** · 2021/03/01(月) 20:15:47.54

コードとはまた違うけど
javaのインターフェースとインプリメントはクソだなと思う
無駄にファイル数増えてクソうざい

**デフォルトの名無しさん** · 2021/03/01(月) 20:59:56.79

interfaceがクソってｗ
オブジェクト指向知らないのではｗ

**デフォルトの名無しさん** · 2021/03/01(月) 21:16:55.91

これだからJava脳はw
言語周りで幼稚な愚痴垂れ流してるやつのJava率の高さったらない

**デフォルトの名無しさん** · 2021/03/01(月) 22:39:30.52

>>811
GoFのデザインパターンも、ファウラーのリファクタリングも、エリックエバンスのDDDもみんなパターン・ランゲージ

それぞれのパターン・ランゲージに共通する要素は何なのか？
なぜパターンがソフトウェア開発に有用なのか？
この辺を学んで出直してくるといいんじゃね

**デフォルトの名無しさん** · 2021/03/01(月) 22:48:23.51

クソコードと言うのは単なるBad Practiceの一種であってアンチパターンとは違うもの

アンチパターンの意味を理解せずにアンチパターンの研究とかまあ無理よね

**デフォルトの名無しさん** · 2021/03/01(月) 23:16:44.33

>>818
abstractだけでいいって事では？

**デフォルトの名無しさん** · 2021/03/01(月) 23:43:38.69

C#やるとJavaのいろいろ足りてない部分はめちゃくちゃ実感する

**デフォルトの名無しさん** · 2021/03/02(火) 00:47:10.90

>>820
君が何を学んだかを教えてよ

**デフォルトの名無しさん** · 2021/03/02(火) 03:20:46.99

いちいち2chで教えなくていいから

**デフォルトの名無しさん** · 2021/03/02(火) 10:54:48.23

Anti-pattern
https://en.wikipedia.org/wiki/Anti-pattern

**デフォルトの名無しさん** · 2021/03/02(火) 11:43:32.18

>>818
そのインターフェース本当に必要？ってのが大半
他クラスとは何も関係無い孤立したクラスなのにインターフェース実装されてるの見たことある？
javaやってる感出すためだけにファイル数が2倍になるゴミ

**デフォルトの名無しさん** · 2021/03/02(火) 12:24:38.24

肛門コード

**デフォルトの名無しさん** · 2021/03/02(火) 12:31:08.45

>>827
ﾎﾟﾘﾓーﾌｨｽﾞﾑ

Storage storage

storage = new USBMemory()
or
storage = new SDCard()

以下、storageを使って読み出し

storage.read()

これができなくなるとか論外

**デフォルトの名無しさん** · 2021/03/02(火) 15:55:12.73

１メソッド１インタフェイスのペアで作れば解決するじゃないか！

interface Writer{
void write(Data data);
}
interface Reader{
Data read();
}
interface Eraser{
void erase();
}

abstract class Storage implements Writer, Reader, Eraser{
abstract void write(Data data);
abstract Data read();
abstract void erase();
}

**デフォルトの名無しさん** · 2021/03/02(火) 16:18:47.07

>>829
そうやって複数クラスで使う前提じゃなくて
自身にしか提供しないくせにインターフェースにするクソコード見ても同じこと言えんの？

その例で言うと
Interface USBMemoryと
Implements USBMemoryImplementsと
Interface SDCardと
Implements SDCardImplementsの4つファイルが作られるんだよ
もちろんStorageクラスなんて作られないからな、覚悟しとけ？

**デフォルトの名無しさん** · 2021/03/02(火) 17:22:18.70

>>831
それはどうかと思うけど、それを根拠に>>817みたいな言語機能を批判しちゃだめだろって話
Java脳とか言い出す人が湧いてるし

まぁ、そのコードは確かに問題だな

**デフォルトの名無しさん** · 2021/03/02(火) 17:45:25.68

脱線したが、無意味にインタフェースと実装部を分けるクソコードは俺も見たことがある
俺も初心者時代はやらかした事はあったな

無駄にコードが増えるだけでメリットが無いというね
初心者時代は、>>831のコードを書けば
class XXXImplement
から
class XXXImplement2
に乗り換える時が楽だなんて思ってたけど、実際はXXXImplement2なんて作らずにXXXImplementを直接編集してた

変な突っ掛かり方をして悪かったな

**デフォルトの名無しさん** · 2021/03/02(火) 17:49:55.29

仕様と実装をどこで切り離しておくかという設計選択の話なのでコードだけでは判断できない
>>831のようにインターフェースに対して実装が1種類しかなくてもそれが望ましい状況もあれば望ましくない状況もある

**デフォルトの名無しさん** · 2021/03/02(火) 17:59:46.35

>>834
望ましい状況って例えば何なんｗ
教えてプロjavaプログラマーさん

**デフォルトの名無しさん** · 2021/03/02(火) 18:06:26.23

インターフェース作ってもいいけど同じファイルに押し込んで欲しい
こんなくだらない内容でファイル数が倍は勘弁してほしい

**デフォルトの名無しさん** · 2021/03/02(火) 18:27:01.85

>>835
Storageの例と一緒だよ
共通した仕様を使いたいレイヤーと複数の実装を使いわけたいレイヤーがあって
それを分離することで結合度を下げときたい場合の選択肢の一つ

USBの例で言えばSDカードや他のストレージとは異なるUSB特有の仕様に依存したコードを書く必要がある場合に
実装が変更されても利用者側のプログラムを変更しなくてもいいようにしたかったり
複数の実装を実行時に切り替えて使えるようにしておきたい場合

面倒臭さと将来の柔軟性とのトレードオフ
切る場所が適切かどうかは要件次第なのでコードからは判断できない

**デフォルトの名無しさん** · 2021/03/02(火) 18:28:28.29

>>835
実装を変えられるってことさ
オープンクローズプリンシパルを守ろうとしたらインタフェイス切るしかない

**デフォルトの名無しさん** · 2021/03/02(火) 18:29:36.21

クラスは分けてなんぼ、理想を言えばメソッドごとにクラスを分けるべき

**デフォルトの名無しさん** · 2021/03/02(火) 18:36:50.14

メソッドごとにクラスを分ける理由は？

**デフォルトの名無しさん** · 2021/03/02(火) 18:47:13.75

同じ階層のものがたくさんあると
全体を把握しにくくなるんじゃないかなあ

**デフォルトの名無しさん** · 2021/03/02(火) 18:48:50.43

クラス毎にファイルを分ける理由は？

**デフォルトの名無しさん** · 2021/03/02(火) 18:48:57.53

Java脳のレスはインターフェースなくてもオブジェクト指向できるっつう話でしょ
引数に関数をとることでインターフェースの代替にできる時もあるしね

**デフォルトの名無しさん** · 2021/03/02(火) 18:59:10.26

>>842
関連するものの単位が同じだからでは？

**デフォルトの名無しさん** · 2021/03/02(火) 19:35:50.44

>>831
あの例だと
interface IStorageにread()などの必須メソッドを追加
class USBMemory implements IStorage
class SDCard implements IStorage
やろｗ
Storage抽象クラス又は親クラスで定義してoverrideでもいいけど
設計次第やな

**デフォルトの名無しさん** · 2021/03/02(火) 19:55:38.87

>>845
違うんだよなぁｗ

Interface USBMemory
class USBMemoryImplements implements USBMemory
Interface SDCard
class SDCardImplements implements SDCard

こんなのが爆誕してるというかほぼ全クラスこんなので統一されてる絶望感分かる？

**デフォルトの名無しさん** · 2021/03/02(火) 20:12:52.16

>>833
まあ仕様が悪いというより簡単に悪用される実態が問題なんだよね
そのパターンもあるあるやと思ってる
だけどもし仮に2に乗り換えたところで、何かあった時に戻れるようにって無印が残されて結局ファイル数は増える地獄なんだなぁw

**デフォルトの名無しさん** · 2021/03/03(水) 07:45:39.12

>>846
テストしやすくて最高じゃないですか

**デフォルトの名無しさん** · 2021/03/03(水) 10:51:02.42

ワクチン効かなくて人類オワタ

**デフォルトの名無しさん** · 2021/03/04(木) 00:08:07.08

親クラスが子クラスに依存する処理を持つコード例
https://stackoverflow.com/a/29907649/

Eric Lippertの書いてるコードがクソなのか？
それともその認識がクソなのか？

**デフォルトの名無しさん** · 2021/03/04(木) 09:40:02.79

ケース・バイ・ケース

**デフォルトの名無しさん** · 2021/03/04(木) 09:49:55.40

普通にクソってことでいいんじゃね？
クソだけど処理が小さく、まともにするには
過剰気味な設計が必要になるならそのままにするけど
良いとは思わないけど必要十分

**デフォルトの名無しさん** · 2021/03/05(金) 11:07:38.15

短絡的にクソコード認定したがるやつの脳みそがクソってことだよ
>>1のようなプログラマーは自分の見方がクソなのかもしれないと考えられるようにならない限り
いつまでたってもクソプログラマーのまま

**デフォルトの名無しさん** · 2021/03/05(金) 16:16:51.44

短絡的にクソプログラマー認定したがるやつの脳みそがクソってことだよ
>>853のようなプログラマーは自分の見方がクソなのかもしれないと考えられるようにならない限り
いつまでたってもクソコードのまま

**デフォルトの名無しさん** · 2021/03/05(金) 17:34:44.54

>>854
クソプログラマー認定も含めて自分の見方がクソかもしれないと考えてないようなら
そいつ自身がクソプログラマーの可能性はそれなりに高いだろうね

ただコードとプログラマーにはクソかどうか判断する基準に決定的違いがある
その決定的違いが分かってないから君はクソプログラマーなんだよ

**デフォルトの名無しさん** · 2021/03/05(金) 18:45:25.18

> クソコードを見た時に「あっ、これクソコードだ」って認識する根拠を挙げていきましょう。

スレ主は短絡的にクソコード認定をしていないと思うけど
むしろ、なぜクソコードを見てクソコードだと感じたのか哲学するスレだろ

クソプログラマーの定義とかスレ違いだし、どうでもいいわ

**デフォルトの名無しさん** · 2021/03/05(金) 20:45:43.09

>>856
スレ主さんwちーすっ

**デフォルトの名無しさん** · 2021/03/05(金) 23:14:44.63

>>855
底辺に何言っても無駄
他人からは学べないから

**デフォルトの名無しさん** · 2021/03/06(土) 09:14:58.43

根本的な原理が分かってない人が意外なぐらい多い
情報の多重化、DRY原則からの逸脱を誘発するものがとにかく駄目
突き詰めればダメなものは間接的でもそこにつながっているから被害を受けるのだと分かる
いろんなデザインパターンなんて結局は
いろんな状況でDRYを遵守する手練手管が99%だろう
重複実装も必要な時があるが
どんなものをどんな風に重複させるかで
状況はかなり異なるので短絡的な判断は禁物

1が言ってる一つ目の例は
もっと文脈をはっきりさせないと
何がクソなのか断定出来ないし
これで伝わると思ってるなら難アリ

**デフォルトの名無しさん** · 2021/03/06(土) 11:40:20.85

そもそもデザインパターンみたいなのは、こうすれば良いのでは？みたいな物だし
正直そういう所から入った層よりは、ある程度組めるようになってから見て納得出来た方が良いかと
つまりは最初に読むものでは無いと

**デフォルトの名無しさん** · 2021/03/06(土) 12:21:11.27

バックグラウンドとデザパタへの反応

複雑でも無く大きくも無いプログラムで遊んでた人
→自分のコードに対してデザパタの概念が大きい
→無意味にデザパタ導入してコード無意味に膨らます
→あるいはデザパタは無価値だと騒ぎ出す

ある程度複雑で大きいものを作ろうとして糞の山量産した人
→自分のコードに対してデザパタの概念が小さい
→デザパタ導入して部分的に見通し良く場面が見える
→必要に応じてデザパタを無言で使用

**デフォルトの名無しさん** · 2021/03/06(土) 12:47:09.63

オブジェクト指向を理解するにはデザインパターンを理解するのが近道
言語の基本文法を学んだ後すぐデザインパターンを学ぶと上達がはやい
パターン熱にかかるのも早い方がいい

**デフォルトの名無しさん** · 2021/03/06(土) 14:22:35.38

デザインパターンとオブジェクト指向は全く別。

**デフォルトの名無しさん** · 2021/03/06(土) 14:29:20.30

>>863
GoFのデザインパターンのことだぞ

**デフォルトの名無しさん** · 2021/03/06(土) 19:16:45.22

このスレすげえ面白えな
>>11からの流れは思わず引き込まれてしまった
下手なラノベよりよっぽど読めるわ

**デフォルトの名無しさん** · 2021/03/06(土) 20:23:40.52

そう言えば「名前がクソ」というクソパターンは
DRYとあまり関係ないな
あまりに基本過ぎて盲点だった
使ってる言葉や概念がそもそもおかしいのは
あまりに基本的な問題だが一番有りがちかもしれない
特に日本では戯言過ぎて英訳なんか不可能なぐらいの
曖昧模糊とした言葉を話す人が多いので…
コードを書くずっと前から間違ってることが多い

**デフォルトの名無しさん** · 2021/03/06(土) 20:54:37.19

コードがクソかどうかはコードを見ただけでは判断できない
一見名前がクソっぽくても本当にクソなのかどうかは分からない

**デフォルトの名無しさん** · 2021/03/06(土) 20:58:25.37

コードを見る以外の何をやって判断するんだ？
煮るのか焼くのか食べるのか？

**デフォルトの名無しさん** · 2021/03/06(土) 21:00:04.77

マウントスレ

**デフォルトの名無しさん** · 2021/03/06(土) 21:08:34.97

重複には悪性のものとそうでないものがある
明らかに悪性なものの見極めは簡単だかそうでないものは重複を除去すべきかどうかそう簡単には見極められない

accidental duplicationなのかactual duplicationか
重複を除去して抽象化することが望ましい状況なのかどうか

最低でもこの2点の判断が必要

**デフォルトの名無しさん** · 2021/03/07(日) 00:51:19.68

片方だけの変更が妥当なら良性、両方に変更を入れないとダメなら悪性、ぐらいでだいたい見分けられるんじゃね？

**デフォルトの名無しさん** · 2021/03/07(日) 01:45:46.06

例えばこれ
https://mevius.5ch.net/test/read.cgi/tech/1610137345/570

似たようなこと3回繰り返してるけど重複を除去すべきかどうか？
除去すべきならどうリファクタリングするか？

**デフォルトの名無しさん** · 2021/03/07(日) 18:09:07.95

具体的なコードが出てくると途端にヒヨるマウントスレ民

**デフォルトの名無しさん** · 2021/03/07(日) 19:18:29.31

ゴミみたいに細かい問題
知るかボケ

**デフォルトの名無しさん** · 2021/03/07(日) 20:58:32.09

>>872
３行３回程度ならそのままにするかな
breakしないとダメなので関数化しても条件判断が要るし
行数が増えるなら関数化する
回数が増えるなら関数をテーブルにしてforで回すかな

**デフォルトの名無しさん** · 2021/03/08(月) 08:06:44.01

それは要件次第って言えてしまうからなあ
関数作れない時もあるし、仮に1回でも要件で拡張の余地をとか言われたら関数にしなきゃだし
クソコードって分かってもそうしなきゃいけないときもある

**デフォルトの名無しさん** · 2021/03/08(月) 09:04:47.24

関数化すらしないやつがいるのはちょっと驚き

このケースで関数化する動機は繰り返し同じことをしてるからというより意図を明確にするため
行数やbreakの有無みたいな表面的な形よりも意味が重要なので
この書き方が組織内で標準化されてる等の特殊な理由がない限り関数化する

ループにするかどうかは処理順序やcssをコードに固定化すべき状況なのかどうかによる
これも形じゃなく意味
使い捨てじゃなく長期的にメンテするコードで
hrml要素の検索順や検索条件をコードに固定化したほうが望ましい状況は少ない

**デフォルトの名無しさん** · 2021/03/08(月) 09:23:46.71

でも関数って勝手に作ったらまずい現場もあるよね

**デフォルトの名無しさん** · 2021/03/08(月) 10:14:50.71

>>878
そういうのが特殊な理由

Pythonのような高レベル言語使ってるのに
ヘルパー関数を自由に作らせないのは控えめ言って異常だけどな

**デフォルトの名無しさん** · 2021/03/08(月) 11:50:19.86

全然控えめに言ってない件

**デフォルトの名無しさん** · 2021/03/08(月) 13:51:58.27

作らせないってのもあると思うな
MSDNはドキュメントあるけど
派遣社員ってドキュメント書かないじゃん
ドキュメントないメソッドなら作らんほうがマシになるときもある

**デフォルトの名無しさん** · 2021/03/08(月) 14:37:36.32

>>881
ドキュメントが必要だと思うなら書いてもらえばいいだけでは？
必要なドキュメントをきちんと書かせないのは依頼主の責任

**デフォルトの名無しさん** · 2021/03/08(月) 14:40:37.46

ドキュメント必須のレイヤーとドキュメントは任意で十分なレイヤーがあるから
全部同じ扱いをするのは非効率

コーディング規約と同様に指針を決めておくのが普通

**デフォルトの名無しさん** · 2021/03/08(月) 20:18:45.16

>>882
( ﾟдﾟ)あ、お金ないんでいいです

**デフォルトの名無しさん** · 2021/03/08(月) 20:20:53.39

ドキュメント間違えるし、イラネ

**デフォルトの名無しさん** · 2021/03/08(月) 21:04:02.65

>>884
金の使い方間違ってるw

**デフォルトの名無しさん** · 2021/03/09(火) 08:13:13.98

ドキュメントはちゃんとメンテしないとむしろ害を及ぼすよ

**デフォルトの名無しさん** · 2021/03/09(火) 09:22:23.90

メンテと言ってる時点でおかしいんだよね
本来はドキュメント変更してからコード直すべき
まあ不具合対策とかでいちいちドキュメントまで直してられっかって言うのはよくあるけど…

**デフォルトの名無しさん** · 2021/03/09(火) 09:35:33.69

ドキュメントを修正するのは不可能
すでにそれでOKがでてるんだから

**デフォルトの名無しさん** · 2021/03/09(火) 10:35:41.16

関数化すべき
→勝手に関数作れないもん
→関数作ったらドキュメントが必要になるもん
→作ったドキュメント維持できないもん

コードを評価する方法よりも職場やプログラマーを評価する方法を身につけた方が
圧倒的に効率よくクソを避けられるといういい見本だな

**デフォルトの名無しさん** · 2021/03/09(火) 11:18:33.87

このスレで得られた教訓

クソプログラマーが「こういうコードはクソ」と言った場合、十中八九その認識のほうがクソ

**デフォルトの名無しさん** · 2021/03/09(火) 11:48:27.03

>>891
>>1を見ただけで得られる教訓じゃん

**デフォルトの名無しさん** · 2021/03/09(火) 13:02:45.11

>>889
その理論でいくとコード修正するのも不可能では？

**デフォルトの名無しさん** · 2021/03/09(火) 15:30:47.03

>>891
それはわかる

**デフォルトの名無しさん** · 2021/03/09(火) 17:44:05.23

引き継ぎしてドキュメントを読む。
ソースをあまり読まずに修正する。
ドキュメントを直す。
システムが死ぬ。

**デフォルトの名無しさん** · 2021/03/09(火) 17:51:26.17

>>893
コードは最終工程なので動かなければバグとして修正される
ドキュメントは動かなくても、コードを直せば動くので
ドキュメントの修正をする必要はない

**デフォルトの名無しさん** · 2021/03/09(火) 18:19:39.56

>>888
コードがテストされるまで設計フェーズは終わらないので
その後のフィードバックで設計書の修正は当然
他のエンジニアリング分野で言う「製造」は
コンパイラとリンカーがやってしまうのであり
実装という実験によって設計の妥当性が証明されるまで
設計は終わらない

**デフォルトの名無しさん** · 2021/03/09(火) 20:20:33.28

ロジックをドキュメント化するのは無駄。
コード読んで分からないものに手を入れてはいけない。

**デフォルトの名無しさん** · 2021/03/09(火) 21:37:12.31

>>891
このスレを見返してみると「こういうコードはクソ」というレスが15～16あった
その中で「確かにそれはクソだな」と思ったのは1つだけ
それ以外は・・・

**デフォルトの名無しさん** · 2021/03/09(火) 22:03:20.61

竹内関数は糞か否か。

**デフォルトの名無しさん** · 2021/03/10(水) 02:31:32.15

どういう人が書いたのがわからんのが問題だと思う
バカが書いたとか間違ってるのが断定できればなんとかできるもん

**デフォルトの名無しさん** · 2021/03/10(水) 13:29:27.14

竹内関数は、WEB+DB vol.121 のRuby 3 特集で、
平行・並列処理、Ractor のベンチマークで使っている

マルチコア用の並列処理は、まだ数年は掛かりそう

**デフォルトの名無しさん** · 2021/03/10(水) 15:29:31.30

>>900
竹内関数は関数の仕様を定義したものなので
コードではなく仕様がクソかどうかという話になる
それはクソコードかどうかという話とは少し種類が違う

**デフォルトの名無しさん** · 2021/03/11(木) 15:58:20.83

まずは、使われない無駄なコードを減らして欲しい！

「無駄だらけのプログラムを効率化して、1万行→500行に。それを見た上司が激怒して『あいつは三流』と言いふらし始めました」（エンジニア・50代男性）
2021年1月26日 06:00
https://j-town.net/tokyo/column/allprefcolumn/317613.html?p=all

**デフォルトの名無しさん** · 2021/03/11(木) 16:00:27.63

とくぎ「パニパニハニー」を完全抹消コメント 1件

アイミョン
[KS108-054]
テーマ：キャラクター育成・強化2020/06/14 06:15
宝珠「パニパニハニーの技巧」とか、不要なオブジェクトは煩わしく誤動作の原因にもなります。
こうした旧バージョンのゴミは片づけて整理して、コマンド表示をわかりやすくしてほしいです。

https://i.imgur.com/IReXk4Q.png

**デフォルトの名無しさん** · 2021/03/11(木) 16:31:29.74

>>904
50代にもなってこんな所でしょうもない憂さ晴らししてるほうもたいがいやな

**デフォルトの名無しさん** · 2021/03/11(木) 16:59:27.28

>>904
条件分岐するたびに重複コードを書く初心者は必ずいる。サブルーチンの概念がないというよりは、変数の使い方がおかしいのが最大の理由だと思う。

**デフォルトの名無しさん** · 2021/03/11(木) 17:02:40.39

プログラムもドキュメントも常に作りかけかと思う物を作る50代を知っている。