printデバッグについて

初心者が多用するデバッグ法というと、printデバッグです。誰に教わることもなく、自然と自己発見して使い続けるケースが多い気がしています。

プログラマーの三大美徳には怠惰という文言があります。ただ、この怠惰というのは繰り返し作業をやめるために、アクティブな行動を伴うので、別なポジティブなラベリングがされるべきだし、個人的にはちょっと違和感があります。低きに流れて部分最適化されてしまうprintデバッグこそ愛すべき怠惰な気がしています。

UI/UXというと、すごい意識高い感じだけど、じつは意識の低さが大事だと思っていて、低きに流れた先が最短ルートで目的というのが大事なんじゃないかと。何かを探すときはまずスタートボタン（Windows95）。困ったらホームボタン（iOS）。OSごとのUIガイドラインに従うのも、そのユーザーにとってすでに常識となっている使い方に対応することで、ユーザーに新しい学習を強いることなく使えるようにしてあげると。意識低い重要。

printデバッグは初心者がとっつきやすいけど効率が必ずしも良くない方法の代名詞みたいになっているけど、printを置いたところが勝手にブレークポイントになって、そこのスタックが取れたり変数が取れたり、変更検知とか、すごいprintデバッグに進化してもいいのになってたまに思う。

— 渋川よしき (@shibu_jp) May 26, 2017

で、こういうことをツイートしたわけです。

いろいろ反応があったので、まとめておきます。

@shibu_jp print文の出力結果が全部クリッカブルで、クリックするとその出力時点のスタックフレームに入って対話的実行できる時代が来るよ！

— nishio hirokazu (@nishio) May 26, 2017

いまのところ雑なprintデバッグでこれに近いのはChrome/SafariのDevTool。出力すると、出力した場所の情報も出てきます。オブジェクトとか配列は構造化されていてクリックして中を覗いたりできます。もう１つ思い出したのはWerkzeugのデバッグ機能ですね。ウェブサーバー内でエラーが発生すると、スタックトレースがブラウザ上に表示されて、それぞれのスタックの中の変数とかを覗いたり、それぞれのスタックの名前空間でスクリプトを実行できるやつ。

汎用機な時代には、オペレータリプライ要求付きのコンソール出力命令がカーネルサービスにあってだな、、、けっこうデバッガ的に使ってたヤツもいたような https://t.co/RCNvWwPrm1

— みんつ＠よこはまちほー (@migimatsu) May 26, 2017

rubyのpryのことかなぁ https://t.co/RovUcG73zM

— M.Futakawa (@fm_fata_morgana) May 26, 2017

そういや、JSにはdebugger statementがあったな https://t.co/3VrozYou6z

— Wreulicke:?人 (@wreulicke) May 26, 2017

PowerShellなら環境変数の$DebugPreferenceとWrite-Debugコマンドレットで、デバッグストリームにメッセージ出しつつブレークしたり継続確認のプロンプト出したり https://t.co/SbBLrhBpFq

— KIMATA RobertHisasi (@robert_KIMATA) May 26, 2017

なるほど、binding.pryやJSのdebuggerステートメントとデバッグ出力を兼ねると僕が妄想してたやつに近そうです。リプライ要求付きコンソール出力命令というのはいいですね。

@shibu_jp 昔作ったおもちゃ言語で、「メモリダンプを吐き出す命令」をソース上のほぼ任意の位置に書ける文法にしときました。

— 非実在naka aki (@naka_aki_spl) May 26, 2017

trace_printk() https://t.co/uy0DiXe6pU

— まさみさんは語りたい (@mhiramat) May 26, 2017

そうですね。出力する情報を増やすというのは手っ取り早く効率があがりそうです。

主に組み込み向けですが、自動で関数の開始終了分岐にprint文的なものを挿入。そのままコンパイルして動作させてログを収集、処理の流れや関数の呼ばれた回数、処理時間などを見える化できるツールがあって便利に使ってました。DT10とか。変数も出せたと思う。 https://t.co/hpJUCVL50b

— Tomoya Miwa (@tomoya0x00) May 26, 2017

C言語とかだとマクロでいろいろやったりはありますよね。そういえばバグベアードというのもありました。

わかる。optimized out防止に調度良い。

が、それ故に「debug printをこういう風に入れた場合だけ何故か動く」系に弱く、やっぱり良し悪しだよなー、となる https://t.co/dBN3H3Mgax

— ichimal (@ichimal) May 26, 2017

ハサミと一緒で使いよう プリントデバックはシーケンス処理のデバックには向いてるので多用するのが正解 落ちる系やキワなタイミング依存系やメモリ破壊系やらのデバックに使ったら時間がかかるだけで得られるものは少ない https://t.co/IexrIMQ9W0

— へちょ顔ヤマヒデ@横浜 (@hidekunyamamoto) May 26, 2017

このあたりは別の手法が必要ですね。Goだと、静的チェックではなくて動的にクリティカルセクションを探し出すraceチェック機能がありますしね。

妄想をアウトプットするといろいろ反応があって楽しいですね。