クソコードとは何か

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

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

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

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

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

**デフォルトの名無しさん** · 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代を知っている。

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

ひな形とかサブルーチンって言葉が古めかしいよな

**デフォルトの名無しさん** · 2021/03/11(木) 19:01:33.97

サブルーチン＝クソコードだよ
関数は原則として引数から戻り値を求めるものでテストが容易
もちろん副作用をもった関数もあるけど、わざわざ副作用と言ってるように
副作用は避けるべきものとして考えられてる

サブルーチンは戻り値がなく副作用がメイン
コードの責務とか考えなしに、似たようなコードがあったら
とりあえずサブルーチンにまとめちゃえってなる
その結果テストが容易ではなくなる

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

サブルーチンと関数を別キーワードで定義&コールするFortran流もありだと思うけどなあ

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

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

サンプルが追加されたな

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

クソプログラマーではないのでそれは当てはまらない

**デフォルトの名無しさん** · 2021/03/11(木) 20:37:19.04

クソプログラマーは自分がクソだという自覚ができない
自覚ができないからこそクソプログラマーとして生き続ける

**デフォルトの名無しさん** · 2021/03/11(木) 21:26:53.63

>>910
サブルーチンに戻り値はないというのは勝手な思い込み
プログラミングにおける副作用という言葉は薬の副作用や副反応と違って一般的に望ましくないものという意味は全く無い

主張の中心となる用語をよく理解せず勝手な思い込みでオレオレ理論をふりかざすやつがクソプログラマーでなくなんなのだろうか？
自分の認識が間違ってるかもしれないとは考えないクソプログラマーの特徴がよく表れている

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

関数呼び出しは遅いから関数しか無いCは使えないという恐ろしいFortran使いが結構たりするけどな…

**デフォルトの名無しさん** · 2021/03/11(木) 23:38:43.29

まあインライン化やマクロ駆使してオーバーヘッド削ったCよりは絶対読みやすいので、一理ないこともない

**デフォルトの名無しさん** · 2021/03/12(金) 00:52:41.16

今時FORTRAN使いとかいるのか・・・
どこで使っているんだ？ｗ

**デフォルトの名無しさん** · 2021/03/12(金) 03:40:10.66

理学系とか今でもFORTRANらしい

**デフォルトの名無しさん** · 2021/03/12(金) 03:51:45.30

たぶんおじさんの想像するFORTRANとは随分違う言語だぞ

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

>>918
母数がわからんけど、HPC分野だとまだまだFORTRAN優位

次世代スパコン「富岳」の重点課題で開発するアプリのうち，Fortranでないのは一つだけ．
https://qiita.com/implicit_none/items/ad4c556c043a91fa0dc4

**デフォルトの名無しさん** · 2021/03/12(金) 10:14:24.86

Fortran2018？

**デフォルトの名無しさん** · 2021/03/12(金) 11:45:41.06

サブルーチン・副作用は、状態を持つから、ややこしい。
Ruby 3 のマルチコア並列処理・Ractor でも問題になっている

状態を持つと、共有変数の排他処理が難しいから、
関数型のElixir みたいに、immutable にしないといけない

**デフォルトの名無しさん** · 2021/03/12(金) 14:09:01.67

デッドコードは、見つけて、取り除く必要がある。デッドコードを残しておくと、プログラマの理解と行動を
妨げることがあり、コードが実行されて、重大な問題を引き起こすリスクもある。デッドコードの削除は、
技術的な問題ではない。Kevlin Henney氏によると、それは考え方と文化の問題だ。
https://www.infoq.com/jp/news/2017/03/dead-code/

**デフォルトの名無しさん** · 2021/03/12(金) 14:22:11.99

仕様変更でなくてもよくなった箇所は、削除より、いったんコメントアウトで対処した方がいい。外国人はコードを変えて失敗する能天気だから、あいつらの言うことに従ってはいけない。

**デフォルトの名無しさん** · 2021/03/12(金) 14:26:53.48

