よくわかりません

2006 | 10 |
2007 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 12 |
2008 | 02 | 07 | 10 |
2009 | 01 | 02 | 03 | 04 | 05 | 08 |
カテゴリー
 | 

2009-05-10

[]きれいなソースコードを書くために必要な、たったひとつの単純な事



「構造のきれいなプログラムを書けるようになるためにはどうすればいいのか?」という質問を受けたので、「はて?どうしているだろうか?」と考えてみました。あ、形式知にきちんとなっているようなテクニックみたいなもんじゃなくて、モノローグなので、あまり凝ったものは期待しないように。

http://blog.shibu.jp/article/28983162.html

自分なりにもっと凝縮版を。渋川さんが言っている事全体もその通りとは思うけど*1、もっと簡単で、しかも射程が広い、と自分が思っている事。


渋川さんはちょろっと触れてるだけだけど、自分はこれが最も基本的で汎用的、かつ、ソースをきれいにする原動力となる上にバグをも減らしてコードの汎用性まであげる、コーディングのエンジンみたいなものと思ってる。それは、


「すべてに正しい名前を付けて、そして、正しい名前であることを維持する」という鉄の意志


クラス、モジュール、メソッド・関数変数モジュール、クラス、インスタンス、ローカル、etc)など、プログラムで名前がつくものすべてについて、「正しい名前」を付ける。そして、「正しい名前」であることを維持する。維持するためには、コードの方を変える事も、名前の方をより正しい新たな名前に変える事も、どちらもやる。さらに、その言語では名前が付けられないような、ブロック、ループ、数行のコードの固まり、などなどにも、正しい名前を付けたがる姿勢まで含む。意志なんてヌルいものではなく、名前原理主義、名前パラノイア、などと言ってもいいかも知れない。


「正しい名前」とは、それが何なのかを、そのスコープにおいて的確に表現している名前のこと。「それは何?」を一言で言うには、その名前以外に言い様がないような名前。

それ自体は、至極シンプルな事。でも、それを徹底的に突き詰める事で、まったく単純ではない様々で莫大な効果得られ、ソースコードも必然的に綺麗になる。では、なんで「正しい名前」でソースコードが綺麗になるのか。


※本エントリに関連して、実践するために気を付ける事や考え方みたいのを書きました。よろしければこちらも。

 「そのソースコードが汚い理由:共通した根源的な間違い


「名前が正しければ、そりゃソースは読みやすくなる」 は違う

もちろんそれはそれで非常に大事な効果。意味がない名前や実態と合ってない名前が溢れてると、ソースを見ても、何をやってるか分からなかったり、勘違いを招く。それがなくなれば、ソースは大幅に読みやすくなる。大きなメリットであり非常に重要ではあるけど、それは効果のほんのごく一部に過ぎない。「正しい名前付け、正しい名前の維持」で生まれるのは、そんな当たり前の事だけではない。「正しい名前」を付けるために、コードの方も直すのだから。


「すべてに正しい名前」を求める意志は何を生むか

偉そうなことをいっておいて、実は全然整理されてないけど*2、思いつくところを順不同で挙げていく。抜けてる物・説明もたくさんあると思う。それぞれは完全に独立したものではなく、多分にオーバーラップしつつ、全体で上記に挙げたメリットに繋がる。


そのコード・その部分がやることが明確になる

たとえば、メソッドや関数。適当な名前で「なんとなく」で書き始めてなんとなく動いたら終わり、では、目的不明確でコードがヨレがち。ヨレてフラフラしたコードが綺麗な訳がない。その各部分(ブロックなりループなり、メソッド・関数内の数行の塊なり)に注目しても、単に不完全な断片にしかならない。


しかし、まじめに的確に名前を付けようとすれば、それが何をする物なのか明確に考えなくちゃならない。そして、明確になったら名前としていったん固定され、実装ではその固定された「やる事」をぶれずに書き下す。もちろん、実装中に名前の方が実は間違ってる事に気が付いたら、名前の方を直す。書き上がってからも、名前と実態が合ってるか、名前にそぐわぬコードが混ざってないか見直す。これにより、無駄やヨレがなくなり、コードは綺麗になり、バグも減る。


