この記事は毎日書くということはできていませんので、結構時間がかかりそうな気がしますが、地道に進めて最後まで続けるのが一番でしょうか。
本当は毎日進めたいところですが、学生とはいえ色々あるので…
25 見られて恥ずかしいデータは使わないこと (ロッド・ベグビー, Rod Begbie)
なんだか見覚えがありますね。たまに見かける、プログラマの遊び心ですね。
確かに何かしら公と関わるコードに入っているデータは、何かの時に公にさらされることってよくあります。私はそういう遊び心が薄いので ( そしてそこまでジョークも上手くないので ) そういうことをあまりしたことがないのですが、そういうことで恥ずかしい思いをしたくないのであれば、出来る限りしないことですね。
見られて恥ずかしいという以上に、思いっきりさらしているようなBrainF**kなんてものもありますが…あれはジョークですからね。ここまであからさまにできる勇気があるなら、してもいいのかな？
しかしながら、顧客が関わるプロジェクトでやるべきではないと思います。特に日本はそういうことに厳しい環境ですからね。
26 言語だけでなく文化も学ぶ (アンダース・ノラス, Anders Noras)
プログラミング言語は様々あります。もちろん動的、静的、手続き型、オブジェクト指向、関数型など大きな区分けとしても色々ありますが、強みとなる部分というのもあります。
また、言語は生まれた背景も大きく異なっていたりするので、似たような言語でも背景にある文化は大きく異なったりします。
私は主にC++を使うことが多く、その他の言語は時と場合に応じてということが多いです。C++は古くから幅広く、また汎用的な言語として使われているために、使われる分野や企業などで大きく文化が異なっていたりします。
このうち、C++では複合語の単語の区切りとして"_"、またクラスや関数、変数を区別せずに命名している場合が多いです。
標準ライブラリの命名規則なので、それに合わせるという点ではとても良いと思うのですが理解しにくく、冗長になりやすいと思います。
そこで良いと思ったのがJavaの命名規則でした。キャメル記法を用い、クラスと変数の区別がしっかりと出来るように作られていて、より読みやすいコードを書けます。
そのため、私はよくJavaのこの命名規則に似た命名規則をC++でも用いていたりします。この辺りはC++を単に学んでいるだけだと意識しにくかったところでした。
27 死ぬはずのプログラムをムリに生かしておいてはいけない (ヴェリティ・ストブ, Verity Stob)
例外の処理の仕方というのは基本的に21個目のエッセイにあったように「技術的例外とビジネス例外」というのをしっかり区別して、技術的例外というのはトップレベルまで通過されるべきです。
「ユーザに対して例外の情報を見せるべきでない」というのは、どちらかと言えば「プログラマ側が、ユーザに対して例外を見せたくない」というほうが正しいのではないかと思います。
例外の情報を見せることで問題の解決が早まると思います。握りつぶす際には、発生するすべての「例外」がプログラマの中では「例外でない」状況でないといけないはずです。
どちらかと言えば、絶対に例外を見せないようにすることによって危険性を上げていると言えると思います。
最後に
見られて恥ずかしいデータを使わないというのは、今でもやってはいませんが、これからも続けていかないといけませんね。
新しい言語を勉強する際に、文化自体も勉強すべきというのは確かに感じました。思い起こしてみると文化を勉強することで学んだこともよくあることに気がつきました。
また例外に対しての対処については、例外処理で例外を作らないということが重要であると再度認識しました。
こういうことは認識はできているのですが、有名なプログラマの方々が同じように考えていると思うと、これからもしっかり忘れないようにしたいですね。
