C++11スマートポインタで避けるべき過ち Top10 | POSTD
(注：2017/10/25、いただいたフィードバックを元に翻訳を修正いたしました。修正内容については、 こちら を参照ください。) 私は新しいC++11のスマートポインタをとても気に入っています。自分でメモリを管理するのが嫌だと感じる多くの仲間たちにとって、これはいろいろな面で天の助けでした。私の場合、このおかげで新人にC++を教えるのがずっと楽になりました。 しかし、C++11のスマートポインタを幅広く使っていた2年ちょっとの間で、使い方を誤ると、プログラムの効率が落ちたりクラッシュして壊れたりするという事態に何度も遭遇しました。参照用に、以下に例を載せました。 まずはこれらの”過ち”を、簡単なAircraftクラスを例に取って見てみましょう。 class Aircraft { private: string m_model; public: int m_flyCount; weak_p
コードの品質を維持したまま開発スピードを上げる | POSTD
高品質のコードベースは、反復作業やコラボレーション、メンテナンスを簡単にすることで、長期的な開発のスピードを上げてくれます。Quoraではベースコードの品質は重要だと考えます。 高品質のコードを維持することは利点がありますが、その反面かなりのオーバーヘッドが発生し、実際の開発のサイクルに時間が掛かってしまいます。このオーバーヘッドと利点の折り合いを付けるのは難しい問題です。この場合、2つの選択肢しかないように思えます。低品質でコードスピードが速いか、もしくは高品質でスピードが遅いか。スタートアップは素早い開発サイクルに最適化しているので、多くの人は低品質で進めたほうがいいと思っています。 このジレンマは解消できます。ツールやプロセスを工夫することで、コードベースの品質を維持したままスピードを速めることができるのです。この投稿では、コードの品質に関しての私たちの考えや、2つの世界を共存させる
眼鏡なしのコードレビュー | POSTD
例えば、あなたが驚くほど聡明な開発チームのメンバーで、コードレビューのみに一日の時間を確保しているとします。しかし作業を開始して2時間後、眼鏡を忘れてきてしまい、午前中はぼんやりとしたカラフルな表示を見つめていただけだったということに気づいたとします。さて、あなたはどうしますか? 家まで歩いて10分もかからないし、天気も良ければ、眼鏡を取りに帰るのが一番です。でも朝家を出るとき、攻撃的なスズメバチの群れが眼鏡の置いてある部屋に巣を作って、邪魔されたくない様子だったらどうしますか？ そういう時はもちろん、コンタクトレンズを付けてきたふりをして、恥ずかしい思いをしないようにするのがよいでしょう。実際に読むことなく膨大な量のファイルを見分けることができるということを覚えておいて下さい。 参考コード 1 不安の種は隔離するべきだということに誰も異論はないでしょう。そしてもちろん、あらゆるクラスは一
Scala使用歴5年のプログラマが、この言語とその環境に関する神話を解き明かす | POSTD
(注：2016/1/21、頂いたフィードバックをもとに記事を修正いたしました。) 『 Programming in Scala (Scalaでプログラミング) 』の初版を読み始めた（でも読み終えていない）5年前からJavaの代わりにScalaを使うようになりました。最初はテストの時に使用していましたが、すぐにちょっとしたユーティリティクラスでも使用するようになり、気付いたらプロジェクト全てで使用するようになっていました。 Scalaに対する不満は多く存在しますが、この記事は違います。これは非難するものではなく、むしろ称賛するものです。 Scalaに興味ある開発者や聞いたことがあっても詳しく見たことがない人、「スムーズなプログラミングの妨げになる」と思い使用を先送りしていた人のために書きました。もちろんScalaファンに読んでもらうのも、他の人にも紹介してもらうのも大歓迎です。 この記事は3
品質の文脈でコメントの代わりのメソッド導入が安易に受け入れられない理由 - きしだのHatena
前提 目的は品質であり、品質のために読みやすさを求める。 メソッドを導入するとコードの複雑度はあがる。 コメントの記述ではコードの複雑度はあがらない。 コードの複雑度が高くなるとバグがでやすくなる。 バグがでやすくなると品質はさがる。 ここまでは今回前提とさせてもらいます。なので、ここで異論があれば、あぁそこに考え方の違いがあったのね、ということで。 目的が読みやすさであれば、まあそれで読みやすい人もいるんですねぇ、ということで終わらせることもできます。 ただ、このまえのエントリでは、品質がテーマです。 そういう前提では、読みやすいだけじゃなくて、品質を落とさないということも大事になります。 メソッドの導入は、基本的に複雑度をあげるので、それはそれでやりすぎるとバグの原因にもなっていきます。 もちろん、メソッドによって式や処理に名前をつけるというのは、複雑度をあげたことを補ってあまる効果が
コードに対してコメントを書くと実装に関するコメントになる - きしだのHatena
おととい、渋谷JVMというイベントがあって登壇させてもらったんですが、そのあとビール飲んでるときに、ぼくが「コード書く前にコメントだけ書くのいいよね」と言ったあとの返答としてきょんくん(kyon_mm)が言った言葉。 全体としては 「コード先に書いてそのコードに対してテストを書くと実装に対するテストになるし、コードを先に書いてそのコードに対してコメントを書くと実装に対するコメントになる」 という感じ。 ここに至るまでの話もおもしろかったんだけど、ここでは、コメントについて書いてみます。 まず、実装に対するコメントってどういうのかというと、こういうの。 id = findId(name); if(id == -1){ // idが-1だったとき登録 register(name); } いやそれはコード見ればわかるから、ってやつですね。 これは、こうやるとより適切です。 id = findId
バージョン管理したくない作業用スクリプトは「,」ディレクトリに入れるといい - Qiita
TL;DR: グローバルな gitignore に ,/ を追加して、作業用スクリプトを , ディレクトリに入れると便利。 ,/tmp_script.sh で実行できる。 Git リポジトリの中に一時的に使う作業用スクリプトを置いておきたいことがある。自分だけが使うものなのでコミットはしたくないが、いちいち .git/info/exclude に追加して無視させるのも面倒臭い。 今まで自分は、 tmp_script.sh~ や tmp_script.sh.bak など、グローバルな gitignore で無視されるファイル名にしていたが、これは不要なファイルと間違えて消してしまう危険がある。 ignored.tmp_script.sh は分かりやすいぶん長い。 _tmp_script.sh は悪くないが、コミットすべきファイルにもアンダースコアで始まるものがあって紛らわしい。 そこで、作業
gcov の使い方 - まめめも
concov のドキュメントを書こうと思ったけれど、何から書くか困ったので、とりあえずその前に gcov の使い方とはまりどころを書いてみます。 gcov とは C 言語で書かれたプログラムのカバレッジを測定するツールです。gcc に付属しています。 基本的な使い方 こういうコードがあるとする。 /* test.c */ #include <stdio.h> int foo(int x, int y) { return x + y; } int bar(int x, int y) { return x - y; } int main(void) { printf("%d\n", foo(2, 3)); printf("%d\n", foo(3, 4)); return 0; } コンパイルする。-coverage をつけると gcov 用のオブジェクトファイルが生成される *1 。 $ g
良いネーミングをするために覚えておきたい英語のルール5つ - プログラマー幸福論
Photo by muraterturk こういった記事って、ネーミング規則や慣習の視点から書かれていることが多いんですけど、この記事では、英文法に視点を置いて、参考になりそうなことをいくつかピックアップしてみたいと思います。 「省略形は使わない」などの規約的なものは、各プロジェクトのルールに従えばいいので、ここでは書きません。あくまで英語という視点から書いているということを、ご理解ください。 Rule 1 : “検索”は名詞 一般的な英語辞書のルールでは「検索」は、動詞ではなく「検索する」が動詞になります。「検索」は、検索することの名称 だと考えられるため、動詞ではなく名詞として扱います。 英語辞書には、日本語の品詞ごとに表記のルールがあります。これが理解できていると、和英辞書などで品詞を意識して検索できるようになります。以下に、一般的な英語辞書の表記ルールをまとめてみました。 ＜各品詞
Javaプログラマが知るべき9のこと - @katzchang.contexts
はじめに ソースコードは設計であり、コードの記述は品質に直結するのは言うまでもない。ちなみに、プログラマにとって特に重要なのは保守性だ。コードは書いた直後から保守対象となるからだ。コードは要求文書の範囲で動けばいいと思っている人がいれば今すぐ、ソースコードをコピペして100klに増えるプラグインがいつの間にかインストールされる呪いをかけてあげよう。幸い、ここを読んでいる人にはそんな人はいないだろうと思うけれども。 ということで、コードの品質を下げる要因、すなわちシステム全体の品質を下げる要因となり、かつ使われやすいアンチパターンを挙げ、対策を検討していくことにする。対象は以下： 出力パラメータ 処理状態返却 意味のある配列 無意味な初期化 多すぎるtry-catch 暗黙の順序 コンパイラ警告の無視 過剰なコメント e.printStackTrace() 出力パラメータ メソッドの引数にオ
RjpWiki - RjpWiki
RjpWiki はオープンソースの統計解析システム R に関する情報交換を目的とした Wiki ですRjpWiki はオープンソースの統計解析システム 《R》 に関する情報交換を目的とした Wiki です † どなたでも自由にページを追加・編集できます． (初めて投稿・既存記事への追加・修正を行なう方はこのページ末の注意*1を御覧下さい) ページへのファイル添付については、画像ファイルのみパスワードなしで可能としてあります(ページ上部「画像添付」より)。その他のファイルの添付はパスワードを入力することで可能です(ページ上部「ファイル添付」より)。現在のパスワードは, Rでの round(qt(0.2,df=8),3) の実行結果です。 スパム書き込みに対処するため、書き込み系の処理に対してパスワードを設けました。ユーザ名の欄には，Rで round(qt(0.2,df=8),3) を実行
ダメな技術書の見定め方 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 技術書を自分のお金で買うようになってから、かれこれ十数年。 ダメな技術書が放つ独特のニオイがやっとわかるようになってきたので、書いてみました。 以下、主観を多分に含みます。「あー、あるある」と思いながら軽く読んでくださいね。 (逆バージョンの「良書のみつけかた」は、近日公開予定でございます。) ダメな技術書の「あるある」 誤字・脱字が多い 推敲に時間を割いてないことの証拠である。よって誤字・脱字が多い本は技術書としてもクソ本である確率が高い。 正誤表・サポートページがない 多少の誤字・脱字は仕方がないとしても、それを Web で補う気す
誤った判定 - 学校では教えてくれないバッドノウハウ英語 #13 - bkブログ
誤った判定 - 学校では教えてくれないバッドノウハウ英語 #13 学校では教えてくれないバッドノウハウ英語の13回は、誤った判定（間違った判定）に関する表現を取り上げたいと思います。 スパムフィルタによるスパムの判定や、メモリチェックツールによるメモリリークの判定など、コンピュータの世界では、ソフトウェアを用いて何かを自動で判定することがよくあります。 ここで問題となるのが、誤った判定です。スパムフィルタの例で言えば、「本当はスパムじゃないのにスパムと判定された（大切なメールがスパムフォルダに行ってしまった）」と「本当はスパムなのにスパムじゃないメールとして判別された（スパムが受信箱に入ってきた）」という２つの場合があります。 英語では前者の場合を false positive、後者の場合を false negative と呼びます。日本語では偽陽性、偽陰性となりますが、基本的に医学用語な
ちょっと囓っただけの素人が自分を過信して陥る三つの罠？ - カレーなる辛口Javaな加齢日記
http://d.hatena.ne.jp/fromdusktildawn/20081026/p1 うーんと，30点．「もう少しがんばりましょう」レベル．*1 初心者が惑わされると可哀想なので，一応突っ込んどく． 「変数のスコープは狭いほど良い」という迷信 「同じロジックのコードを2度以上書くな」という迷信 「プログラミング言語を極めるのが大切」という迷信 一つ目は大原則．特にグローバル変数は最悪だ．言語によっては避けられないこともあるが，それはコーディング規約などでカバーするしかない． 二つ目も，ほとんどの場合は大原則．未熟なプログラマーには，何故か負担が大きすぎるらしいけど． 三つ目はケースバイケース．ほとんどの場合は言語も極めてない奴の方が多く，まずは「言語を極めろ」は概ね正解． なんだかなぁ。「先ずは使うことを覚えろ」「次に使わないことを覚えろ」「最後に使うか使わないか選ぶことを覚
中途半端に優秀なプログラマが「正しいプログラミングテクニック」だと妄信しがちな３つポイント - 分裂勘違い君劇場
「変数のスコープは狭いほど良い」と妄信する 変数でもメソッド名でもクラス名でも言えることだが、単純に「スコープは狭いほどよい」という方針でプログラムすると、逆に保守性も可読性も悪いプログラムができあがることがけっこうある*1。 実際、「あちこちから頻繁にアクセスするようなオブジェクトやメソッド」は、スコープをぐっと広くしてしまった方が(場合によってはグローバル変数やグローバル関数にしてしまった方が)、いちいちパラメータ渡しのバケツリレーをせずに、オブジェクトや機能を使うことができ、プログラムの可読性も保守性もずっと向上することがけっこうある。 たとえば、プログラムのいろいろな箇所から比較的頻繁にアクセスする必要があるようなオブジェクトや機能がバインド(格納)された変数やメソッドのスコープをクラスやメソッド内のローカルにして、それを使うときは、いちいち各クラスやメソッドにパラメータ渡しのチェ
プログラマの常識：変数と値 - 檜山正幸のキマイラ飼育記
プログラマの常識っぽいネタ。 「変数は入れ物で、値は中身」とか僕は説明するんですが、それほど単純でもないですね。 とりあえず即物的に、変数はメモリ内に確保された領域で、値はそこに格納されているビットコンビネーションと捉えましょう。プログラミング言語はたいてい型概念を持つ*1ので、値であるビットコンビネーションには高級な（たとえば整数としての）意味付けがされています。 変数は入れ物（実体は連続したメモリセル）なので先頭アドレスを考えることができますが、値自体にアドレスは考えにくい； 例えば整数変数xに値3が格納されているとき、xのアドレスは取れますが、3のアドレスって意味不明。-- と、そんなことを言ったりもします。が、これもアヤシイよね。 整数値3は、それ自身でアイデンティティを持つので、3が4に変わったりはしない（変わった結果はもはや3じゃない）のですが、「3をインクリメントしたら4」と
Scalaで<:<とか=:=を使ったgeneralized type constraintsがスゴすぎて感動した話 - ( ꒪⌓꒪) ゆるよろ日記
Scala2.8から、Predefに<:<とか=:=とかが定義されていて、これなんだろ?とずーっと疑問だった訳ですよ。で、ついったーで質問投げてたらやっと理解できました。 教えて頂いた @ScalaTohoku さん、@okomok さん、@tioa さん、有り難うございました! "generalized type constraints"というヤツで、型パラメータに与えられた型が、特定の条件を満たす場合にのみ呼び出せるメソッドを定義できるというものです。しかもコンパイル時に静的にチェックされる!! これはスゴい!! What do <:<, <%<, and =:= mean in Scala 2.8, and where are they documented? - Stack Overflow =:=や<:<や<%<で特定の型のみ呼び出せるメソッドを定義する 具体的な例で説明します。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
なるべく短い正規表現で住所を「都道府県/市区町村/それ以降」に分けるエクストリームスポーツ - Qiita
JavaScriptの「&&」「||」について盛大に勘違いをしていた件 - Qiita
JUnit4のassertThat()って便利なの？