部分についても同様。実際に言語では名前を与えられなくても、各部分部分について的確な名前を考え、コードもそれに合わせるように直していけば、部分についてもやる事が明確になり、無駄・ヨレの排除でコードが綺麗になり、バグも減る。


クラスでもモジュールでも、話は同じ。


変数であっても同じ。その変数は何なのかきちんと考えて固定すれば、役割が明確になる。役割が明確なら、役割に合わない値を入れたり、役割と違った目的で値を使う事がなくなる。というか、なくす。もちろん、最初考えた役割の方が間違ってたら、正しい役割を表す名前に直して、その役割と使い方がすべて合ってるか見直す。これも、ヨレを無くし、バグを減らす。


「それは何なのか」が一貫する

適当な名前で何となく書かれた関数なりクラスなり変数なりは、曖昧がゆえに実装の部分部分や使われる場所によって、それがどういう物なのかが微妙にまたは大きく揺らぎが生じる。これもヨレや無駄、そしてバグの元。


一方、かならず的確な名前を付けるようにしていれば、その実装やその使い方がそこから外れる事が無くなる。実装や使い方が、その名の通りに一貫される。使い方を間違えない。


スコープが最適になる

なんとなく処理に必要な変数を用意して使っていると、それが必要な範囲も漠然としてしまう。


変数に最も的確な名前を考え、コード内の部分(ブロックなりループなり、メソッド・関数内の数行の塊なり)についても的確な名前を考えていくと、変数がその名前にふさわしい役割で必要とされている範囲がはっきりしてくる。そして、スコープで適切な名前にしようとすると、自然と本当に必要な範囲だけのスコープの変数になっていく。


スコープが最適になると言う事は、それが本来無用の場所でも間違って使われたり、読むときも無用に意識する必要がなくなるという事。ソースは綺麗になり、バグも減る。


プログラムが「とにかくそう動く」ではなく、意味レベルで整理・洗練される

そのコードが何なのか一貫した認識がなく、またそのコードで使ってる変数関数も何なのか曖昧だと、「ああなってこうなって…、えーと…、ウン、よし、動くな」と、動き中心でコードが書かれがち。それでは、何とかそのときは動くコードにはなるが、コードは洗練されない。


きちんと的確な名前を付けようとすると、動きでなく意味で考えざるを得なくなる。意味で考えて意味通りのコードにしようとすれば、コードはただ動くではなく、洗練の方向が明らかになるし、洗練させずには意味通りのコードにはならない。


コードの凝集度が上がる

そのコードが何なのか一貫した認識がなく意味レベルで整理されていなければ、「動く」という理由で、関係の深い物も浅い物もバラバラに配置されたままになる。


意味で考えられていて、コードを意味に合わせていれば、関係ある物はどうしたって集まってくるし、関係が浅い物は離れていって別メソッド・関数や別クラスなどに分離されていく。これはコードの凝集度が上がる事に他ならない。凝集度があがると、コードは綺麗だし、変更の影響範囲が狭い範囲に閉じるし、コードの依存事項も小さくなり、いい事づくめ。


設計が本当に必要な最適解に近付いていく

名前と実装の絶え間ない改善のスパイラルは、実装を書いてみて気が付いた大事な事を吸収しながら、ソースコードを明確な意味達の集まりに洗練していく。これはソースコードを、事前設計では得られない正しい設計に導く。


さらに、それぞれの意味が明確に名前で表されていれば、必要なものとのズレも見付けやすくなる。これによって、そのズレを直すべく設計をさらに洗練させる事になる。


複雑さが名前で表現できる範囲に押さえられる

名前は名前であり、それなりに簡潔であるべき物。簡潔な名前の意味にあったコードにするには、そもそもダラダラと長く複雑なコードではいられなくなる。長いコードは、その部分(ブロックなりループなり、関数内の数行の塊なり。あるいはメソッドの集まりであったり)についてもそれが何であるのか名前を付けようと意味を明確にしようと考える事で、部分の役割が明確になって、関数やクラスに独立させる事になる。


