オブジェクト指向ってクソかよPart5
レス数が950を超えています。1000を超えると書き込みができなくなります。
無理やりオブジェクト指向にしたから出てきた問題を解決して凄い凄い言ってるだけ。
単なるマッチポンプ。
カプセル化（英語：encapsulation）とは、オブジェクト指向を構成する概念の一つで、
オブジェクト内部のデータを隠蔽したり(データ隠蔽)、オブジェクトの振る舞いを隠蔽したり、
オブジェクトの実際の型を隠蔽したりすることをいう。
偏差値の低い学校向けの情報処理系教科書において「大変すばらしいものであり絶対に使うように」と大体的に宣伝された。
一方、カリフォルニア大学バークレー校の有識者を中心としたインターネットを作った人たちは「階層化の有害性」として
「絶対に使うな」としている。大雑把にいうと、その時は良くても、将来的な改修の際に隠蔽されたデータに
アクセスできないと解決できない問題が出てきて、結果的にデスマーチに陥るというのである。
オブジェクト指向の発案者であるアラン・ケイもコーディング規約（頭文字にアンダースコアを付けるなどの命名規則）で
縛る程度にすることを推奨しており、アラン・ケイが関わったオブジェクト指向プログラミング言語にはどれも「private」
という概念はない。
https://monobook.org/wiki/%E3%82%AB%E3%83%97%E3%82%BB%E3%83%AB%E5%8C%96
前前前前スレ
オブジェクト指向ってクソじゃね？
https://mevius.5ch.net/test/read.cgi/tech/1535085129/
前前前スレ
オブジェクト指向ってクソじゃねぇよ？ Part2
https://mevius.5ch.net/test/read.cgi/tech/1539872441/
前前スレ
オブジェクト指向ってクソじゃねぇかよPart3
https://mevius.5ch.net/test/read.cgi/tech/1542884872/
前スレ
オブジェクト指向ってクソじゃねぇかよPart4
https://mevius.5ch.net/test/read.cgi/tech/1556462315/ >>899
そしてデスマになる
だからデスマになる
オブジェクト指向を疑え
メリットのない技術を信用するな >>900
「オブジェクト指向」を何に置き換えても通じるなw 悪魔の証明ではないけれども
オブジェクト指向がダメな理由を指摘できる人は
オブジェクト指向を使いこなしてる人に限られるんじゃないかな
限界を知らないと否定することは難しい
ろくにコード書かないで本だけ読んでわかった気になって
オレオレオブジェクト指向で無駄に複雑なコードを書く人が
出てくるのはどうにかならんもんかなと思う
まあかくいう僕もその道をしっかり歩んで来たわけですが >>900
オブジェクト指向以外で
まともに作れたソフトなんてごく僅かだよ 有名なソフトをいくつか言えばいいのに
こういうレスしか返せないわけだ >>905
Windows APIはオブジェクト指向ではない。 >>906
APIがオブジェクト指向じゃないだけでしょ？
Windowsはオブジェクト指向で作られてる Win32はC言語でオブジェクト指向を実践する良い例だね >>907
え？それは嘘やろ
なんかそういう証拠あるん？ CreateWindowとか見るとオブジェクト指向やなってわかる
第一引数が、ClassNameだったりするし、引数にhInstanceってあるし
オブジェクト指向を踏まえてるとしか思えない ClassNameもhInstanceも事実だけど？ とりま「オブジェクト指向」の定義…というか
暗黙のうちに前提にされがちな歴史的経緯を共有しとかないと
お互いに欠けてる部分の揚げ足取りの応酬に終始して議論なんか無理
たとえば定番の↓に書かれてることなんかは全て常識…ってくらいじゃなきゃダメだろう
https://qr.ae/TWsn7X Windows SDKでの開発はオブジェクト指向というわけではない。 オブジェクト指向って、文字通り「指向」なのだから、
指向しているかしていないかなんて正確に判定できんだろ
人によって違う
例えばfopenはオブジェクト指向と言う人もいれば言わない人もいる
そこに正解はないよ 雑多な実装を雑多なまま扱わないでオブジェクトに落とし込んで扱うって事やろ？
雑多なまま扱った方が速くて解りやすければそうすればいい
それだけの話じゃないのか Boochの定義が広く一般に使われてるオブジェクト指向の定義
「OBJECT-ORIENTED ANALYSIS AND DESIGN」
Object-oriented programming is a method of implementation in which programs are organized
as cooperative collections of objects, each of which represents an instance of some class,
and whose classes are all members of a hierarchy of classes united via inheritance relationships. >>906
仕方がないですよ、あれは C からコールすることを前提に作られているのだから… >>918
プーチは後にSmalltalkを経験してメッセージング寄りに宗旨替えしている いい悪いは別にしてカプセル化、継承、ポリモーフィズムの3原則が広まったのもBoochの本によるもの
Boochの定義は「継承を使わずADTを使うだけではオブジェクト指向とは言わない」と明記してるところに価値がある
あとは英語版のWikipediaの定義は平易でいいと思う
(また英語で悪いが日本語版の記述は駄目なので)
Object-oriented programming (OOP) is a programming paradigm based on the concept of "objects",
which can contain data, in the form of fields (often known as attributes or properties),
and code, in the form of procedures (often known as methods).
A feature of objects is an object's procedures that can access and often modify the data fields of the object
with which they are associated (objects have a notion of "this" or "self").
In OOP, computer programs are designed by making them out of objects that interact with one another. >>923
継承は要らない子といわれて久しいと思うのですが…継承、要らないんじゃないですか？ >>923
プーチはもとも継承のないAdaを使っていたからね
ともあれ経験した言語で主張が変わる定義はダメだろ >>924
継承といっても
・型の継承
・実装の継承
・状態の継承
があってそれぞれ必要になることあるじゃんじゃあ残しましょうよ
むしろリスコフの置換原則がいらんのですよ 英語ばっかりだし
アメ公バカだから他人の商売邪魔しないじゃん（それが例え詐欺でも）
イスラム圏の方の意見とかも聞きたい >>925
オブジェクト指向プログラミングは、「オブジェクト」の概念に基づいたプログラミングパラダイムです。
オブジェクトにはデータを含めることができます。
オブジェクトにはコードを含めることができます。
オブジェクトの特徴は、オブジェクトのデータにアクセスするコードです。
OOPでは、プログラムは相互に作用するオブジェクトで設計されます。
言ってることはまとも 貧血ドメインがーとかクラス名は名詞がーとか
オブジェクトに知性をもたせるんだーとか俺のちんぽがーとか
そういう設計論が入り乱れてオブジェクト指向が闇鍋みたいになってる
オブジェクト指向自体はシンプルなんだよね >>927
やってみた結果ダメだった
経験から学んでいるんでいいんじゃないか? >>928
＞むしろリスコフの置換原則がいらんのですよ
驚きました、継承にするか移譲にするかの重要な判断基準そのものを否定するとは、私には暴挙にみえますね
＞継承といっても
＞・型の継承
haskell の型クラスを思い浮かべましたが、これにはリスコフが厳密に当てはまりますね、というかリスコフが当てはまらない型クラスなんて使えない…
＞・実装の継承
最近、簡単なお題で、移譲と実装継承の両方をやって比較してみましたが、継承による実装の継承では、基底クラスへのキャストという無様な記述が排除できないことがわかりました
これは継承より移譲の方が紛れが少ない、やっぱり継承は要らない子なのではないでしょうか？
https://mevius.5ch.net/test/read.cgi/tech/1573094136/943,960 https://ideone.com/y3ROXS
https://ideone.com/CeQlSq
＞・状態の継承
これはコードで記述するとなればどのようになりますか？ >>902
これだわ。
staticおじさんが叩かれた理由もそれに関係しそう。 否定する理由にオブジェクト指向でも避けられている
実装の継承、状態の継承をあげて叩きまくる記事を見ると
使いこなしているのかなと何とも言えない気持ちになる >>934
君は継承は要らないって立場なのだから継承か移譲かの判断をリスコフの置換原則で行っているとするならば
継承が要らないものならばその判断基準であるリスコフの置換原則も要らなくなると思うのだけれども
Javaで話をするけど
型の継承はインターフェースの実装が例
AbstractListがListインターフェースを実装してるような
実装の継承はArrayListがAbstractListを継承してるのが例
indexOfなどのコードを引き継いでる
状態の継承はHashMapがAbstractMapを継承してるのが例
keySetやvaluesといったデータを引き継いでる
継承の目的は型の継承を使うことでそれを使用するオブジェクトに
影響を与えないようにすることと、実装の継承を使って差分プログラミングで
コードを共通化して管理しやすくすることの2つに大別されると思ってて
リスコフの置換原則は型の継承では必要だろうけど差分プログラミングでは
必要ないと思うんだよね 僕はBtoBのWebアプリをいくつか作った経験がある
開発の規模は20人程度
プロプラなフレームワークを使って誰が担当してもある程度の
品質は担保されるようにはなってはいるのだけれども
プロジェクト固有のデータや共通の処理があって
そのために抽象クラスを作って各担当者に継承してもらうってことやった
修正があってもコードは集約されてるから修正しやすかった
リスコフの置換原則は意識してなくても継承が役に立つことは
あるんであまり原則とか気にするものじゃないと思った
状況に応じて良い悪いは変わってくるので
継承は良いものだ悪いものだって考え方ではなくて
どういう目的で継承を使うかってことを考える方が大事だと思う >>933
プーチ個人の成長としてはそれでいいけど
議論のベースにする定義には使えないだろうって話だよ
その後「結果ダメだった」って刷新されているんだから
（刷新後のものを使うならともかく） >>928
チンポは随意筋であり不随意筋であり、これはオブジェクトの多重継承だ。 >>941
オブジェクト指向は俺の股間に付いている！ >>934
素数のプログラム例について
Javaだとsuperというキーワードが使えますよ
https://paiza.io/projects/_vWOZhOW1Qsbn1-DTxVqfQ
この例だと僕も委譲を使いたいです
委譲なら間違って状態を破壊する恐れがありませんから
多態性が必要ならSieveのインターフェースを切ればいいだけですからね >>943
繋がっているけれども独立している、これがオブジェクト指向。 >>944
ありがとうございます。java コードをみました！C++ の知識だけでも十分に理解できます
C++ にはない super は便利ですね、ただ super は一行目／最初にしか書けないのは残念なところです
static class SieveExt extends Sieve {
private static int size(int n) {
for (var i = n; i > 0; i--) {
var r = index(i);
if (r != 0) {
return r;
略
これは、もとの C++ 関連スレへの質問と関連があります。
このプライベートメソッドは、私はメソッドとして書きたくない、という意向があり、C++11 では私はメソッドを立てずラムダ式で書いておきました
なぜならば、この部分は一箇所(SieveExtコンストラクタ）からしかコールされないから、その一箇所にまとめて書くべきだと思っているのです >>946
なるほど、Javaだとどうしようもないから
コンストラクタの代わりにstaticのファクトリメソッドを作るかな チンポは俺の体のコンポーネントであり、かつ独立している！ カプセル化というのはオブジェクトの独立性であり、チンポが勃起してシコシコするのは本人の意思ではない！ >>943
そう思ってるのはお前くらいだから。
つーか、お前、普段何を開発しているんだ？ >>952
システム開発経験なぞ無くても、オブジェクト指向は俺の股間に付いているんだよ！ >>952
お前こそ>>942のちんぽを有効活用してるのかよ なんでも動的にやることが偉いと思う馬鹿が増えただけ。 >>957
オシッコは本体と繋がっている静的メソッド、勃起は独立した自己完結型の動的メソッド。 膀胱の中にオシッコが溜まって尿意がする、それはグローバル変数である。 オブジェクト指向の無いシステム開発は、勃起しないチンポと同じだ！ <オブジェクト指向>
宇宙間に存在する千万無量の物体がけっして各個別々に独立自存するものではなくて、
たがいに相依り相待ってひとつの組織体をなしていることを表示するものである。 チンポは自らの意思で勃起するが、勃起することをそのまま関数オブジェクトとして扱うこともできる。 「チンポがシコシコする」とは、釈尊によって見出された普遍の道理なのである！ 半年前位からPythonをネットで勉強し始めたんだけど（PG未経験）
最初は手続き型でコード書いて、途中からオブジェクト指向もやってみましょう 的な流れ
今迄は 短く簡潔に を意識してきたつもりなのに・・・何でこうなるん？抵抗がある
少し間を間置いてやって、再度やってみたけどイマイチ理解しづらい
途中から切り替えるんじゃなく、最初からオブジェクト指向で習い始めれば良いんじゃネ PythonやRubyのライブラリは強力だからね
オブジェクト指向じゃなくても大体のことはシンプルに解決可能 >>965
プログラミングのスタイルっていうのはいくつもあるんだよ
場合によって違うし、どれでも使える場合もあるし、どれかが最適な場合もある
必ずしもオブジェクト指向が適切なわけではない。ただしオブジェクト指向が適切な場合が多い
だから複数のスタイルを学ぶことには意味がある。
なんで最初手続き型からやってオブジェクト指向なのかというと
オブジェクト指向の方が覚えることが多いから。いろんな機能が増え
歴史的にもオブジェクト指向の方があとで登場した
30年ぐらい前はほぼ手続き型といっていいし、そこから新しく登場した
オブジェクト指向を導入するという流れで、オブジェクト指向を後で勉強するという流れを
今までの人はずっとやってきた。それを受け継いでいるから、
みんな手続き型をやってオブジェクト指向をやるのが当たり前になってる。
オブジェクト指向でも短く簡潔に書くとういことは変わらない。
君はまだコードの行数でしか簡潔かどうかを判断できないのだろう
短く簡潔に書くべきものは動く処理。テストする対象。オブジェクト指向で増えてるのは
処理ではなく定義。関数定義やクラス定義など。これらは動かない。
そういう定義があることで人間が理解しやくなり大きく複雑な構造を持ったシステムが作れる。
だからオブジェクト指向で短く簡潔だったものが複雑になったわけではない。
新たに構造を表す概念が増えた。概念が増えるというこは勉強するものも増えるので
オブジェクト指向の学習があとになるのは必然 オブジェクト指向は大きく複雑なシステムを完結にするものだから
学習最初レベルの短いコードではオブジェクト指向が理解できないのはよくある話。
一人で作ってるシステムを作るのではなくその何倍も大きな物を
複数の人が協力して作ると考えれば、少しでは負担を彫らすために
あったら良い機能ばかりであることに気づくだろう >概念が増えるというこは勉強するものも増えるのでオブジェクト指向の学習があとになるのは必然
>学習最初レベルの短いコードではオブジェクト指向が理解できないのはよくある話
誰でも通る道なんですね
先に進むと見えるものがあるかも知れないので もう少し頑張ってみます ありがとうございました >>969
ttps://i.imgur.com/Y1JgMDU.gif たとえばGUIのクラスライブラリって
継承によってうまく表現されてる例じゃないかな？
おまえらどうおもう？
java.lang.Object
java.awt.Component
java.awt.Container
javax.swing.JComponent
javax.swing.AbstractButton
javax.swing.JButton
継承関係の無い状態にくらべて
ある場合の上記のような構造が
コード全体を理解する助けになってる気がする イベントリスナを持つことと、
他のGUIを複数載っけてリスナ集約することを上手に設計してると思うよ >>971
チェックボックスとか
テキストボックスとかってどこに所属するの？ 継承関係の階層構造って、整理した気になるだけで実態把握には使えない
元のクラスを一部改変した派生クラスを楽に作りたい、というのは分かるんだけど、それ以上の意味（is-a関係とか）を提示しちゃうのは良いの？ってなる
例えば>>971で言えば、JButton <: Containerだけど、本当にそれでいいの？ってなるし、
ボタンの特性だと万人が想像する「クリックしたときに何か起こせる」って、他のComponentでもできる
でよく見るとActionを介して制御できるってあるけど、Actionに関する機能は>>971の継承関係とほとんど関係が無い
他にActionが使えるコンポーネント、どこにどれだけあるかすぐ分かる？俺には分からない
「継承でこんなにシンプルに表現できる！OOP凄い！」って思ってる頭で、同時に「奥深い！こんなこともできるなんて！」と思ってない？
俺はそんな分裂症気味の精神を持ちたくないし、traitを知ってしまったのでいよいよ利点が分からない >>974
意味がわからんっていうか、お前が分かってないだけじゃないか
> 元のクラスを一部改変した派生クラスを楽に作りたい、というのは分かるんだけど、
派生クラスという用語を使うのはやめろ。それは差分プログラミングだ。
そこでお前が言うべき言葉は「元のコードを一部改変した差分プログラミングをしたい」だ
派生クラスは差分プログラミングに含まれるが、派生クラス＝差分プログラミングではない
> それ以上の意味（is-a関係とか）を提示しちゃうのは良いの？ってなる
差分プログラミングをした結果is-a関係ができてしまう、のは間違いに決まってるだろ
派生クラスを作った結果、is-a関係になるのではない。因果関係が逆になってる。
is-a関係を提示したいときに派生クラスを作るんだよ
オブジェクト指向というのは「この何を提示したいか？」を（より多く）コードの中に記述することができる
お前はまず動きそうなコードを書いてしまってる。
何をしたいのか（設計）をコードで記述するというレベルに達していない。 >>974
> 例えば>>971で言えば、JButton <: Containerだけど、本当にそれでいいの？ってなるし、
お前が設計を読み取れてないだけ
オブジェクト指向は現実を表現するためのものじゃない
それを見れば（現実ではなく）「Javaのswingでは」JButtonはContainerの一種として
作られていることが、設計から読み取れる。
例えばHTMLでは、<input type="button">はコンテナの一種ではないが
<button>その他</button>はコンテナの一種だろう
同じボタンでもコンテナタイプと非コンテナタイプが考えられる
お前は現実世界のボタンはどうなんだろうか？って考えてそれでいいの？って思ってるんだろうが
オブジェクト指向は現実世界を表現するためのものじゃない
継承関係から「JButtonはContainerの一種として設計されてる」という事実が読み取れる。
これが重要なこと 念のために言っておくが
「ボタンはコンテナの一種として設計するのは正しいのだろうか？」という話はしてない
「継承関係から設計が読み取れる」という話をしてる
「継承関係から設計が読み取れる話」と
「継承関係から設計を読み取った結果、この設計は正しいのだろうか？」というのは全く別の話
設計が間違ってるなら設計が間違ってるってだけの話だろ。
それは継承関係を用いた「設計の一例」の話であって
継承関係で設計が表現できるという事実とは何の関係もない
そもそも継承関係で設計が表現からこそ、その継承関係だけを見て設計の正しさを議論ができわけで
継承関係をコードとしてかけるというのは、素晴らしいことの証明になってるだろ 長方形正方形問題から察するに、実装の継承は問題点が多い。 >>976
>お前が設計を読み取れてないだけ
>オブジェクト指向は現実を表現するためのものじゃない
夢の世界？ 「現実を表現するためのもの」である
と主張して憚らない人たまにいるよね
マジなんかネタなんか最後までわからんけど オブジェクト指向ではカモノハシを表現できないとかなｗ
カモノハシを表現するための道具じゃないからｗｗｗ 僕オブジェクト演算子を作った人だけど
恩師に褒められた部分は
開発環境でのプロパティのアシストが便利で楽
だけ 恩師って無名の素人やろ？ｗ
あ、大学で有名とかそういうのはいいから
ソフトウェア業界で名前が知られてるかどうか 恩師はC89の開発者の一人
名前を知られているかはわからない 結局必要だったのはネームスペースの閉じ込めだけだったのに
余計なことしてくれたという感想しかない。 正しさを人が議論しなくちゃいけない、それが継承の限界だよ。俺はフツーに数学とコンピュータの力を借りる。 >>976
Sunが作ったGUIフレームワークという事前情報があるから
安心してクラス階層から設計を読み取れるんだと思う
例えば俺（または経験不明の第三者）がオレオレGUIフレームワークを作って同じクラス階層を提示したとすると、
継承の使い方が間違っていてそのフレームワークが実現したいことは
そのクラス階層で正しいのかという疑念がどうしても拭えないだろ？
考慮されたクラス階層ですという保証がない限り、
クラス階層から設計を読み取っても疑念が残る、
または、バグに繋がるケースがある
>>971 はそういうことを言いたいんだと思う
単純な例だとC#のApplicationExceptionとか、
昔はユーザが作る例外はApplicationExceptionを継承するべき、
現在はMSのライブラリチームの人がクラス階層間違って使ったせいで継承するべきでないという方針転換してるが
クラス階層は互換性からそのままになってる >>987
> 例えば俺（または経験不明の第三者）がオレオレGUIフレームワークを作って同じクラス階層を提示したとすると、
> 継承の使い方が間違っていてそのフレームワークが実現したいことは
> そのクラス階層で正しいのかという疑念がどうしても拭えないだろ？
継承に限らないよね？
お前が書いたコードがクソで、そのやり方ではうまく動かないかもしれないし
メンテナンス性が悪いかもしれない
そして>>977の話に戻す
> 念のために言っておくが
>
> 「ボタンはコンテナの一種として設計するのは正しいのだろうか？」という話はしてない
> 「継承関係から設計が読み取れる」という話をしてる
お前のクラス階層が正しいかどうかの話はしてない
「継承関係から設計が読み取れる」という話をしてる 何を読み取れるのって話をしてるんじゃないの？
YはXのサブクラスとしたとき、「YはXの状態と振る舞い全てを持っている」以上の意図は込められないのに、「いやY is a Xだ！」って余計な意図を撒き散らしてる
まずどういう視点でis-a関係なのかの説明が必要だし、別の視点で見るときにそのis-a関係は無価値になる
提示できているかどうかが疑われる方法を使って、提示している知識の価値が低い。そんな不便な道具を使っちゃ駄目だ > YはXのサブクラスとしたとき、「YはXの状態と振る舞い全てを持っている」以上の意図は込められないのに、「いやY is a Xだ！」って余計な意図を撒き散らしてる
だから因果関係が逆。
自分でサブクラス作ったことないでしょ？
他人が作ったサブクラス見て、あーだこーだいってるだけでしょ？
はじめに世界がありました。はじめにサブクラスがありました。じゃないんだからさ
最初はなにもない。なにもない所にサブクラスを作り出す。
Y is a Xとしたいと思ったときに、YをXのサブクラスにするんだよ
そうすると状態と振る舞いもついてくる
なんで、とりあえずサブクラスでなんて考えるのかな？
理由なしにサブクラスになんかしないだろ > まずどういう視点でis-a関係なのか
そんなもん、（自作、既存問わず）フレームワークやライブラリがあって
そのフレームワークやライブラリはクラスを親クラスとして扱う。
それをサブクラスで拡張やカスタマイズできる。
そういうことをしたいときにサブクラスにするに決まってるじゃん
それ以外に理由なんかあんの？理由なんてたった一つなのにそれを説明しろだなんて
お前がその一つの理由を知らないだけとしか思えんが オブジェクト指向とか便利かもしれないけど
普通にクラスのデザインが不味いとオブジェクト指向とか関係なく放棄されるから
オブジェクト指向であっても普通にクソコードは生まれる
免罪符的な何かを期待してもむりじゃね？ >>992
当たり前だろ。なんでできないやつ、素人用の道具だと思ってるんだ？ OOPの概念 ←難しくない
クラス設計 ←難しい
クラス設計が難しい事を自覚すること ←不可能レベルで難しい
クラス設計が難しい事を自覚することなくOOPを批判 ←ありがち 逆じゃねえよ作らねえと分からないのがソフトウェア開発だよ
最初に考えた設計じゃすぐに駄目になるから身軽じゃないといけないし、想定外の使われ方をするから防衛的にしなきゃいけないんだ
そんな世界で、後から変更しづらいことが作る前から分かってる道具を使う理由は何だ？
クラス階層は時間で腐る。最初のロクでもない思いつきがずっと残る。作った奴の意図がコードに込められないから用途も目的もブレる。
継承の階層構造から読み取れる意図なんて幻想だファンタジーだフィクションだ。嘘じゃねえよどれだけ世の中にそびえ立つクソがあるか知ってるだろ？ クラス使っていても特に変更しづらいことはないし何いってんだこいつ？ >>995
よく入門書に書いてあったのは
設計書をプログラムに反映するためのオブジェクト指向のハズだったよな？ >>995みたいなのって、設計もせずにいきなりコード書くんでしょ？
だから、コードを共通化したい＝サブクラスじゃぁっていきなりサブクラスが出てくる。
そしてYはXの状態と振る舞いを全部持ってるだけだ、Y is a Xという意図はない！
あとから意図を聞かれてごまかしてる。
最初に設計（意図）をして、それがY is a Xであるときにサブクラスにする
コードを共通化したいときにサブクラスにするのではない 設計もせずにいきなりコード書くから作らないとわからない
すぐにだめになる。全部書き直し、それはクラスだからみたいな意味不明な結論を持ってくる
最初の設計が破綻してるだけ。そもそも設計してないんだろうがな
最初のロクでもない思いつきでコードを書いてるからそうなる
自分が意図を込めてないから、用途も目的もブレる。
そして相手も意図を込めてないと思ってる。
何も意図を込めてないコードから、意図なんて読み取れるわけがない。
意図が読み取れないのは、書いたやつがクソだけ
世の中にあるクソコード一つが>>995が書いたコード レス数が950を超えています。1000を超えると書き込みができなくなります。
