くそコードが無くなる日を目指して

実例はC++/Javaがメインです|良いコードは健康を増進します

Category: ひとりごと

コード=読みやすくあるべきという観点で見ると、書く際に気をつけるべきは命名と分割という話。

命名を意識するというのは次のような感じです。
例えばこんなコードがあったとします。
String orange = "Apple"; // これは論外
String info = "Some Information";
前者はそもそも書いてあることと中身が違うので、混乱をきたすどころか、バグでも起きた日には迷宮入りしかねません。後者は、結局なんの情報?という部分が欠落しているので、読み手は中身が正しいのかどうか判定できません。(前後の文脈で判断を仰ぐのは、時間の無駄になるので適切ではありません)
一方で、命名がしっかりしていれば、細かなロジックがわからなくても何をしているのか理解できる(ここが重要)はずなので、命名はコードを書く際に意識すべき要素だといえます。

分割を意識するというのは次のような感じです。
次のコードを見てください
void eatBreakfast() {
    while () {
        〜
    }
    while () {
        〜
    }
}
eatBreakfastの中で2つの処理が混在しています。これでもいいのでは?という意見はあると思いますが、これでは、ぱっと見た時に、eatBreakfast(朝ごはんを食べる)が2つのwhileループからなることはわかりますが、それが一体何をしているのかはわかりません。
(じっくり読めばわかるんだと思いますが、それをさせるのは良いコードではありません)

なぜわかりにくいのかというと、朝ごはんを食べる処理にはいくつか分割できる要素がある(eatBreakfastは抽象度が高い)のですが、それがそのまま(抽象度が高いまま)になっているからです。
そこでeatBreakfastが、実際には、「パンを食べる」と「コーヒーを飲む」から構成されていたとするならば、
void eatBreakfast() {
    eatBread();
    drinkCoffee();
}
となります。明らかにわかりやすくなりました。

命名と分割 、ぜひ意識してコードを書いて見てください。

それでは、良いコード日和を 

自分だけなのかみんなもそうなのかわかりませんが、家にいると、コーディングがしたくないわけではないけど、かと言って特に作りたいものもないから、何もせず、あーでも何かしなきゃという妙な焦りだけがあって、ただ時間だけが過ぎてしまうことはないでしょうか?

そんなときに個人的におすすめなのが、コーディングスキルチェックサービスやいわゆる競技プログラミングのサイトにある問題を解くことです。

サイトはいろいろ有りますが、有名どころだと
コーディングスキルチェック:
CodeIQ
Paiza
競技プログラミング:
TopCoder
Codeforces
あたりがありますね。

おすすめは、PaizaとCodeforcesです。
Paizaは初心者でも解けるような問題(文字列の中からAの個数を数えるなど)から1時間以上かかる難しい物まであって、その日の時間的な余裕とバランスをとりながら楽しめる、CodeforcesはTopCodeに比べてサイトがシンプルでわかりやすいところが好きで、おすすめです。

解けたからといって、きれいなコードがかけるようにはあまりなれないかもしれませんが、
スピードと正確さが求められる中で、コードの品質も気にすることができれば、一歩先のレベルに行けるようになると思います。

是非、試してみてください。

それでは、良いコード日和を
 

ソースコードって難しいですよね。
極論いうとif, for, whileあたりがわかれば誰でも書き始められて、
最近はAndroidやiOSの登場で、初心者でも気軽に簡単にアプリを作れてしまう。
作れてしまうがゆえに、コードの見た目はとりあえず脇に置かれてしまう。
で、気づいたらぐちゃぐちゃ・・・。

あー、もどかしい。

そもそも綺麗なコードってどんな感じ?
自分のはどうなのだろう?
とif, for, whileの使い方を教えてくれたあのサイト、あの本たちは
そういうことは何も教えてくれなくて全然わからないこともよくあると思います。
綺麗に書くのは、スーパープログラマーじゃないとできない。とすら、思ってしまうこともあるかもしれません。

でも、実は綺麗なコードを書くには、知識も特別な技術も本質的には要りません。
相手に伝えようとしているかどうかという、心構えが一番重要です。

良いソースコードは、料理のレシピのようなものです(たぶん)。
たとえば:

A)メニュー
じゃがいもとたまねぎをきりつつ、おゆをわかしながら、にくをいためて、そのごきったじゃがいもとたまねぎをいため、いためたらわかしたおゆをいれてにじゅっぷんくらいにる、じゃがいもがにえたら、かれーるーをいれてあじをととのえてかんせい

B)カレーの作り方
-じゃがいもは皮をむき、一口大に切る
-たまねぎも皮をむき、スライスする
-フライパンに油をひき、肉を炒める
-肉に火が通ったら、切った野菜を入れ、中火で炒める
-玉ねぎがきつね色になるまで炒めたら、鍋にお湯をいれ、炒めた具を煮る
-じゃがいもに串が通るまで煮えたら、カレールーを入れる。
-ひと煮立ちさせたあと味を整えれば完成

なにが言いたいかはなんとなくわかりますよね?
AよりBのほうがわかりやすくないでしょうか?
それはきっと、
・Bはカレーの作り方と書いてあるから、最初からその後にどんなことが書いてあるか想像できる
・順番になっていて、それぞれの手順が分割されている。Aはぱっと見なんだかよくわからない。(ひらがなだし・・・)
・Bは細かい指示(きつねいろまでとか)が書いてあるので、間違えにくそう。Aはどこまで炒めれば良いのかよくわからないので、初めてだと???となりそう
・そもそもAは伝える気があんのかよ!
というところにあると思います。

ソースコードもこれと同じです。今、何を、どのように、どこまで、したいか、それを説明するように書かれているかどうか、それが綺麗なコードと俗にいうくそコードの差です。
意外と単純な気がしてこないでしょうか?

今まさにこれに気づき、意識し始めたあなたは、もう綺麗なコードを書くプログラマーの仲間入りです。

長くなってしまったので、実例は次の記事からお見せしたいとおもいます。

では、良いコード日和を!
 

↑このページのトップヘ