コードがシンプルになる

正しい名前にするために意味で整理して凝集度が上がることで、メソッド・関数なりクラスなりは小さな単位になっていく。これは、一つ一つの役割は小さくなり、小さな役割について意味を明確にしようとして、その明確な意味通りのコードにしようとすれば、それは自然に短くシンプルになる。


コードの矛盾・ズレ・間違いが排除される

使ってる物(変数・メソッド・関数・クラス、など)の正しい名前・意味が曖昧なままだと、使ってる物に何か変更が入ったときも、もともとの意味が曖昧なので使い方に矛盾・ズレ・間違いがあっても目立たない。


使ってる物の名前・意味が明確ならば、使い方の矛盾・ズレ・間違いは目立つし、かつ名前・意味を明確であり続けさせようとすると、そのような矛盾・ズレ・間違いは排除しない訳に行かない。


依存の少ない変更に強いコードになる

使ってる物(変数・メソッド・関数・クラス、など)や部分(ブロックなりループなり、関数内の数行の塊なり。あるいはメソッドの集まりであったり)の名前・意味が曖昧なまま整理されないと、それらが依存する(影響を受ける)ものも必要以上に増えた状態になる。そのため、別の部分を修正したときも、本来関係ないはずであっても影響を受けてしまいやすくなる。


的確な名前を考え意味で整理され無駄が無くなっていると、本当に必要な物だけが使われるので、関係ないものへの依存が無くなり、変更に強くなる。


コードの重複が排除される

その部分の名前・意味が曖昧で依存が広く塊も大きいと、似たような事をやるにもちょっとした違いのためにそれを利用できず、また部分的にはほとんどそのまんまでも、部分を切り出す事が困難になり、似たような別のコードを書かなくてはならなくなる。


明確な名前と意味で整理されたコードは、自然と凝集度が高く独立性が高い小さな単位(メソッド・関数、クラス、など)の集まりになる。役割が小さく意味が専門化させていくと、そもそも「似た処理」の本当の共通の性質部分そのものの意味になりやすい。「似た処理」が必要と思ったとき、その部分について本当に的確な意味として既に切り出されて専門化されている。


汎用な物が抽出され、それを利用する事で、コードがさらに簡潔になる

前項とほとんど同じだが、部分部分の小さな単位に的確な名前を付けて独立させると、それは小さく、そして元の場所のしがらみから離れて汎用的な物になる。そうやって汎用的な物がどんどん独立していき、そしてそれらの塊にも適切な名前を与えるべく専門の塊にしていくことで汎用性を持つライブラリが出来ていく。


そのようなライブラリを他からも使用する事で、コードは全体としてさらに簡潔に書きやすくなっていく。


一番大事なのは、常に正しい名前を求める意志であり、場合によっては必ずしもその通りの名前を付けなくてもいい

もちろん普通はその名前を付けた方がいい。いいけど、上記のメリットは正しい名前を求める意志・思考自体によるところが大きい。だから、言語でのお約束として、たとえば自明なレベルではループカウンタはi,j,k,...を使うなら実際のコードではそれを使ってもいいし、とにかく簡潔な名前を使う慣習の言語では、名前に若干の説明不足が生じても仕方ない*3*4


名前重要、超重要。そしてその先

ちゃんと名前を付けるってのは、基本と言えば余りに基本的な事。でもそれは、その一言ではとても尽くせない、広大な汎用性を持つ超重要事項。それに本気になればなるほど、それに見合ったご利益が得られる、と思う。


このエントリでは、一般的な「きれいな」ソースコードのための超絶最重要事項として正しい名前を挙げた。これは自分なんかが言わなくても、実践できてる人も多いかも知れない。そういう人は、もう一段上の「美しい」コードについて、ハッカー達の濃い思いをじっくり味わうのもよいかも知れない。「きれいな」と「美しい」の違いとかは、danさんが書いてくれる事を期待(→ なんとホントにdanさんがエントリ書いてくれました! 404 Blog Not Found:いい仕事をするためのたった一つの心得 - 「美しい」から「かっこいい」へ)。

