検査し成功することをもって、安全性の根拠としている。防ぎつつ自動的な判定を行うためのものなので、いくらか保守的である。「本当は安全なのに、コンパイラでは安全であると判定できないコード」というのが存在する。コードという概念である。ブロック中で実行しようがアウトであり、この場合未定義動作や脆弱性などが発生しうる。破ってよいという仕組みではない。ブロック中における安全性は人間が注意深く確認し保証しなければならない。フルセットが存在する。部分に原因がないと発生しないようになっている。コードは、重点的にチェックする価値がある。コードが必要になる場合というのは、限られている。厳密にはこれ以外にもいくつか状況はあるのだが、まあ大雑把にはこんなものである。正当性がなかったり薄かったりする疑いがある。残る2つについては、その必要性は十分にチェックすべきだろう。処理で効率化を提供していることが多い。部分はプロジェクトの存在意義の少なからぬ部分を占めている場合が多い。あってほしい部分は仕方ないものとして、安全性を確認することに注力したい。ある必要のない部分については、たとえ安全であるとしても要注意である。する価値のある高速化であるかは別の話。本当に高速になっているのかはよく確認すべきだし、必要を確信できる効果が観測できるのなら、それはドキュメントなりコメントなりで記されて然るべきである。逆に最適化でほとんど消え去るような変更だったとすれば、コンパイラのチェックを迂回してまでこだわるべきではないだろう。何事もバランスである。「エアバッグとシートベルトを外すことで車体が軽量化でき、燃費が良くなります!」などと言われて燃費を優先する人がいるものだろうか。言語の思想レベルでも安全性がかなり重視されており、安全性の自動的な保証を諦めてまで行うべき高速化であるかはよくよく検討すべきである。使いすぎ」というレビューをするだけでも良い。それによって後続のレビュアーや利用者は未発見のバグを警戒することができるようになる。コードが安全である条件と、それが満たされる根拠が説明されているか」である。条件チェックなどで保証が行われるか、データ構造としての制約や、提供されている処理の制限などによって安全性が保証される。コメントがあるべきである。いったコメントがなかったら、貢献のチャンスだ。条件を把握し、コメントを書いてプルリクエストなり何なりを投げてしまうのが良い。条件が明示されていても、それが本当に正しいかはよく考えるべきである。いったことは機械的な検査では難しいので、多数の人間が考えればその数がそれだけ信頼になる。「他の誰かが確認しているだろう」と放置するのではなく、できるだけ自分で納得できるまで考えるのが良い。安全性の条件は満たされているか?期待される安全性の条件が問題ないと考えたなら、次はそれらの条件が実際に満たされているかの確認もする。条件を一度明文化してしまえば、ロジックを追いながら確認するのもやりやすくなるはずである。よる検査を挟むという手もある。追加するパッチを送ってしまうのが良いだろう。いった貢献により、将来コードを編集したりレビューする人が、条件が満たされていることを確信しやすくなる。報告してしまうのもアリだ。この場合、作者やコードをよく理解できた人が応答してくれるだろうし、場合によってはコメントなどを追加してもらえるかもしれない。条件が満たされていないことを発見してしまったら、これをそのまま報告しても良いし、余裕があるならバグ発現コードを作ってみて報告しても良いし、修正を一緒に提出しても良い。そもそも条件が満たされないことを発見する過程で何が起きるとマズいか把握できているだろうから、他人に理解させてから修正を待つよりも、おそらく問題を現時点で一番よくわかっている自分自身で直してしまうのが最も無駄がないだろう。ないと形容するためだ。コードの問題について報告するときに使える便利な言葉である。それは綺麗か?これは多分に美的感覚の入り込む場所なので修正されるべきか客観的な判断が難しい場合も多いが、もし「どう考えてもこう書いた方がいいだろう」と思ったなら、パッチを書いて投げてしまうのが良い。されて終了だし、考える余地があるなら議論なり修正なりが進むことになるだろう。数は気にしても良いかもしれない。忙しそうなプロジェクトなら、必要性の低い、あるいは本質的でない修正は提案しない方が良いということもあるだろう。)こういった本質的でない変更は、レビューというよりはむしろプロジェクトのコードそのものに対して反映されるべきものが少なくない。覚えておく記憶容量が勿体ないので、さっさと報告なり修正なりして外部記憶へ吐き出してしまおう。使うというものがある。投げてしまうのが良いだろう。いった「やらねばならないが実害が小さいので放置しがちな作業」を解決してもらえるのも存外ありがたいものである。それは説明されているか?テストされているか?正直なところ、これはちょっと難しいというか、あまり参考にならないかもしれない。コメントやドキュメントが整備されていたところで良いコードかは別問題だし、テストがあるからといって効果的だとも限らない。巨大なコードであるにも関わらず十分なドキュメントやテストのある形跡が見えないのであれば、これは不安要素であるには違いない。私の体験それで、あれこれ語っている私は何をしたのかという話である。Robbepop/string-internerイテレータからコンテナに値を入れるとき、事前に長さが判明していたら事前にメモリを確保できるというだけの話。実装されているのが自然だよね、というだけの話。説明するほどのことでもない簡単なものである。使えそうだなというのは、まあ眺めてると浮かび上がってきたやつで、慣れである。存在することを思い出したので書いたもの。コンテナとして振る舞うという直観を既に持っており、ひらめきが近かったというのはあるだろう。こんなものはちょっと書いてやれば済む話であって、さっさとパッチを投げてしまうのが一番手っ取り早い。して改善しておけば、得をするのは次のリリースを自分のプロジェクトで使う自分自身ということになるので、躊躇う理由はない。(具体的には、メモリ消費量を半分近くにできる)。完全に排除するのではなく、安全性を説明し確信する方向で読んでいくことにした。Robbepop/string-internerとりあえずひととおり眺めてみて気になるのが、以下のような部分である。それを確認するには、作者がどこまで速度を重要視しているかを考える必要もあるのだが、まあひとまず置いておこう。指摘されてから議論すればいい話である。する」というチェックを飛ばすためのものである。確認済であるから安全ではある。アセンブリを見て比較・調整してみることにした。書き方をするにもいくつか方法がある。置き換えるのが一番差異が少なく済むということになった。バージョンでは絶対にジャンプしないジャンプ命令がひとつ挟まるだけで済む。最終的に、こう直すことにした。使うことでここに来ることはないという意思を明示した。プログラムは未定義動作ではなくメッセージとともにクラッシュすることでバグの存在を明示してくれる。コードだと立ち止まって周囲を確認する必要があったのに比べれば格段に読みやすく、また弄りやすくなった。逃げることはできない。引用するのも面倒なので省略するが、雑に言うと文字列の生ポインタの参照を外す箇所とスレッドセーフであるという指定をする箇所がコンパイラによらない検査を必要としている部分であった。オブジェクトの利用がスレッドセーフである理由はコメントで簡単に説明されていたためそれを参考にしつつ、自分で納得しながらコードを理解していく。することでこの条件が破れる」というものである。自体の寿命より長生きさせられる心配はないと考えていたのかもしれない。検出できなくても理屈のうえでは確実に駄目なメモリアクセスが発生しているはずなので、かくなるうえはテストケースや内部状態のダンプで示すしかない。プログラムをクラッシュさせることである。コードのみでは未定義動作が起きないという保証がされている。(まあ厳密には特例があるが、いずれ修正される見込みだし本当に特例なので無視しよう。コードに問題があるという証拠となる。未定義動作の一例は「実行のたびに違う結果が出る」などであるが、厄介なことに未定義動作なので実行のたびに正常に見えるそれっぽい挙動になって確率的におかしくなるのでも良いし、わけのわからない暴走を始めても良い。し、タイムトラベルを可能にしても良いし、鼻から悪魔が出ても良い。「普通に考えてこうはならんやろ」とか「正気とは思えん」となるようなおかしな挙動を観測できれば大抵は勝ちである。大概、それっぽいいい感じのメッセージを表示したうえで異常ステータスとともに「ちゃんと終了」する。文句を言われるレベルでの異常終了になる。誕生した理由の一端でもある。実のところどうすれば不正なメモリアクセスが発生するかは既に道筋が見えていたので、私はそれを引き起こしたのちオブジェクトの中身を適切な形でダンプするコードさえ書いてしまえば、「ほらここで解放されたアドレスにアクセスしてるでしょ」と言えば済むわけである。そのようなヤバい実行例を用意した。出現」で未定義動作が示せた。この時点で報告を投げた。原因と再現コードがわかっているのだから、あとはテストを書いて直すだけである。修正のコードでコメントなどに記載できるので、ちょっと便利なのでおすすめ。され無事終了となった。追加のテストバグを修正できたは良いが、未定義動作が起きていないことを保証するというのは一般に難しい。テストで「おかしな挙動を弾く」ということを試みても、未定義動作が「おかしく見えない挙動」をしてしまうことは十分にありうるし、また確率的におかしくなる場合はテストを単純に実行しても異常を検出できないかもしれないからである。関するコメントを増量して提出した。何なのかまあここ数日の進捗みたいなものを雑に書いただけなので、だから何と言われても教訓を引き出すようなことでもないが。コードレビューについてはえらくいろいろ考えている風なことを書いている割には、実際やっていることが「眺めてたら光って見える」みたいな雑なアレであるということを察してもらえれば、日記じみたものを書いた甲斐があったというものである。文脈でよく言われる「十分な目の数があれば〜」と似たようなもので、数がそれなりに大事になってくる。品質も高いに越したことはないが、そこは信頼の連鎖でうまく計算を調整することで、多少品質の低いレビューがいくらかあってもどうにかなる。よって、無理せず手の届く範囲でやるのがまず大事ということである。コードの品質や信用などは主観的なものであって、ゆえにそれらはあくまで人間の目と各自の判断によって決定されるべきという立場である。OK」とかそういうレビューはしない方がいい。(そんな評価はそれこそツールですれば済む話で、数を集める必要はない。いうか、しているとレビュアー自身が信用されなくなっていくと思われる。セクションに書くということになっている。危険性をどうにかしていく流れが感じられる。いった状況で、コンパイラが機械的に検査できない部分を確認する人間の目の数が増えるというのは大変心強いものであり、まあ早い話が慣れてきた人はどんどんレビューしてみてほしいという話だ。仕組みによって共有・算出しようという試みである。コードレビューはそれ自体もコミュニティへの貢献だが、プロジェクトの開発自体に貢献する契機にもなる。コードを読んだのなら、ついでにバグ報告やパッチを投げてしまうのが良い。コードリーディングは良いコードやバグに触れる機会でもあり、バグ探しの実践でもある。勉強になるし、時間をかける価値は大いにある。軽率に手を出してみると良い。(コレクション気分で無限に手を出していくのもありだと思う。レビューが雑にならないなら。(小並感)ユーザ増えてくれ。同名のブラウザ拡張が存在するが、これは全く関係ない。個人情報を収集・販売しているなどの話もあり、むしろ良からぬ意図をもって名前をぶつけてきたのではと疑ってしまう。[0]ここでいう署名とは、メールの末尾に付ける個人情報などの全く信用ならない自称の「署名」ではなく、暗号学的な意味での「署名」である。無料で貰えるのなら貰っておけばいいと思う。そのうちどこかで役に立つかもしれない。持ってて損になるようならそのときになって捨てればいい。[2]ここでいう偽陽性とは、安全でないものを誤って安全と判定してしまうこと。避け難いことは、確認が不要であることを意味しない。ソースコードまで遡って確認している。限らず別言語についても十分な知識が必要になるため、重要ではあるが誰にでもできることではないだろう。無理せず自分のわかる箇所に注力して確認をするのがよい。[4]面倒というのはちょっと誤魔化しで、実は私は定量的な評価をするためのベンチマークとったことがない。秒単位とかで効いてくるものは大雑把に測ったりすることはあるが、精密な評価をするには考えること、やることがあまりに多くてダルいためである。理由はあるのだが、計測するのが面倒だしこれ以上良くならないだろうから十分だろうというかなり雑な決断である。文句を言われたり疑問を呈されたりしたら、そのときはまたどうにかするなり引っ込むなりしよう。除去するだけで未定義動作に突入しうる。絶対に除去するべからず」とでも書いておけば良いのかもしれないが、人間の注意力に期待するよりもコンパイラの検査に頼る方が現実的というものである。[7]ある種の「訓練された性格の悪さ」みたいなのが必要かもしれない。何らかの条件のもとで安全と言われると、その条件を破ってみたくなるものである。このような性格の悪い思考は、エッジケースでのバグを未然に回避したり有効なテストケースを作り上げたりバグを発見するのに非常に有益なスキルであり、なにかと重宝する。[8]本当に何故なのか。いう機能あったと思うんだけど。フォーマットというのも時代を感じさせる表現になってきましたね。未定義動作を踏んでいるままバグの存在に気付かないというのが日常茶飯事なのである。ここで「問題なく動いてるならいいじゃん」と思ってしまうのは考えが甘い。未定義動作というのはどのような結果になっても良いことになっているので、ある日コンパイラのバージョンを上げると今まで何事もなく動いていた箇所が滅茶苦茶な挙動になってメモリを無限に食ったりクラッシュしたりランダムな値を吐きはじめたりなどするので大変厄介であり、これを許容するなど言語道断。未定義動作で暴走したプロセスに食われたのが私である。レベルの検証結果の共有だったら皆大歓迎だろうが、そういうのは外れ値なのでここでは考えない。この話は終了になりますよ。借用検査は組込の複合代入演算子に対して特殊な動作を行う。