【日記】ぼくが直面しているクソコード

Friend, Publicを滅ぼせ

 PublicやFriendな変数は極力使っちゃいけないと思います。「簡単だから」「動けばいいから」と乱用されると、どこからデータを取っているのか、外から設定されるのか、どこにデータを渡しているのか、渡されているのか、段々と分からなくなっていきます。
データの流れが一目で分からないということは、直せない、改良できないということです。どこに影響しているか分からない、どのタイミングで変わるか分からないものを作っちゃいけません。後で他人が苦しみます。ぼくが苦しんでいます。
オブジェクト指向的には基本となるデータは1つだけ、それを参照渡しして操作は末端でのみ行うというのが最良だと思います。

お前その関数読めんのか?

 関数は画面1枚で収まるのが基本だと思います。収まらなくていいのはどうしてもまとめ切れずFor文も使えないような単純処理の繰り返しだけですし、それだって発生するのは設計が悪いか頭が悪いかのどちらかです。
 まとめなきゃいけない理由は以下の3点です。

  1. 出てくる変数が多くなりすぎ、どの変数がどの処理に使われているのか分からない
  2. 人間の目はスクロールで文字を動かすと、コードの特徴量を捉え難くなる
  3. 書き直す操作量が行数のべき乗で増える


 1がまず大きな問題で、大体の追うのがダルい関数は変数の宣言と使われる場所が離れていたり、一度使ってもう使わないような変数がゴロゴロ出てきます。テストコードで1つの関数にまとめるのは構わないと思いますが、分離できる処理はある程度分離すべきです。分離しておけば使いまわせることもありますし、関数の名前から処理の内容が分かります。
 2と3も重要で、変数が宣言された場所と使われる場所が離れていると直すときに非常に労力がかかります。止まっているものと動いているものでは当然止まっているものの方が見やすいです。それは移動が離散的であっても変わりません。「動かせば見失う」のです。そして見失うから探して、探したから見失って、操作量はべき乗で増えます。ダルいです。

「関数は長く、名前は短く」

 個人的に関数は長く、変数名・関数名は短く書いているようなコードはクソコード率が非常に高いと思ってます。関数の長さについては前述の通りですが、変数名・関数名の短さもクソコードの特徴です。
これらは短縮したからって分かりやすくはなりません。むしろ可読性が下がります。変数名の短縮に頭を使うぐらいならIDEに甘えて補完を使いこなしたほうが良いと思います。
 個人的に変数名は役割を表す1文だと意識しています。パリピを知らない人にパリピと言っても何のことか伝わらないでしょうし、何のことか伝わってもそれがどんなものなのか具体的に伝わるとは限りません。会話はともかくコードに書くならTerriblePeople位書くべきです。
 更に続けると、こういったコードの処理はほぼ100%冗長です。1行にまとめられる処理に何行も使い、関数に分離できる処理も一まとめかつゴチャゴチャになっていて、そのくせ変数名は3文字や4文字、これでは何がなんだか分かりません。
 後で苦しむのがあなたなら別に構いませんが後で他人が苦しむことも当然のようにあります。繰り返し言いますが今ぼくが苦しんでいます。

あーーーーーすっきりした

 愚痴を吐くためにクソコードがなぜクソなのか考えたことをまとめました。途中に変な方面への口撃が入ってますが、読み返しても取り下げる気にならない程度にはストレスが溜まってたんだなあと賢者タイムしています。
 一応もう少しで解放される予定ですがそれがイコール納期な訳で、デバッグ作業へ掛けられる時間の無さに今から頭が痛いです。。。
 予防線を張っておくと、自分は天才ハカーみたいにプログラミングができる人ではないので、この記事はストレスからのでまかせです。