Xcodeコメントの基本 - Toyship.org
これはiOS Advent Calendar 2014の12日目の記事です。 年の瀬もだんだん押しせまってきました。 年末年始のお休みの後に、「あれ、このメソッドどんな目的で作ったんだっけ？こっちのメソッドとの関係はどうだったんだっけ……」など無駄に悩まないために、このあたりでソースコードのコメントを見直してみましょう。 Xcodeでのコメント そもそもソースコードにコメントを書いた方がいいかどうかは長い議論がありまして……。 コメントによりコードの理解は深まるので、あったほうがいいという意見もありますが、コメントを書いたあとにコードを変更してしまうと、コメントとコードの内容が違ってしまい、かえってバグを生んでしまうためコメントを強制するのは害悪だ、という考え方もあります。 また、適切な命名規則を守ればソースコードを読むだけで理解できるという考え方もあります。 実際には、プロジェクトのライ
Xcodeでデバッグ実行中にクラッシュした時に捗るブレークポイント設定 - Qiita
ずばりこの設定です。 ExceptionはAllでも良いですが、実際の動作に問題無い内部例外に反応しちゃったりするのでObjective-Cにしてます。 po $arg1について気になると思いますが、そこだけ見たい方はこちら 通常、クラッシュするとここでブレークしちゃうため、 左下の＋ボタンから、これを追加しておくとクラッシュ時に原因箇所で止まって捗るテクはそこそこ有名だと思います。 このようにブレークする場所が分かりやすくなる: po $arg1について さらに、こちらは有名じゃないと思いますが、Debugger Commandアクションに以下を入力しておくと、 このようにブレークすると同時に自動的に原因のログを出力してくれます。 無設定だと、1回目にブレークした時点ではクラッシュについてのログは何も出ていなくて、1・2回デバッグcontinueボタンを押すと、ログが吐き出されます。 即
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