ビューティフルコード
Brian Kernighan Jon Bentley まつもとゆきひろ
オライリージャパン
売り上げランキング: 101149


追記

コメントやブクマを見て、説明不足だったかもと思ったところを補足。

きれいな名前じゃなくて、「正しい」名前

重要なのは、しゃれた名前とか、縁起のいい名前とか、知的な名前とか、詩的な名前とか、かわいい名前とか、そういうのじゃない。ただ単に「それは何?」という事を考え抜き、コードに対して「そのまんま」な名前を考える。そして、名前そのまんまのようにコードを書き、そのまんまになるように直す。それだけ。センスがある人は(邪魔にならない限り)そう言う要素を混ぜてもいいかも知れないけど、必要なのはもっと愚直に考える事。


「それはどんなかんじ?」じゃなくて、「それは何?」

たとえば、手に負えないようなぐちゃぐちゃなソースに対して、"spagetti"なんて名前を付けても、まあ確かにある意味そのまんまかも知れないけど正しい名前じゃない。「中身がどう」じゃなくて「中身が何か」を表さなくては意味がない。


「こんなのに正しい名前なんて付けられない」じゃなくて、正しい名前を付けられるように整理して分割する

俗に「ひとつの関数・メソッドは、25行(1画面)以内」というプログラミングの格言がある。自分がプログラミングをまともに始めた頃は、そんな無茶なという認識だった。その頃は、それに一言で正しい名前なんて付けられないようなのを書いてた。でも、正しい名前を付ける事を強く意識して内容を一言で言える単位毎にまとめて整理・分割していくと、いつのまにか25行以上なんて関数・メソッドはごく例外的なものだけという状況になっていた。曖昧にダラダラ書いた関数・メソッドでは、正しい名前は付けられない。そこをうんうんムリに考えるんじゃなくて、関数・メソッドの方を整理して分ける。これは、クラスやモジュールでも同じ。いつの間にデカくなってきたクラスやモジュールは、「正しい名前であること」を維持できているか見直して、整理して分割して、正しい名前を付け直す。


名前そのものじゃなくて、正しい名前を付けられるソースにする事

大事なのはソースをよくする事であって、名前はそのきっかけや手掛かりに過ぎないとも言える。目的はソースを見やすくするだけじゃなくて、構造や設計を含めてきれいにする事だし。

役割がシンプルで単一なものになるように整理分割されてないと、一言でそのまんま言い表せる名前は付けられない。中身を一言でうまく言えないソースは、部分部分にそれぞれ正しい名前を付けられるように整理して正しい名前で分割する。これをしなければ、名前だけそこそこの物を考えても、「名前でソースをきれいに」としては全くの片手落ちで、前のエントリで書いた効果の多くが得られない。


「正しい名前」の実現は、ソースを書き換えてきれいにしていくための方法であり、考え方。漠然とソースを書き換えてもきれいになるとは限らない。だから羅針盤が必要。その羅針盤が、「正しい名前」と「名前通りのソース」を追い求める事。


「きれいなソース」は、リターンの大きい、時間の投資

正しい名前を考え、ソースもきちんと直すには、確かに時間はかかる。目の前の10行だか100行だかを、ただとりあえず動くだけのレベルで書くのに比べたら、余計に時間はかかる。その程度の規模で、動いたらもうメンテせずに棄ててしまうプログラムならば、こだわってもご利益に見合わないかもしれない。


しかし、たいていのプログラミングは、目の前の10行だか100行だかを書いて終わりじゃない。実際は、全体としてもっともっと沢山のコードを書き、そしてその後それをメンテナンスしなくてはいけない。そこで、「きれいなソース」のために投じた時間に、莫大な利子が付いて返ってくる。整理されてなくて、何やってるかも不明確で、ちょっと条件が変わると動かなくなるようなソースが一部分でもあると、それに関係するプログラムを書くときに何かにつけてあれやこれやの無駄な時間を食われる。それが一部分じゃなくて、大部分のソースがそんな状態だと、もはや手枷足枷目隠しをされてプログラミングするのと同じだ*5


