タグ

ハンガリアン記法に関するt-murachiのブックマーク (3)

  • 間違ったコードは間違って見えるようにする - The Joel on Software Translation Project

    Joel Spolsky / 青木靖 訳 2005年5月11日 水曜 私が最初の当の仕事をはじめたのは1983年9月に遡る。それはオラニムというイスラエルの大きな製パン工場で、16台の飛行機ほどもある巨大なオーブンで、毎晩10万個のパンが作られていた。 はじめて工場に入った時、そのあまりの汚さに信じられない思いだった。オーブンの側面は黄ばんでいるし、機械は錆びていて、そこらじゅうが油だらけだった。 「いつもこんなに汚いの?」と私は聞いてみた。 「なんだって? なんの話をしてるんだ?」とマネージャが答えた。「掃除したばかりだから、今が一番きれいな状態なんだ」 なんてこった。 毎朝の工場の清掃を何ヶ月か続けて、ようやく彼らの言っていたことが理解できるようになった。パン工場では、きれいというのは機械にパン生地が付いてないことを言うのだ。きれいというのは、ゴミ箱に発酵したパン生地が入ってないこと

    t-murachi
    t-murachi 2014/03/09
    久しぶりに読んだ。今読むと C++ の演算子オーバーロードが不用意に dis られてる気もしてなんだかなぁ… あと Perl の Taint mode がそこまでクレバーな仕組みじゃなかったことをも思うとどうにも…
  • キャメルケースよりスネークケースで。 - 偏見プログラマの語り!

    プログラムを書くとき、たいていは何らかの命名規則に従って識別子を書くわけですが、その種類はだいたい 2 つじゃないかと思います。 ・スネークケース:スペースをアンダースコアに置き換えた表現。( chocolate_pie, candle_cake, ... ) ・キャメルケース:スペースを詰めて次の語を大文字から始める表現。( chocolatePie, CandleCake, ... ) プログラムってのは名前が 8 割とか言うひともいますけども、なんだかんだと複合語を記述する場面は死ぬほどありますし、しかも多くのプログラミング言語がスペースをトークンの区切りとしている以上、何かルールを設けないといけないんですよね。そうしないと「複合語の中にあるスペース」と「トークン区切りとしてのスペース」を区別できない。区別できないっていうかプログラム書けない。 で、どういうルールで書くかっていうと標

    t-murachi
    t-murachi 2012/01/22
    型ハンガリアンは不必要なら避けるべきであって、それは言語や環境を跨いで共通の認識ではない。 C++ で定数名を UPPER_CASE で書くのが流行りじゃないのは、マクロと区別したいという要求があったから。
  • ハンガリアン記法考: 国民宿舎はらぺこ 大浴場

    物凄く久しぶりに一人っきりでワインとか飲んだら思いっきり酔いつぶれて 2、3 時間ほど眠ったらこんどは目が冴えてしまって眠れなくなっちゃったので、これまた久しぶりに枯れた話題について愚考を重ねてみようかと思う次第。 最近、とある友人 (「主に VB」なプログラマーさん) が、「変数名には必ず型がわかるような接頭子をつける記法に慣れている」というようなことをおっしゃるので、ハンガリアン記法を原則化するコーディングルールが好きでは無いおいらはちびっと反発してしまったわけなのですが、偏見の可能性もあるので今一度整理してみようかなぁとか思ってみたわけなのですよ。 結論から言えば、結局は case by case ということになるのだろう、ということなのですが、それだけだと有意義な情報とは言えないと思うので、どういう場面で使うと効果的かというのをさらっと列挙すると大体以下の通りになるんではないかと思

  • 1