■

いい加減みなれてきたﾊﾟﾀｰﾝがある。
まとめる意思が見られるソースか、
テキトーに作られたソースか、
いじくりまわされた挙句に腐ったソースか。
小奇麗なソースに出会ったことなんざ３回あればよいほうだ。

今回もうだうだとやってる同じシステム。
その中で、機能が違えば作成者も違う。
ﾃﾞｻﾞｲﾝもｿｰｽ構成もみんな違う。

かつて自分もやってはいたけれども
捨てた選択肢。
そんなのがばんばんみられる。

(´-`).｡oO(誰しも通る道と思えばハラもたたず・・・・・・)

なんてことはない。
決して無い。
精神衛生上はよろしくないけれども、
腐れソース撲滅という果てしない目標を忘れないためにはそれくらい我慢しとこうと思う。

[傾向と対策]

既存の仕組みがあって、それに追加修正する場合にとれる選択肢ってのは決まっている。
　(1)全部塗り替える
　(2)一部分をとってつける
二つしかない。

中途半端に修正を繰り返すことは目に見えて修正結果を確認できるメリットはあれども、
ソース解析に必要となる時間を大幅に増やすデメリットがある。
解析が不十分なら修正行為が新たなる不正になる危険もある。
つまりロクなことにはならんってこった。

時間が許す限り。
ソースの影響範囲が知れている限り。
(1)を推奨したいのだが、
現実問題そんなことばかりでもない。
一部分の修正に対することのほうが多いだろう。

そんなときに、なんとなく既存のソースに沿った形式で修正することに慣れてはいないだろうか。
追加修正の機能によっては、クラスを足してみたり、メソッドをたしてみたり、で対処できないだろうか。

なんて書いてはみたものの、実体験を伴わない人々がみてもなんのこっちゃ想像もつかないのではあるまいかと想像してしまう。
経験者は自身の経験の相似により、なんとなく言葉が通じてしまうのではあるまいかとも想像してしまう。

日本語だけで対象範囲、ソース規模、元ネタの拙さ汚さなどの前提条件を整えるのはとっても難儀だな。
かといってソースをさらせばこれまたBlogで表示するには膨大な量になるうえに
著作権問題までからんでくる。
ってなことで、プログラマたちのぐちっぽくまとまってしまうことはある意味必然なのではあるまいかとも想像してしまう。

そんな垂れ流しのような言葉を誰が聞きたいか。
垂れ流しは情報収集整理整頓がめんどくさいので丸ごと破棄されることがしばしば。

今回の主張。

ごちゃごちゃと考えることはあるけれど。
誰かの作ったソースを見るたびに思うこと。
おいらが頑なに守り続ける一つのこと。

(,,ﾟДﾟ)＜せめてソース構成には一貫性をもたせろや。

これに尽きる。