そしてもうひとつ。きちんとそれが何かを徹底的に考え、徹底的にプログラムを整理する事は、こだわった分だけ、ほかならぬそのプログラマ自身のスキルを着実に向上させる。プログラムをただ書くのではなく、ちゃんと考えて整理するために仮にいまは10の時間が掛かっても、それをやった分、次は9の時間でそれができ、その次は8の時間で、というふうに、投資に必要な時間がどんどん短くなっていく。投資額は小さくなっていくが、リターンは減るどころかどんどん大きくなる。こんなにおいしい投資をしないのは、あなたの時間とあなたの誇りを自ら捨ててる事と同義ではないか。


-疑問・質問歓迎-

疑問・質問・その他、歓迎。米欄のほか、続きのエントリ「そのソースコードが汚い理由:共通した根源的な間違い - よくわかりません」の末尾で(求められてなくても勝手に)回答。

*1:ただし、引きこもりがきれいなコードをかけないということは全くないと私は思います

*2:なので、後で断り無く記事をブラッシュアップするかも。→実際ちょっと加筆修正してます(おもに、すこし「部分」を強調。あと設計にも触れた)。

*3:そういう場合は、長い「正しい名前」はコメントとして付しておくといいかも

*4:あと関数型言語とかだと、抽出したものが余りに抽象的でまんまの意味となる的確な名前を簡潔になんて付けようもなかったりするけど、そういう言語ではそう言う物は既に標準ライブラリに大抵入ってるし、大事なのはそう言う思考って事で

*5:恐ろしいのは、大なり小なり、プログラミングとはそう言うものだという認識がまかり通っている組織が往々にして存在する事。

trshugutrshugu 2009/05/11 18:43 object temp1;
int temp2;
temp1 = temp2.ToString();
とかやっちゃうもんねウヒヒ。

通りすがり通りすがり 2009/05/11 20:37 「(オレにとって)正しい名前」だと思う。自分にとっては
意味が統一されていて読みやすい「きれいなコード」だろうけど
きれいか否かを評価するのは「他人」だから。他人が見た時に
「きれいなコード」と感じるか否かは別問題だと思う。
自分がこのエントリーを呼んだ感想としては、多分感じない方に1票投じるよ。

c91131c91131 2009/05/11 22:29 r-westさん、あなたは何者さんでしょうか?
この手のエントリーは、正直、おなかいっぱいというか、役に立たないことばかりなので、期待せずに見たのですが、感動しました。
こういうのが今の若い人にはわからんのです。
「上の通りすがり氏は、自分勝手な汚いコードを書いてる」に1票。

r-westr-west 2009/05/11 23:29 >trshuguさん
そんな汚いコード、誰もメンテしてあげないんだからね、ウヒヒ。

>通りすがりさん
確かに、完全に客観的な「正しい名前」が必ずあり得るか、というのは自明ではないと思います。
しかし、まず、「それが何であるか」を徹底的に考えて、それを表すのに必要十分な情報を持つ名前を付けようとすれば、そこでは自分ではなくコードを中心に考えれば、自分の脳内にだけある事に依存しない客観的に正しい名前になっていくと思います。
そして、このエントリで挙げたメリットの多くは、出来るだけ(自分の脳内に依存しない)正しい名前に「拘る事」、その「拘る事」自体によってもたらされると考えています。そのメリットは、単に名前が正しくて読みやすい、という話に収まるレベルではないもっともっと大きく巨大なものだと考えており、そういうエントリにしたつもりでした。

>c91131さん
ありがとうございます。こんなに読んで頂いて、お褒めの言葉まで頂いて、ほんとに書いてよかったなぁと思います。

通りすがり通りすがり 2009/05/11 23:54 レスありがとうございます。エントリーを読んで他人から見た場合どう感じるかって点が見えてこなかった。一言で言うと自分本位な俺ルールに見えたのでコメントしました。レスを読んで納得しました。
特にコードを中心に考えるって言うのは素晴しいと思います。確かにコード中心で考えれば、他の人から見てもきれいなコードになる事は間違い無いと思います。

