明日で今週は終わり、一番忙しいであろう山場は乗り越えられそうな空気を感じます。
といっても来週からはデバッグ期間でバグ報告があれば対応しなければいけないのでまだまだ厳しい状況は続きそうですね。

久しぶりに先輩に自分のソースコードを見てもらい、初めて文句なしの評価をいただきました！
叱られたりした分喜びも大きいですがまだまだ頑張らねば、という気持ちです。

これからはコードや設計に関してのことより、
メインプログラマーとしてやっていくためのプロジェクトのマネジメントみたいなものの考え方を教えてくれるそうなので非常に楽しみ

この頃は前よりも書き方に無駄がないようにという意識が強くなった気がします。
ifやforを１行で書くときに中カッコを省略するか否かはまぁさておいて（私は最近つけなくなりつつある）
制御構造のネストはなるべく深くならないようになった気がします。
条件に合っていないならはじく、条件に合っていれば処理をする、と書けばネストは減りそうです。

あとassertをよく使うようになりました。
プログラマー自身への戒めでもあり、コードミスを減らす方法論と言えます。
しかし使い過ぎは禁物。

止めなくてはいけない処理は止めても、
止めてはいけない処理はスルーしてアプリが進行するように作る、意外と難しいのです。



プランナーやデザイナーは制御構造や複雑な分岐など知らないので、なるべく
「～という条件で～になる」
くらいのレベルまで単純にするのが望ましい。
プログラマーは職業上複雑な条件も理解できるが、プログラマー以外の人にはわからんのです。

なので最近はelseもあまり使わない方向性です。
なるったけifやswitchだけで分岐できると構造は非常にシンプルと言えます。


そんなことを勉強。
まだまだ覚えることは多い、ではでは！

せんちゃ さんが書きました:あとassertをよく使うようになりました。
プログラマー自身への戒めでもあり、コードミスを減らす方法論と言えます。
しかし使い過ぎは禁物。

止めなくてはいけない処理は止めても、
止めてはいけない処理はスルーしてアプリが進行するように作る、意外と難しいのです。

大手クライアント(に限らないかもしれませんが)には異常終了した時点でデバッグ作業を中止して改善されるまで再開してくれないところがあるので、画面に出るはずのものが出なくてもとにかく動き続けるように作らないとあっという間にスケジュールが押してしまうんですよね。

assertはどのみち異常終了する状況でログを吐くためだけの存在と言えるので、assertじゃなくても良かったりして。


実はわたしはあまりassert使ってないんですよ。
assertってここに異常な値が来たら、というチェックじゃないですか。
異常な値だったらそもそもここに来ないというふうに作れば要らないんですよね。

日記の内容と関係ないですけど、std::vectorは連結リストじゃないですよ>> twitter

＞ISLeさん

ISLe さんが書きました: assertってここに異常な値が来たら、というチェックじゃないですか。
異常な値だったらそもそもここに来ないというふうに作れば要らないんですよね。

そうですね、有効かどうかのチェックをして不可であれば処理しない、という流れにはしますね。
ただ、プログラマー側の注意力ミスによるバグ（たとえばコピペとかでちゃんとチェックしていないとか）
には効果的かなと感じます。

ほかの人にソースを触らせたり他人のモジュールを使ったりする場合なども、
誰が担当した場所で落ちたのかが明確になるので（これもログ出せばいいだけではありますが...）
期待していない値がやってきた場合はデバッグバージョンである限りはassertでもいいかなと感じています。
(さすがに企業に提出するROMはプリントもassertもifdefマクロで全て外しているようですね)

＞h2so5さん
あーすいません。
調べてみましたがアドレスは連続してるんですね。
イテレータとかあるからてっきり双方向リストなのかとばかり思っていました。。。

せんちゃ さんが書きました:そうですね、有効かどうかのチェックをして不可であれば処理しない、という流れにはしますね。
ただ、プログラマー側の注意力ミスによるバグ（たとえばコピペとかでちゃんとチェックしていないとか）
には効果的かなと感じます。

例えばインスタンス処理にすると、ヌルポインタかどうか判断する必要ありませんよね。
インスタンスが呼ばれている時点でヌルポインタではないことが確定しているわけですから。
#クラスを使わなくても同様のプログラムは作れます。

有効かどうかチェックする必要性そのものを減らしたほうが効率良いと思います。
たった1つのチェックでも、それが必要であるということは危険だということです。
そのモジュールを呼び出す階層が深ければ爆発的に危険性を増やすことになります。

制御構造レベルで異常な値が入るようなコードはほとんどコンパイルエラーで弾けるはずですし、モジュール単位のテストを充実させたほうが後から手を入れるときにも役に立ちます。

常に有効かどうかを調べるわけではないのですが、例えば基底などを作ってそこから派生させて実装、
とすると基底の方で扱うデータが常に正常な値なら派生クラスは不正な値を気にせずにコーディングできると思います。
システム部分などの深い階層にあるモジュールも同様にあってはいけないものを遮断してしまえばアプリ部分の実装で余計な心配はする必用はないのかなぁ
というふうに考えています。
止まって欲しくない部分では不正である場合は仮のデータを渡したりは作るのですが、
チームで決めたルールなどでやってはいけないことを途中参加の人がやろうとする可能性もあるので、
そういったとき用でしょうかね。

私は今の仕事が途中参加なのですが、全体で決められたルールがわからず本来使うべきではないところで使うべきではないAPIを呼んでassertを出してしまったことがあるのですが、
それは「呼ばれても不可なら処理しない」というふうに作れなくはないものの混乱のもとになるからそもそも呼ばないでください、
というルールを後で受けたりしました。

その方法論が正しいかどうかはわかりませんが、
明確にやってほしくないことなども明示するには良いのかもしれません。