コミット対象をよりわけるのをやめてみよう - 日々常々
git add {ファイル名} でステージングするファイル単位で選べます。10ファイル変更しててそのうち3ファイルだけコミットしたい時とかに便利です。 git add -p でステージングする変更を行の塊単位で選べます。関係ないコメントを足しちゃったのとか、うっかりついでに変えてしまった変更をコミットから避けたり、別のコミットにしたい時とかに便利です。 間違いなく便利な機能ではあるんだけど、常用するものじゃないと思ってます。 なので git add -A を基本にする。 ……とか言いつつ git add . を常用している私。単にタイプ数と手の慣れ。ちなみにgitのaliasは使わない派です。これは違う環境でコマンド叩く機会が多かったりする都合です。 理由 を並べてみます。 コミット対象を選択するのがいちいちブロッキングなので時間がかかる 10ファイルの変更から3ファイル選択する時間は g
価格が4倍違うモニターアームを買ってみた - 日々常々
先月はじめてモニターアームを買ったのですが、気づいたら2つ目が増えてました。 モニターアーム ガススプリング式 17～32インチ対応 耐荷重2-9kg グロメット式＆クランプ式 VESA100*100 (ブラック) メディア: エレクトロニクス お値段は先日買ったエルゴトロンLXの1/4程度です。製品名は何なんだろう？よくわからない……（わからないので本エントリ内では「こちら」と呼称します） 周辺機器は安いものを買うと安物買いの銭失いになりがちです。 とはいえ価格差の要因も興味あるところ。怖いもの見たさも手伝い「4,000円くらいならゴミでもまぁいいかな」とか失礼なことを考えながらポチりました。 あとエルゴトロンLXだと、追加したモニターより高いことになるのも躊躇いポイント。 ちなみに追加で買ったモニター。 HP 9YF44AA#ABJ HP 21.5インチワイドIPSモニター P224
変更前をコメントアウトして残す習慣は未だ根強い (2012年現在) - 日々常々
2020-03-11追記: タイトルの「未だ」がいつなのかわかりづらいので「2012年現在」を追加しました。 バカバカしい話ですが、ソースコードをSubversionなどでバージョン管理しているにもかかわらず、未だ修正前をコメントアウトして残す習慣は残っているところも多々あります。こういうのです。 // 2012/08/15 irof 修正開始 // hoge = fuga(1); hoge = fuga(2); // 2012/08/15 irof 修正終了 見た事無い方は、そのまま見ないままで生きていかれることを切に願います。 コメントの修正がある場合 2012/07/21にあった、SCMBCでこんなツイートがありまして。 この時点でお見せしたのはこんな感じ。 // 2012/07/21 削除開始 // // 間違ったコメント // 2012/07/21 削除終了 someMethod
職業PGにわかるFizzBuzz - 日々常々
なんかFizzBuzzが書けないPGがどーとか定期的に話題になってるけど、私に言わせれば説明の仕方が悪い。 こうすれば誰でも書ける。 これだから最近の若いもんは……。 GoogleDocsのスプレッドシート、方眼紙作るのに向いてませんね……。
チームでフォーマッターを使うときのあれこれ - 日々常々
（見やすいコードのために出来るたった一つのこと - 日々常々 の続きみたいなもの） 「フォーマッターを使わないなんてありえないよねー」とか思ってたけど、意外と使っていないプロジェクトは多いのかもしれない。思い返せば、私の経験上も多くのプロジェクトで使ってなかった。なので導入する時にあったあれこれを思い出しつつ書いてみる。 必ず同じ定義を使用する 必ず全員同じ定義でフォーマットしましょう。 個々人の好みはあるとは思いますが、それ以上に共通したものを使うことのメリットの方が大きいはずです。 これから導入する場合、まずはその言語で一般的っぽい定義を手に入れ、既存のコードをフォーマットしながら微調整するのがいいです。 なるべく早いうちに導入する 可能な限り早く導入しましょう。途中からの導入も可能ではあります（後述）が、それでもなるべく早期に導入しているほうが、余計なコストもかかりません。 何よりチ
見やすいコードのために出来るたった一つのこと - 日々常々
タイトルは釣りっぽいですけど、結構まじめ。 フォーマッターを使用すること。 これが全てです。「スペースがどうこう」とか「括弧の位置がどうこう」とかどうでもいいです。そんな美的感覚でかわるような枝葉の話に結論は出ません。 コードフォーマッターを使用してください。そのプロダクトを通して、統一された同じフォーマッターでフォーマットすること。コードはそれだけで格段に見やすくなります。個々人が好き勝手にやったり、気をつけたり、CheckStyleなどでの見た目の警告を処理したり……そんなのしてたら不統一で見難いコードにしかなりません。 個人個人での見やすさとかはあります。当然です。例えば変数代入のイコールの位置がそろってる方が見やすい人もいます。変数宣言は1行開いてた方がいいって人も、メソッド間は2行開いてた方がいいとか、賛同できませんけどそんな人も居ます。そう言うときは自分専用にフォーマットして、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