shuji_w6eshuji_w6e 2009/05/12 09:42 同意します。
名前をしっかりと定義しないと落ち着かなくて気持ち悪い、そんな所まで行き着くとベストですよね

いちいち 2009/05/12 09:58 私も名前にはこだわっていますのでとてもよく分かります。
でも自分の場合は名前にこだわると生産性が落ちますね。
なのでこだわり過ぎないようにしてます。
頭のいい人はすぐ「正しい名前」が浮かぶんでしょうけど・・・。

pigmentpigment 2009/05/12 10:18 企業から使い捨てにされても、無理な仕事を押し付けられても、努力が一般的に認められなくても、お金にならなくても「綺麗なコード」を書きたいという欲求はとても純粋で崇高だなぁ・・・と思う。
大抵の人は沢山の障害に会って、完遂出来ないんだけどね〜

なかにしなかにし 2009/05/12 23:03 目から鱗

pow360pow360 2009/05/13 02:45 もう一段の美しいコードについて。
それはアレですね。
無駄なコメントが極力ない、自然言語でかかれたようなプログラムのことですね(英語表記に近い)。
そんなコードを書くとアドレナリンが大量に溢れます(笑)

増田増田 2009/05/13 04:33 trshuguさんの temp1 と temp2 がテンポラリファイルなら、名前と実体にそれほど乖離は無いと思います。えーと、tempfile1 とか temp_file2 とかにしろと仰るかもしれませんが、とりあえずテンポラリファイルは temp1 でオッケーの前提で話をさせてください(個人的にはそう思います)。

上のコードは型付けされているので object と int に temp と命名するのは汚いと仰るかもしれませんが、例えば Perl のように型付けが弱い言語だとその変数がどの型を持つかはコードに依りますよね。(コードに依る、を「宣言で束縛されない」または「実行時に解決される」という意味で使ってます。宣言で束縛されないオブジェクトは型も決まりませんから名前が実体を表すかどうか一意では無いと考えてますが、その辺の異論はあると思います。)

use File::Temp qw/ tempfile tempdir /;
use File::Copy;
$temp1 = tempfile();
$temp2 = tempfile();
# 省略
copy(tmp1, temp2);

これだとちゃんとした名前が付いてるかはコードを見ないと分からないですよね。正しい名前かどうかがコードに依存してるということは、正しい名前を付けたか判断するにはコードを見て名前とコードが一致してるか判断できないといけないってことになりませんか?
だから正しい名前を付けたら…ということでしょうが、なんとなく話が単純化され過ぎてるような気がしたもので脊髄反射的にコメントしてしまいました。どうもすみません。

自分の経験からですが、ちゃんと名前を付けろと教えたらその人がきれいなコード書いてくれるとは思えません。
ちゃんと名前付けられないからきれいなコード書けない人は、正しい命名ができない訳で、正しい命名ができない人は正しい名前が何か判断できない訳で、それを判断するには言語とか仕様とかに対してそれなりの洞察が要る訳ですが、そこまで理解できる人ならたぶんきれいなコード書いてると思うのですけど。変数に変な名前付けてても。
なんか瑣末なこと書いてますでしょうか?自分でも少しそんな気がします。
でも命名することを銀の弾丸的に捉えてるところがどうにも納得できないのです。
昔ハンガリアン記法というのがありまして、変数名のプレフィクスを正しく付けることにより美しいコードが…

cheapcodecheapcode 2009/05/13 10:36 ハンガリアン記法はかなり誤解されたまま広まってます。
マイクロソフト式のハンガリアン記法(システムハンガリアン)ではなく、正しいハンガリアン記法(アプリケーションハンガリアン)を用いる事は、バグの少ないコードを書くという目的においてはかなり有用なんじゃないかと思います。
詳しい話はJoelSpolsky氏のブログ(日本語訳)を読んでみてください。

