iOSアプリケーション開発のコードレビューで気をつけていること - ninjinkun's diary
日常的なコードレビューで気をつけていることリストです。GitHub会議(仮)で発表しようと思っていたのですが、日程の都合で参加できないので、書きためておいたメモを公開します。またどこかで発表するかもしれません。 AutoLayoutにできないか AutoLayout化した方がすっきりしそうならAutoLayout化する AutoLayout化できそうなものでやっていないものは、なぜコードで実装したか質問する 例えばUITableViewCell ちゃんと理由があれば別に良い。コードの方が良いことも多い UIAppearanceで解決できないか 各クラスの中にスタイルの指定が入るより、UIAppearanceでスタイル指定を分離して別クラスに書く方がデザイナーも弄りやすくて良い 3.5インチ端末が考慮されているか レイアウトが決め打ちだとここで問題が出ることが多い 着信ステータスバーが考慮さ
Clang-FormatでObjective-Cのコードを整えたらレビュー捗る - ainameの日記
最近Objective-C書いてるのでClang-Formatというツールを試してみた。 些末なコードレビュー - naoyaのはてなダイアリー にもある通り、コードレビューするときにいちいちソースコードのフォーマットを指摘し続けるのはアンチパターンで、人間以外がやるべき仕事。 PerlならPerltidyというツールがあるけど、Objetive-C（C, C++）にはclang-formatというコマンドがある。暇なので社内で導入出来るように調べた。 ClangFormat — Clang 3.5 documentation 使い方 CLIの場合は以下のように実行する。-iで指定したファイルを上書き、-styleでフォーマットを指定する。 $ clang-format -i -style=Google Hoge.m これだけで既存のコードがフォマッターの設定通りに整えられる。 2014年
Objective-C のコードレビューチェックリスト - Qiita
はじめに 本稿は Juri Pakaste 氏による Cocoa review checklist (commit fff5703)の翻訳です。他人の Objective-C のコードをレビューするとき注意する点、また普段のコーディングで心がけるべき点についてまとめられています。 なお、原文のタイトルは Cocoa review checklist となっていますが、内容が Cocoa に限らない範囲のトピックをカバーしているため、本稿のタイトルは「Objective-C の〜」としました。 誤訳の指摘や例の補足を歓迎します。 コードの見た目とコード以外の問題 不要な #import や @class 宣言を消す #import をソートする .m ファイルの中では、対応する .h ファイルの #import を最初の行に書く。空行をはさんで、ソートされた他の #import を書く。 X
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
