【IT】本当にあった怖いプログラム（クソコード事例集）
■ このスレッドは過去ログ倉庫に格納されています
命名規則に関連するクソコード
クラス名、メソッド名、変数名などのネーミングを誤るとクソコード認定されてしまいます。会社やプロジェクトごとに多少のルールの違いはあるにせよ、どこに行っても漏れなくクソコード認定されてしまうネーミングパターンのご紹介です。
ネーミングが「記号＋番号」
クラス名や変数名はわかりやすい名称にしましょう。ネーミングを見て内容を推測できるようになっていることが重要です。「記号＋番号」ではそれを見るだけでは何のプログラムであるかを推測することは不可能です。
ネーミングに日本語、英語、ローマ字が混在
プロジェクトによってクラス名や変数名のネーミングルールは異なりますので、何がダメだというわけではありませんが、自由すぎるネーミングを行うのはやめましょう。きちんとプロジェクトでルールを統一することは重要です。
またにクラス名や変数名に日本語を使用することは言語仕様上可能とはなっておりますが、アルファベットを使うことが慣習となっていることと、日本語だとIDEの補完機能がうまく機能しないことがあって非効率化の原因となりますので、避けた方が無難です。
ネーミングにスペルミスがある
ネーミングでスペルミスがあると、後でソースコードから文字列で該当箇所を検索する時に検索にヒットせず、改修漏れの原因にもなります。正しいスペルと間違ったスペルが混在していたりするともう最悪です。スペルミスのないように気をつけましょう。
ネーミングに個人名が使われている
ネーミングはプログラムの中身がわかるような名前にするという観点からも、プログラムの中に自分の名前にすることは適切ではないのでやめましょう。
またソースコードレビューの時に思いがけず恥ずかしい思いをすることになるかもしれません。私は新人の時に「yonemura.sh」という名前で自分用に作ったシェルが他社に買い取られることになってしまい、他の会社のエンジニア２０名くらいの前で「よねむらシェルとは・・・」と説明会で大きな声で読み上げるはめになって大変恥ずかしい思いをしたことがあります。
個人で使うプログラムでもプログラムの中身を表した無難なネーミングにしておくことを強くお勧めします。
ネーミングに番号やアルファベットの連番が使われている
クラスや変数のネーミングに、１からの連番やaからの連番を使うと、クラスや変数の中身を推測することが不可能になってしまうのでやめましょう。こういうことをすると後でそのプログラムをメンテナンスする人に、一々プログラムの処理を細かく解析することを強いることとなり、「このクソコード書いたやつまじで氏ね」と言われてしまいますのでやめましょう。
可読性に関連するクソコード
プログラムは後でメンテナンスするためにも、読みやすく書くことが非常に重要です。処理の内容だけ見ると読みやすくても読みにくくても実行される内容は同じかもしれませんが、読みやすいソースコードは改修の工数を下げますし、バグが混入するリスクも下げてくれます。
ネストが異様に深い
ソースコードの中にネストが何重にもなっている箇所があると可読性を下げてしまいます。ネストを何重まで許可するかはプロジェクトによって異なりますが、個人的には３重か４重くらいまでにおさまるようにコーディングするよう心がけていました。
これとセットで「１行の文字数は８０文字まで」みたいなコーディング規約があるとさらにカオスな感じになってきます。ネストが１０階層＋１行８０文字までとか、考えただけでも嫌になりますね。
インデントがずれている
今どきエディタが良い感じにインデントしてくれるのに、まさかインデントがずれているソースコードなんて存在しないと信じたいところですが、昔作られたソースコードだとそういう化石みたいなクソコードにお目にかかることはあるようですね。
カッコの閉じ位置のインデントがズレていたりすると、著しく可読性を下げますし、コードの解析を誤るリスクも増えてしまいます。こういうことをすると漏れなくクソコード認定されてしまうでしょう。
１つのメソッドが異様に長い
たまに１つのメソッドが異様に長いソースコードにお目にかかることがあります。私の個人的な感想だと某国にオフショア開発に出されてウミガメのように日本に帰ってきたソースコードにそういうメソッド分割の概念が消失してしまったかのようなソースコードが多いように思います。
１つのメソッドの長さが数千行にも及ぶような男前なソースコードにバグが混入してしまい、解析及び改修をしなければならなくなった時には絶望するしかありませんね。
以下ソース
https://axia.co.jp/2018-04-27 状態と振る舞いが全カイチンになっていて、外のクラスから破壊的操作が呼び出し可能なクラスを知識不足で作成する人、分かっているのに事無かれ追随で作成する人。 AからZの1文字の変数名しか使えなかったあのころが懐かしい C#で戻り値を使わず全部refで処理してる
理解に苦しむ >>104
cでポインター慣れしてる人の書きがちなコード
若しくはリソース少ない中での最適化コード（リソース少ないとこでC#はそもそも使わんか） while((*ptr=*ptr=='^'?' ':*++ptr)!='\0');
さて何が起こるでしょう DRY（Dont Repeat Yet)ってRailsの概念のひとつで、
個人的にはこんなの当たり前にやるもんだと思ってたけど
モノシリックなプログラムが好きな人間がいるな。
あれなんなの？
あと、MVCフレームワークで、コントローラが異様に長いプログラムって
結構巷にあふれている気がする C言語だが…
その1
20個グローバル変数に代入しまくりの4000行の関数。
ただし、そのグローバル変数は他関数から全く参照されない。
呼び出し元で戻り値を参照してるが、その値は常に0。
完全に冗長なゴミ。
その2
実装意図がわからない、謎の値補正関数。
その処理を通ると使用と微妙に異なる値を出力する。
50行程度だがロジックの意図がわからない。
コメントを信じるなら、実装者は他部署の管理職。
試しにコメントアウトしたところ過去製品で原因不明といわれていた4個の不具合が解消。
ゴミというか悪性腫瘍。 大抵オブジェクト指向設計を正しく理解できていない上に、
何か1つ, 2つの言語しか習得していない(習得する気がない)人だと、
品質の低いコードを書く、というより品質が低いということを理解していない C言語の開発者が「create」ってスペルミスしたのがそのまま使われてる あと、BASIC回顧するのもいいし、C/C++の低レベルプログラミングが好きなのもいいけど
いい加減現代プログラミングは関数型言語とオブジェクト指向の理解は必須だということ理解してください。
この二つプログラミングパラダイムは1980年に出てきた概念で
最初と今とで違う部分もあるけど、だいたい変わっていなくて
これを理解している人は50代でも最新の言語にもついていけるのだが・・・
そこらへん勉強していなくてCOBOL一本やりとかいう人間が最悪 ソフトウェア開発には規律と統制が必要だ。
決められたルールを全員で守る必要がある。
プロジェクトに一人でも頭の悪い奴や無責任なやつがいたら破綻する。
だから大半のプロジェクトはグダグダなのだ。
ソフトウェア開発に天才はいらない。それはむしろ有害。
必要なのは一握りのそれなりに優秀なやつらと、大勢の真面目な歯車。
天才は地味な仕事を真面目にコツコツやれないだろうからね。 俺なんぞ処理時間制限対策の為に
割り込みルーチン内でスタック戻して割り込みフラグ戻して
メインルーチンに飛ばすソフトを書いたよ
大体5.1MHz動作の4bitマシンにCRC計算なんぞさせんなよと思ったよ >>88 ＞ネーミングが「記号＋番号」
防で出会った。完全に一対一で対応するフローチャートがある。
>>100
変数名の文字数が少ない方が早いとかもあった気がする
>>108
＞20個グローバル変数に代入しまくりの4000行の関数。
＞ただし、そのグローバル変数は他関数から全く参照されない。
デバッグ用じゃね？常に同じメモリ領域を監視すりゃいいわけだし。ロジアナでバス監視も出来る。
＞呼び出し元で戻り値を参照してるが、その値は常に0。
正常は0、エラーは負。正常終了しか実装してないから0返してるんだろ。 >>107
流石に最近はそういうのは見ない気が理由は主に２つですね。
１つは多くのMVCフレームワークではMの部分に自由度を持たせてありまして、
作るものや利用するライブラリに合わせて自分たちで設計してねとなっているからでしょうね(;^_^A・・・
そういう状況でMの責務が分かってない人たちが作るとロジックをあれこれCに実装しちゃうわけです。
Mを実装しなくてもプログラム自体は動きますからね。Cからデータアクセスとか余裕な感じで(;^_^A・・・
後からその機能をAPI化しようとしても難しくなったり。
２つめは１とも関連するのですが新規開発時にスモールスタートの低予算でとにかく動くものを作らねばならなかったとかです(;^_^A
予算的にCIなど考慮したことのないプログラマーしか呼べない状況で開発されたとかです。
チャチャっと最低限の設計だけでもすれば良いものを元受けがスキル不足でその作業が必要な意味を理解できなかったり。 ＞ネーミングに個人名が使われている
一番使われている個人名は後藤、異論は認めない。 typescriptが流行る前のjavascriptはひどかったなぁ
他人が書いたコードを修正・改造するのが苦痛でしかなかった >>66
副作用のあるgetter がグローバル変数を触るとこうなる
// a と b は別のインスタンスとする
// どちらも count プロパティをもっている
x = a.count
y = b.count
と
y = b.count
x = a.count
で、x,y の値が変わる可能性が生じることになる。挙動が全く予測できない。 >>115
組み込みでI/Oポート設定とかがハード設計者しかわけわかんないときにはたまにある
そして私もハード設計者だ、スマヌ(だって低予算なんだもん、むりくり入れないとはいらないんだよ！) >>107
Don't Repeat Yourself
でしょ
たぶんしってるけどふと間違ったのだと思うけど >>81
確かにそうだな
俺もキャッシュでよくやる
っていうかキャッシュ以外はまずやらんかな
でもGetterでグローバル変数ってのが余りにも突拍子ないからようわからんです
色々説明してる人もいるけど、そんな変態コード >>82
それもrouteの読み方はルートじゃなくてラウトってオチ 昔々べーしっくんとかいう雑誌だったかで、1行256文字に詰め込むプログラムってのが
あったな 【朗報】”この銘柄”が3日後に爆上げ↑です。
しばらく下落トレンドでジリ貧だった仮想通貨の市場が遂に上昇方向に来ましたね。
このタイミングでビックニュースです。どの通貨銘柄がいつ爆上げするのか？全部教えてくれる厳選情報配信サービスが今だけ無料にてリリースされています。https://tknk.io/7EHM
北米やアメリカの大口投資家や機関投資家、ファンドとのコネクションを有し海外の凄腕専属アナリストが在中する仮想通貨分析機関が行なっている
有料情報配信サービスなのですが
(しかも3000USD/月額で結構高額)
日本グランドオープンを記念して今だけ何と
「月額3000USD→０円」
という形で受けることができます。
https://tknk.io/7EHM
サービスを運営しているのは「THE DAWN」という組織。海外の仮想通貨市場においては知る人ぞ知る優良情報配信機関です。(厳選された情報だけ届きます)ちなみにですが・・・
今現在リアルタイムで「とある銘柄に関する情報」がアナウンスされています。非常に希少価値が高く
資産激増に繋がる情報ですが緊急度が高いので希望される方はお早めに下記よりどうぞ。
https://tknk.io/7EHM
【爆上げコイン配信システム ACT-S】も完全無料プレゼントキャンペーン中！！https://tknk.io/IdHB
※今なら仮想通貨投資で失敗しやすい落とし穴のチェックリストもプレゼント！
【仮想通貨自動収集ソフトも今だけ無料！】
https://tknk.io/l3iQ >>38
一緒に働きたくないのはA
コードを直す方の身にもなってくれ クライアントとしては、安くて、ちゃんと動いて、納期守ってくれれば
コードが汚かろうが、そんなことはどうでもいいんだよ int num, val;
switch(num){
LOOP1:
if(val){
case 1:
break;
case 2:
break;
}else{
case 3:
LOOP2:
break;
}
default:
goto LOOP1;
break;
} >>131
一般的なプログラムは書いたらお終いではなく、デバッグしたり、
数年後に変更したりしますので・・・。 xxx_flagという名前のパラメタなのに取りうる値が 1 or 2 or 3 昔のコード見ることで歴史感やプログラマーの感覚を知ることも大事だろ思う
必ずしもスレで言ってることだ正しいとは思えなくなる事もある
ネーミングはプログラマーのセンスだしあだ名みたいなネーミングでアメリカのコード見てカッコイイなと思ったこともある
プログラム構造も限りある各種リソース内で有効利用するべく例外的にわかりにくくなることもある
自分の経験からだとメンテしやすいからとかいって全体や詳細機能を疎かにしたまま
修正することで発生するバグの発覚や特定の難しさが困難になることもあげておきたい なんかよくわからんがそれっぽく動いているから良し！ オープンソースの仮想通貨もコードを見ると開発の能力がわかる
新興のパンプだけの通貨は本当にクソコード >>38
Aとは絶対に働きたくない、どこにでもいるタダのバカ
Bのような人は滅多にいないから、話を聞くだけでもためになる
注意を聞き入れてコードを直すかどうかは、Bの立場による
Bがただのメンバーなのかリーダーなのか・・・ >>108
その4つはなおったが他に不具合を発生させたかもね >>1
経験上インデントに文句言うエンジニアはスキルが低い。
関数名が記号+数字で統一されているプロジェクトに配属された奴が言うには
最初はアホかと思ったけどドキュメントが完璧に整備されているし命名規則が決まっているので数字を聞けばどのサブシステムなのかすぐにわかるので効率がとても良かった。 C#で、文字列中の{0}や{1}にパラメタ文字列を埋め込める便利な"自作"関数を重宝してる会社
さすが、丸○PC請負会社のクオリティーや〜ｗって思った >>131
デマルコの言う、「駄目な管理者」の典型。 >>38
A嫌い。Bはカチーンとくるけど、クソコード書かないなら受け入れろ。 客から1ヶ月で動作させるのに1万ステップ書かないと動かないコード作ってくれって言われた時は、設計とか検討をすっ飛ばして、とにかく動く奴作ったな。
途中、見積りで1万越えそうなんで残業させて下さい。
1万越えるなら設計しろ！と言われたら、設計だけして逃げますよ？って脅したなぁ。
一番面倒だったのが、変数名を意味の通る英単語で並べる作業。
お陰で英語力が目茶苦茶着いたな >>143
インデント大事。一目で何書いてあるか読み取れる。
インデントメチャクチャが好きなお前は
ソース読むのに時間がかかり、さらにお前が作ったバグを誰かが修正しただけ。
なのに勘違いしてる愚鈍なお前。
インデントメチャクチャなのはバグの温床になる。 >>135
1bitのフラグが2つ入ってるんだろう 画面に通知もしないし、ログも吐かない。
単に例外の握り潰しを意図して記述されたtry-catch。
全てのメソッドでそれやって客に納品したとか平気でのたまう人に会ったことがあるなー >>87
昔、VB6のシステムで、DAOだかRDOの制限のSQLのクエリの文字数の制限（32,767バイト）をオーバーさせた
奴を知っている。どうやったらそんな長いクエリができるのかと。 ネクタイしめて、プログラミングを製造と呼ぶところは大概ヒドイ。
クソコード以前にクソアーキテクチャと、隠しきれず随所から滲み出ているプログラミングへの見下しから物事ははじまっている。 >>1
ざっと目を通したが（組織内で）統一されたコーディングスタンダードがないのが原因
決まったコーディングスタンダードを破りまくる人間なんて和洋を問わず見たことも聞いたこともない
スタンダードがおかしいと疑義を呈するのは構わないし適度に組織を活発にするぐらいで、決定権者に経験値があれば
揉めることはありえない
コードについては適度に最適化されていれば気にはなることはないだろう
最適化されたコードは遠回りな事もするが、理屈は通ってるので問題になりえない
本来見るべきでない外部に対して意図的にコードを汚くする連中はごくたまにいるらしいので、
なぜ汚いかの本当の理由を察するのも必要
良く聞く議論は、コメント量がソースコードの８~９割以上を超える場合、ページスクロールの量が多くなるだけでなく
コメントとソースコードが混ざることが前提とする傾向があり、コメントがないと読めないソースコードが量産される
https://blog.codinghorror.com/coding-without-comments/ >>146
それはYAMAUCHIやなくてもいけるらしいぞ。 仕方ないかも知れないけど、プロジェクトごとにコーディングルールが違うのはつらいわ
{ >>152
帳票だとありうるかもしれん
銀行系だと死ぬほどテーブル連結する ・丸々どっかの知らないシステムのソースコードが入ってて、そのクラスを拡張して使っている。
・丸々どっかの知らないシステムのソースコードが入ってて、その一部の関数を使っている。
昔、中国に外注出した時は、だいたいこれ。1ファイル数千行とかざら。 一般論として言えるのは、「自分は人間」って事を忘れているヤツがコーディングするとクソコードが量産される。
自分は人間だからヒューマンエラーを起すし半年後の自分がこのコード見て瞬時に理解できるかを考慮すると
クソコードは生まれない。
クソコードを書くヤツって大概自分自身が低脳であることに気がついていない。
まあ低脳って気が付くヤツは低脳じゃないんだけどなｗ どんなにコードがクソだろうが、きちんと動いてるものに勝るものは無い 今使ってる外注のソースコードみたら関数名が
****01,****02,****03,****04・・・・ってなってたorz
コメントの書き方とかもMISRA風だったから、たぶん社内規約なんだろうけど
そういう所とは今後付き合えないな・・・ >>162
今現在動くのは当たり前
世の中で、最初にリリースしたまま何も修正されないソフトなんて殆ど無いよ？
だから改造したときに、どれくらい安全に改造できるかが大事
お前もソフト屋ならクソとミソの区別はしろよなｗ
(ソフト屋じゃなかったらごめん) SQL一発で済むものをわざわざカーソル作って繰り返し処理してるの見て
最初、なにしてんだろこれ？って理解できなかった。 >>151
ウチに出入りして業者のソースコードもそんな感じ
確実にtry/catchの悪用だよ
try/catchで例外もみ消すと、自分の想定していた以外のことが起こっても
プログラムが何も騒がないからわからないんだよね。
で市場に出してから不具合連発なんだけど理由がわからないという惨事になる。 # なぜかこのif文があると動作する、削除禁止
if ( hoge == 0 ) {}
とかいうソースコードもたまに見た気がする。
でも、昔は実際に意味不明なエラーに意味不明な対策があったりした。 >>167
それね
たぶんコンパイラのバグを回避するためのモノだと思う
1行無駄な処理を入れるとコンパイル時に適正な最適化をしてくれるようになったりするよ >>38
自分がソフトでメシを食っていくつもりならBを受入れろ
昔俺の職場にもAタイプとBタイプが居たがリーマンショックの折、Aは全員技術職から外されたよ >>95
mikan、ringo、bananaを使っているやつはこの前見たよ // 2010.4.20 不要なコメントを削除 add start
// 2010.4.20 不要なコメントを削除 add end ITとかよく分かんないけど
やってきた成果物みたらそんなに苦労してるの
本当に阿保ばかりなんじゃないか？
Iモードとかゲームとかそんな大騒ぎするもんじゃないだろ。特許の検索とかはまだ分かるけど
電子カルテとか銀行システムとか1回発明したらそれで済む様にしろよ。自分らの業界で自作自演してるだけやん。人材じゃなくてコストと言われても当然だと思う。 変数名が、ayanami0、ayanami1、、、、、 カーニハンスタイル派とオールマンスタイル派でもめたりしたのも昔の話だなー >>167
SJISのソースだとコンパイラによっては//コメントの末尾に0x5Cが含まれるマルチバイト文字があると次の行もコメント扱いされる
なのでコメント扱いされても困らない無駄な1行を入れたと思われる スペルミスというか、英語のはずがローマ字になってるやつ うちの会社クラス名の規約が業務コードや処理コードを書けってなってる…
三項演算子も見づらいから禁止
頭固いおっさんが作ったんだろうけどアホすぎる >>155
どうせ副作用があるんだろｗｗｗ
慣れてない言語で踏みやすい地雷 >>172
おえええええええ
昔の職場を思い出した
バージョン管理使っていてもこれ書くルールがあるからな意味分からん >>38
どう見てもAだろ
このスレ見てる時点でAいらない子じゃん
Bなんかそれこそここ見る連中と変わらんのだから >>165
そういうのあるよね
SQLで一発で済むのをプログラムで二次元配列に入れてひたすらループして集計してるってのがあったわ >>184
それはまともに動かないからクソコード以前の問題
ここで言われてるクスコードってのは見た目では動くのが前提だろｗ >>187
昔書いたコードを改造しようと見たら未来の俺に対して謝罪しているコメントなんかがあって
クスっとくることあるｗ
「この処理には・・・略・・・結局何が言いたいというと設計に失敗しました。ごめんなさい」
なんて書いてあった時は笑ったけどねｗ ただ動くだけのプログラムなんて猿でも書けるからな。
他人も理解できるように設計できるかが人間様と猿の違い。 普通にfor使えばいいのにmapで回したり
やたら三項演算子使ったりするコード >>167
いや、金融系のプロジェクトで
とあるメーカーのシステムが
同じ状況だった
メーカー側の問題だったので
公にしないでコーディングしたが
取得したメモリ領域を一度0ｘｆｆで
埋めてから使うという裏技が出来た
その関数名は『keep_clean』だ 変数のスコープとか変数の名前はよくあるけどな
JVMから外部コマンド呼んだりするキチガイは死んで欲しい >>184
動的allocateを無限ループで自滅
悲しい思い出… >>195
ウチはそれをやったけど、結局Aの方がブチ切れただけで何らAの改善はなかったよ
そしてリーマンショックで整理統合されてAは営業に回されてた。
Bの言い方も悪かったんだが、客観的にみてBのいう事は正しいので、それを受入れる度量と
指摘された問題点を問題として理解できる脳みそがなかったって事でリストラされたよ >>192
コボラーはおとなしくCOBOLだけやってた方がいいぞｗ >>196
forkをループして死んだことがあるわ >>199
コールが重なると
えらいことになるからなｗ
100も入ればタヒぬ ■ このスレッドは過去ログ倉庫に格納されています
