プログラミングで変数名や関数名のネーミングに迷ったときに便利なカンニングペーパーまとめ
僕は、プログラムをする上で変数や関数に良い名前を付けるのはとても重要と考えています。 というのも、良い名前を付ければ、それだけでそのコードがしたいことの説明になり、コメントと同等の働きをすることもあるからです。 自分がちゃんとそれをできているのかはさておき、僕は普段から、できれば読みやすくて分かりやすい名前を付けたいと思っています。他の人も読むコードであれば、できればプログラムでよく使われるような単語を利用して書いた方がより分かりやすいです。 ただ、よい名前を考えるのって、ちょっと面倒くさいんですよね。僕はこれまで、英語の辞書を利用して、考えたりしていたのですが、「何か、プログラムでよく使われる単語をまとめたものはないか？」と探したら、ドンピシャのものがいくつかあったので、それらをまとめて以下で紹介します。 photo by Michael Coté codic codic – デベロッパ
不完全にしてかなり言葉足らずな比較プログラミング言語学 - 西尾泰和のはてなダイアリー
プログラミング言語は人が作ったもの。人は誤るもの。なので完璧なプログラミング言語は存在しない。 「人は誤るもの、しかし誤りに固執するのは馬鹿の所業だ。」(キケロ) プログラミング言語も、間違った設計をして、馬鹿でない人がそれを修正することの繰り返しで発展してきた。 というわけで言語間での設計判断の食い違いとか失敗した設計とかを収集中。一部抜粋して講義資料に入れるつもりなので他の事例をご存知でしたらぜひ情報をいただけるとありがたいです。 if(x = 0) C言語では代入が式であるためif(x == 0)のつもりでif(x = 0)と書いてしまい、常に偽になってしまう。 x = 0の値はint、条件式はboolでないといけないので型エラーだよ派: Java x = 0は式ではないので条件式に入れたら構文エラーだよ派: Python 条件式にx = 0をいれたらx == 0と解釈するよ派: H
非言語型プログラミング言語: 港区赤坂四畳半社長
きっと小説家がプログラムを書く事が少ないのでしょうが、それでもルーディ・ラッカーみたいな数学者兼プログラマ兼小説家みたいな人もいるので、作者が解らないというよりは読者がわからないからないのかもしれません。 僕が映画、マトリックスで最も驚いたのは、パンフレットにあった「オーストラリアのデザイナーが"日本人のプログラマは縦書きでコードを書くに違いない"という思い込みから、マトリックスは縦書きでカタカナ混じりの文字がキーデザインとして多用されることになった」という下りで、まずそんな発想がネイティブ縦書き文化人間には全くなかった訳で。そもそも最近、縦書きの文章ってあまり読んでない。 森鴎外や福沢諭吉が欧米に遅れをとるまいと、日本のローマ字教育と横書き文化を普及させたおかげで、コンピュータもなんとなく使えているわけですが、エジケンのLingrなんか、最近イランで大流行中らしく、もう読めやしない言語。
「構造化プログラミングに関する覚え書き」へと導いたもの | taro-nishinoの日記 | スラド
明けましておめでとうございます。 さて、私の周辺では、先日に書いた"Gotoは有用である"について、折角のMatt S. Trout氏の本文よりも、何故か不幸にも私の書いた訳注の方が話題になっています。 Linus氏はgoto有用論の他にも、C++をボロクソに貶したり、本当に愉快な人だと私は思います。ただ、C++を貶された時の反応として、海外は置いとくとして、日本の一部の人が余りにも井の中の蛙的な反応をしたように記憶しています。代表的な例は「Linusはオブジェクト指向が分からないからだ」というのがあります。私は思わず笑いました。Linus氏ほどの頭脳で分からないことが、極東の日本の貴方がたは分かっていると言わんばかりじゃないですか。一部にせよ、だから日本は駄目だと思いました。つまり、自己を客観視せず、実質的実力は無いのに一流家気取りなんですね。もっとはっきり言えば何様のつもりなんだと。ど
はてなブログ | 無料ブログを作成しよう
ネイルで使う材料で、DIY時の木割れやネジ跡を派手にしたらかわいい OSB合板でちょっとしたボックスをつくりました。 ビス止め下手すぎて木を割ったり穴あけすぎたりした場所に、好きな派手色の樹脂を詰めてパテ代わりにしてみました。 ちょっと某HAYっぽみ出て可愛かったので、自分用にメモです。 手順 塗装 派手色グミジェルで失敗部分…
Life is beautiful: ソフトウェアの仕様書は料理のレシピに似ている
先日、経済産業省向けの仕事をしている知り合いと食事をしたのだが、彼によると経済産業省の今の悩みは、「IT産業の階層化の弊害によっておこる下流のプログラマーの収入の低下」だそうである。「プライムベンダー」と呼ばれる「上流コンサルタント」たちがインドや中国にも仕事を発注できることを理由に、激しく値切り始めたために、今やわずか一人月３０万円というケースもあるという。 こんな話を聞くと本当に悲しくなる。まず第一に「プログラムを書く」という仕事は簡単な仕事ではない。数学的な頭を持っていないとかなり辛いし、基礎がしっかりと出来ていないとろくなソフトウェアは作れない。物価の安いインドや中国なら許せるが、米国よりも生活費の高い日本で一人月３０万円とはあまりにも低すぎる。 「彼らは下流のエンジニアで、詳細仕様書に従った通りのプログラムを書くだけの簡単な仕事をしているから給料が安い」という説明を聞いたことがあ
デザイン・パターンとは何か
先日のMVCの議論の際には、私自身いろいろと勉強させていただいたが、少し心配になったのは、「MVCの定義だって時代とともに変わる」「ウェブサービス用のMVCはSmalltalk時代のMVCとは異なるもの」「MVCなんか理解してなくてもアプリケーションが作れればいいじゃん」など、そもそも「MVCとは何か」どころか「デザイン・パターンとは何か」を理解していないんじゃないかと思われる発言が見られたこと。ということで、今日はデザイン・パターンについてひと言。 デザイン・パターンとは、（業界に蓄積されたノウハウに立脚した）何かを作る際の指針のこと。ソフトウェアに限らず、ものを作るときにはさまざまな（場合によってはお互いに矛盾する）要求条件や制約が課せられるわけだが、そんな時に過去にさまざまな事例を解決してきた先人の知恵を「パターン化」してノウハウとして身につけておけば、似たような事例に出会った時に効
プログラマーには、コーディングの生産性で10倍、コードレビューの速度では6倍もの能力差があるという
プログラマーの生産性をテーマにした有名な著書「ピープルウェア」には、最も優秀なプログラマと最低の成績のプログラマのあいだには約10倍にあたる生産性の違いがある、というデータが出てきます。 これは、1984年から1986年にかけて92社、延べ600人が参加したプログラミングコンテストのデータを分析した結果から導き出された結果で、課題として与えられたプログラミング作業の開始からコンパイル時のエラーを消すところ（第1チェックポイント）へ到達するまでにかかった時間を比べています。 グラフを見ても分かるように、最優秀者と最低者のあいだには作業時間にして約10倍のひらきがあります。また最優秀者は平均の約2.5倍の生産性だそうです。そして、COBOLやFortranのような旧世代のプログラミング言語と、PascalやCのような現代的なプログラミング言語でのコーディングでの生産性はほとんど同じであったそう
普通の人がプログラミングについて誤解してること - へだちの日記
腱鞘炎になっちゃったので、数日キーボード等にあまり触れないようにしてたんですけど、手を使わなければすぐ治るというものでもないらしいですね。諦めて文章やプログラムを書きはじめたんですが、我慢していた反動か、アホみたいにのめり込んでしまって、また手が痛くなってきました。 僕は「書く」ことが好きで、文章を書いたりプログラミングを書いたり、書くことばかりで生きてます。普通はこの２つを「書く」という一つの行為にまとめたりはしませんが、僕は案外似たようなものではないかと思ってます。プログラムは「プログラミング言語」で書かれ、日本語の文章は「日本語」で書かれますが、「言語という記号体系に従って頭の中にあるものを文字で表す」という点は同じだからです。 両者の大きな違いは「読者」で、普通の文章は「人間」が読むものですが、プログラムは「コンピュータ」が読むものです。というのは嘘で、実際にはプログラムは「人
エンジニアがミーティングを嫌う理由 – バイリンガルの独り言
エンジニアがミーティングを入れられる事を好まない事や、不機嫌になる事は英語圏や日本を問わず知られているかと思います。実質、私の周りにもこういった傾向がありますし、職人的に秀でてる方ほどこの傾向が強いと感じています。さて、これはなぜでしょうか？ 友人のtweetにPaul Grahamというプログラマ兼ベンチャーキャピタリスが書いた、Maker’s Schedule, Manager’s Scheduleという面白い記事へのリンクが貼られていたので、私なりに要約して紹介します。 二種類のスケジュール プログラマやライターがミーティングを嫌う理由は彼らが他の人間とは違う種類のスケジュールで働いているからであるとGraham氏は語っています。氏いわく、スケジュールには二種類あります。 Maker’s Schedule（物を作る者のスケジュール） Manager’s Schedule（管理する者の
記号でPolyglotプログラミング♪（RejectKaigi2009） | TAKESAKO @ Yet another Cybozu Labs
RubyKaigi2009の最終日に同じ場所で開催された別のイベント「RejectKaigi2009」にて 「はじめてのRuby1.9プログラミング」と題して、記号Polyglotプログラミングの話をしてきました。 3分という限られた時間でありましたが、貴重な発表の機会を与えてくださりありがとうございます。 取り急ぎプレゼンで披露した記号Polyglotのプログラムを公開しておきます。 ■ hello.pl （という名前ですが、Perlの他にRubyやJavaScriptでも実行できるプログラムです） "#{",$/*"}";%#=();$^_^=’?“;">)~${`&&@`{;:+`[[‘,$^_^=’/?")-=^{(=!".=.!,!)&&>’,$^_^=’`-+|{!?“*.((-+({:^(_^’,$^_=”^’+@$@&’^’^.@%@’.’$^_^"";’.$^_^"",’
ひどすぎるネーミング - idesaku blog
UKTKKNSHINF こういう名前の変数が出てくるのだが、意味わかる？ 答え：受付禁止情報 今読んでいるPL/SQLコードは本当にひどい出来なのだが、その中でもネーミングが群を抜いてひどすぎてむしろ笑えてくるので、ここでさらしてみたい。 先ほどの例でわかると思うが、悪しきネーミング習慣である子音母音抜きの嵐である。変数名だろうが関数名だろうがこのルールで命名されているので、暗号文を読んでいるような気分になる。 他には、例えばこんなのがある。 SKSI 作成 HNKN 変換 KKT 確定 CHKN 中間 DTM Datetime DTA Data こうして見ると、ktkrやwktkとなんら違いがない。 "作成"のような、比較的簡単に対応する英単語が見つかるものまで日本語子音母音抜きで書くという徹底ぶり。でも"情報"はINFだったりする統一感のなさ。そしてこれらが単独ならまだしも、複合して出
各言語におけるtrue/falseまとめ - 昼メシ物語
たとえば PHP で、 if ($hoge) { ... } とか書いてあったら、 $hoge がどんな値のときに if の中身が実行されるのか即答できますか。 こういう書き方は多くの言語で可能ですが、言語によって何が真で何が偽になるのかが異なるので、それぞれまとめてみました。 C言語 C言語には bool 型が無い。 0 （int） だけが偽となり、それ以外はすべて真となる。 NULL 定数は stddef.h で以下のように ((void*)0) と定義されているため、偽値として使える。 意見が分かれそうなところですが、個人的にはNULLを偽値として使用するは好きじゃないです。 #ifndef __cplsuplus #define NULL ((void*)0) #else #define NULL __null #endif C++ C++になると bool 型が出てくる。C と同
タイプ別プログラミング上達の指針 - 遥か彼方の彼方から
雑記 面倒くさがり屋病的なまでに面倒なことを嫌うと、プログラムが上手くなる同じ処理を書きたくないから関数を定義する変更作業が面倒だからオブジェクト指向を取り入れる中身を気にしたくないからカプセル化同じような設計を効率よくやりたいからデザインパターンを勉強面倒なことを解決するためにツール制作かえって面倒になると思ったらダメ。面倒なことをしないためには、どんなに面倒なことでもやってのけるという病的な精神がプログラマには大切。綺麗好き綺麗なプログラムは、よいプログラムであることが多い。何よりよいプログラムは綺麗。タブや括弧の位置を揃えて見た目を統一する同じ処理を何度も書かない１つのものは１つにまとめる（例えば変数の定義など）マジックナンバーはゴミだと思ってなるべく消すようにする適切な名前にこだわる美しい設計を意識するとにかく綺麗なプログラムを意識する。汚れが見えたらまず綺麗にする。人の汚いコード
プログラミング格言集
psychopathより。 金言、格言は古今東西いろいろあるのだが、ここではプログラミングに関する格言がまとめられていたので、抜粋して翻訳してみる。翻訳に間違い等があった場合は、コメント等で指摘してください。 We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil 私たちは、時間の約97%を占めるわずかな効率に関しては忘れるべきである: 時期尚早な最適化は諸悪の根源だ。 - C. A. R. Hoare Walking on water and developing software from a specification are easy if both are frozen 水の上を歩くのと、仕様に基い
プログラマーの開発速度は「はまる」時間の長さで決まる : 小野和俊のブログ
プログラミングを始めてから今日に至るまで、 様々なタイプのプログラマーと開発を共にしてきたが、 驚くべき速度で高い品質のソフトウェアを作り上げるプログラマーには、 一つ共通の特徴があるように思える。 それは、「はまる」時間が極端に短い、ということである。 風のプログラマー」を指向しており、開発速度を重要視している。 例えば平成14年未踏ソフトウェア創造事業「PICSY」では、 発表直前に知人でプロジェクトリーダーの鈴木健にレスキュー隊として呼ばれて 2,3日でGUI全般と、クライアント/サーバー通信部分の設計と実装を終わらせたのだが、 このときなどは、大体の要件を口頭で聞いた後は、 ほぼまったく手が止まらずコードを書き続ける感じで開発をしていた。 「はまる」時間の長さは開発速度に直結するわけだが、 プログラマーが「はまる」場合にはある程度の傾向があると思うので、 今日は「はまる」プログラマ
「オブジェクト指向は教えないでください」ってなんてよくわかった会社だろうか - きしだのはてな
よく分かってる会社だ。 次世代の基幹系オープンシステム開発に利用されるプログラミング言語は？ - forest book 先日、SIer の友人が新人研修の講師として Java を教えるというお話を聞きました。会社側からは「Java を教えるのではなく、"プログラミング" を教えてほしい。オブジェクト指向は教えないでください。」との指示を受けたそうです。 プログラミングにおいて、現場での「オブジェクト指向」の優先度が低いってことですよね。 そして、理論的にも優先度は低い。アルゴリズムとか関数的ななにかとかをちゃんと扱えるようになるのが先決ですね。 関数+制御構造がやはり基本だし、その範囲がちゃんと扱えないで「オブジェクト指向」がちゃんと活用できるとは思えないし。 ただ、そうしようとしてもJavaではオブジェクト指向のための構文を知らざるを得ないので、その範囲のオブジェクト指向の知識は必要に
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
はてなブログ | 無料ブログを作成しよう
はてなブログ | 無料ブログを作成しよう
PHPで変数の値を入れ替えるTips - y-kawazの日記