>>925
VCS使えよ

**デフォルトの名無しさん** · 2021/03/12(金) 14:35:41.22

>>925
いつの時代の人だよw

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

必ずそういうことを言い出すやつがいるが、経験不足だと思うよ。いちいち見比べる方が効率が悪い。

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

すぐに削除しない方がいいと書いてあるのに、早とちりさんが多いね。

**デフォルトの名無しさん** · 2021/03/12(金) 17:02:54.30

>>928
> いちいち見比べる方が効率が悪い。
差分ツールも知らない爺乙

**デフォルトの名無しさん** · 2021/03/12(金) 17:19:15.11

見比べている自分の光景を想像しろ

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

削除するなとは言ってない。ガンガン削除してもいいが、残ったコード内でこう作った意図がわからなくなるくらいなら、システムの作り直しの時点で変えるべきた。

元のデッドコードの話自体は初心者の話だし、コードの書き換えに躊躇がなく、バグだらけにするのは外国人に多いわけで、有名な製品をアップデートするとおかしくなる最大の理由。

**デフォルトの名無しさん** · 2021/03/12(金) 17:41:07.46

外国人のフリして逃げる

**デフォルトの名無しさん** · 2021/03/12(金) 18:44:33.92

クソコードとは俺が書いたコード

**デフォルトの名無しさん** · 2021/03/12(金) 18:52:31.32

またまたご謙遜を。

**デフォルトの名無しさん** · 2021/03/12(金) 19:22:54.23

オープンソースはかなりの確率でクソコード

**デフォルトの名無しさん** · 2021/03/12(金) 19:44:02.10

YAGNI (You Ain’t Gonna Need It) 直訳は「そんなモン要らんって！」
YAGNIの原則は「機能は実際に必要となるまでは追加しないのがよい」とすること。後で使うだろうという
予測の元に作っても、実際に使われるのはほんの一部。ソフトウェア実装において「予期しない変更」は常
についてまわり、できるだけ設計をシンプルにするべき。現実の問題に集中して余計なモノを足さない。
それがヤーグニ。
https://www.jabba.cloud/20180119204314/

**デフォルトの名無しさん** · 2021/03/12(金) 19:56:22.98

業務システムにはあてはまらない。

**デフォルトの名無しさん** · 2021/03/12(金) 19:58:56.77

>>937
仕様変更を想定しないといけないとわかっていながら、そのときの仕様で最適化するのは、その方が周囲から理解をえやすいから。

**デフォルトの名無しさん** · 2021/03/12(金) 20:31:43.28

おまえヤベェわ
さすがクソプログラマースレ

**デフォルトの名無しさん** · 2021/03/12(金) 21:37:32.87

外国人の言うことをありがたがっているようでは話にならない。

**デフォルトの名無しさん** · 2021/03/12(金) 21:37:59.65

>クソコードとは何か

スマホ　アプリの６割未利用！不要なアプリの大量保有はバッテリー消耗の一因。不要アプリは定期的に削除を。
https://prtimes.jp/main/html/rd/p/000000049.000005362.html

Androidスマホのキャリアアプリが1GB以上データ通信！？削除・無効化できるアプリ一覧
https://sp1.jp/career-appli/

**デフォルトの名無しさん** · 2021/03/13(土) 09:00:19.17

詫びソースコードコメント 1件

アイミョン
[KS108-054]
テーマ：冒険者の広場・DQXショップ2020/02/17 16:22
今月になってから急にシステム障害が多発しており、運営としては説明責任を果たすべきと考えます。

https://hiroba.dqx.jp/sc/news/category/3/

不具合を出した個所とその修正箇所の両方を「詫びソースコード」として開示するのです。
ソースコードも企業の重要な著作物ですが、だからこそ開示して詫びることが大切です。
それと同時にシステムの不具合がなぜ多発しているのかを、プレイヤーも一緒に考えるのです。
バンダイナムコゲームスの『ドラゴンボールZ ドッカンバトル』を見習うべきです。

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