そうだ、ソース読もう 〜永遠の初心者からの脱出に向けて〜
こんばんは。せのです
最近テスト案件ばっかりでコーディング出来てません！
のでせめてソースコード読んで力を付けたい！
と思ったので、昼休みにソースコードを読むコツみたいなの無いかなってググってたらこんな記事を見つけました。
以下、記事より抜粋（原文ママ）
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
【1】記録を付ける
「記録を付ける」というのは、自分でノートを付けてもいいでしょうし、
ブログなどでソースコードを読んだときに気が付いたことを書いてみるとかでもいいでしょう。
こういった学習は積み重ねをどれくらいしてきたかが分かるようにするということが大切です。
なんとなくではなく、この日に、このソースコードを読んだ、というのを工夫して記録してみましょう。
記録をたまに確認してみると、努力した分量が分かりますから、それが持続の原動力となるはずです。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
とあったので、早速ですが今の案件のソースコードのファイルを読んで
気づいた点、面白いと思った点、ここダメじゃね？と思った点をつらつら書いていきます。
【気づいた点】
・ORを取ったり、bit移動する処理が多い
C言語はなんでも細かく出来る分（ネガティブな言い方をすると何でもやらなきゃいけない分）
bit演算処理に気を配る必要があるので、読んでると「あ、やっぱり自分は何も分かってないな」というのが分かってきます。
・マジックナンバーほとんど使ってない
C言語使う現場なので、殆どの値をdefineして使用しているっぽいです。
使っててもコメントで補完しているので、可読性が高いです。
出来るプログラマーはこういうところで差が付くのかなと感じてます。
・関数の先頭で異常系の処理をしてる
今日のところは１ファイルを読み進めていっただけなので、これが良い書き方なのかは分かりません。
が、スッキリ書ける異常系は早めに書いて、長ったらしい正常系の処理は後に書くのは良い書き方だなと思いました。
【面白いと思った点】
・プログラマの名前が書いてない
書いてもきっと早晩入れ替わるから誰が書いたコードかなんて
長い目で見れば些細なことですよねきっとうんそうだそうに違いない（白目）
おそらく、この辺はsvnで管理してるのかなと思ったりしてます。
・プロトタイプ宣言と関数の数が合わない
プロトタイプ宣言をしなくても大丈夫な関数があるのか別のヘッダーで宣言してるのかは分かりませんが、どうなんでしょう？
C言語に強い人誰か教えてください！オナシャス！何でもしますから！
【ここダメじゃね？と思った点】
・ビットANDの処理でマジックナンバーが使われてた
コメント書いてるには書いてるんですが、初見ではどういう意図でAND処理をしてるのか分かりませんでした…
正直これはよろしくない書き方なんだろうなと思ってます。
どういう意図でビット演算したのかが一目瞭然じゃないと、バグの温床になりそうで怖さがありますし…
・このswitch文で分岐するためのデータはどこから引っ張ってるの…？
この辺は多分僕の読解力が足りないせいだと思いますふへへ心がしんどいorz
ポインタを戻り値にしてて、アロー演算子でデータ引っ張ってきてるようには読めたんですが、果たしてそのデータはどこからやって来るのか…
引っ張ってくる構造体の中身はどこのタイミングで切り替わるのか、疑問は尽きない…
まあ、多分この辺は開発設計に回らないと全容解明出来なさそうなんですけどねー。
多分全容解明する頃には寿命来る。天寿が来い
・明らかにコピペしてる箇所が複数ある
何やってるんですか先輩！まずいですよ！
ここダメじゃね？と思った点の冒頭にも取り上げたマジックナンバーがペタペタコピペされてる感じの処理が見受けられました。
これはいけない。プログラミング素人の僕でもわかる。
どういう意図で付けたかわかんない16進数でAND処理が行われてる。何これ怖い
更にコピペされてどんどんマジックナンバーのAND処理が行われる。何これ怖い
・一行一行にコメント付けてて直しにくそう
処理の後ろの行に１行コメントが書かれることは珍しいことではないと思うのですが、
問題はほとんど全部の行にコメントがついてる関数があることですね…
長くなるなら、処理前に以下の形で書くとか、関数の説明が書かれる箇所（いわゆるソース看板）に描くとか色々方法ありそうです。
/* ~~~~~~~
なんか長い説明
なんか長い説明
なんか長い説明
~~~~~~~ */
・まとめ
気づいたことをメモしてアウトプットすることで、自分でソースコード書くときにやっちゃいけないことや
こうすれば見やすくなるなと感じることが多いので、ソースコードを読む際に記録をつけることはとても良い方法だなと思いました。
「【2】興味を持っている分野のソースコードを読む」もやりたいですね。
現場のソースコードは仕事の片手間にしか読めなくて、仕事なのでモチベーションも下がるので…
まずはあれですね。ガチャのソースコードを探しまくって読もうかと思います。