・間違ったコードは間違って見えるようにする|Joel on Software
http://local.joelonsoftware.com/mediawiki/index.php/%E9%96%93%E9%81%95%E3%81%A3%E3%81%9F%E3%82%B3%E3%83%BC%E3%83%89%E3%81%AF%E9%96%93%E9%81%95%E3%81%A3%E3%81%A6%E8%A6%8B%E3%81%88%E3%82%8B%E3%82%88%E3%81%86%E3%81%AB%E3%81%99%E3%82%8B

oboro-boroborooboro-boroboro 2009/05/14 05:45 自分も名前は大事だと思いますが(そんな記事を書きましたが)、
正しくあらねば、というのはちょっと固い感じがしますねえ。

名前を付ける過程が大切なのかと思いますが。

(ブログの作法が分からず、コメントが適切なのかが
分からないので、おかしな所があったらすみせん)

r-westr-west 2009/05/15 00:51 >shuji_w6eさん
ありがとうございます。ベストというか、どこでもそれが当たり前という風になったらいいなと思います。

>いちさん
その気持ちは判ります。追記にその辺の考えを書いてみました。

>pigmentさん
仰る通り現実には簡単ではないと思いますが、それが自分のためになり、本当は会社や顧客のためでもあるという信念を持ちつづけたいと思っています。

>なかにしさん
ありがとうございます。書いて良かったです。

>増田さん
前半はちょっとよく理解出来てないのですが、型の名前も当然名前であり、それを活かせるなら活かす事はよいことだと思います。活かしにくい場合は、簡潔で正しい名前というのがより難しくなる傾向はある思います。
後半については追記に書きました。それらを習得していくために名前を考える事がよい指針になると考えています。

>cheapcodeさん
「間違いが間違いに見える」というのは「正しい名前」とかなり近い考え方だと思います。私のハンガリアンに対する思いはそのご紹介のページにブコメを書いてあり、本エントリにTB頂いたhttp://d.hatena.ne.jp/kilrey/20090512#p1 にも賛同するのですが、ハンガリアンも「それは何」を表す方法のひとつであると思います。

>oboro-boroboroさん
まさに仰る通り、過程が非常に重要と思っています。その辺が上手く書けていなかったので、追記を書きました。

FujiwoFujiwo 2009/05/21 14:12 同意です。
名前付けは、分析、設計、実装などにおけるモデリングの根幹だと考えています。

だいぶ前ですが、http://www.atmarkit.co.jp/fdotnet/nagilemind/nagilemind01/nagilemind01_01.html

http://www.atmarkit.co.jp/fdotnet/nagilemind/nagilemind01/nagilemind01_05.html
あたりに名前付けの重要性を書きました。

FujiwoFujiwo 2009/05/21 14:15 ただ、『正しい名前に「拘る事」』って言い方はいけてないと思います。拘るのはよくないと思います。

m0r1m0r1 2009/09/26 18:14 来春社会人になる専門学生ですが、きれいなソースを書くにはどうすればいいのかを調べていたところ此処に辿り着きました。
此処に書いてある事は大変勉強になり今後に役立てたいと思います。

有難うございました

callingvientcallingvient 2010/05/24 12:52 ちょっと大げさかもしれませんが上半期最も心を動かされたのはこのエントリーかもしません。小手先の技術論を超えてもはや哲学ですね。名前はそのもののありようを定義する。ふと昔学んでいた記号論を思い出しました。すばらしい

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証

トラックバック - http://d.hatena.ne.jp/r-west/20090510/1241962864
 | 
最近のコメント
最近のトラックバック
ASUS Eee PC S101 EEEPCS101-BLACK (GRAPHITE) グラファイト EEEPCS101-BLK011X起動バカ速。 PFU Happy Hacking Keyboard Professional JP 墨 PD-KB420B一般社会では結局JIS。 NANAO FlexScan 20.1インチ 液晶ディスプレー  ブラック S2031W-HBK安くて縦横自在でナナオ。 後傾姿勢作業の楽さは異常。
プロフィール

r-west

r-west はてなダイアリープラス利用中

ぷろぐらまーわなびー。よくわからないまま書いてるメモ。オリジナルのコードはデフォでNYSLです。