クボブログ

https://toiro-skin.com

リーダブルコード(2/3)『コメントアウトとかその他諸々』

前回のブログの続きです。

前回は「リーダブルコード」という本の「命名」の内容について解説しましたが、今回はそれ以外の内容をまとめてみました。

 

 

 

コメントアウト

コメントアウトはすべき?

コメントの話をする前に本当にコメントアウトをする必要があるのかという問題が存在します。

コメントは意味の分からないコードをの意味を補足するためにつけます。

ですが、良いコードというのはコメントがなくえも意味が理解できるものです。

つまり、本当に良いコードを書けるならコメントアウトを書く必要がないのです。

だから、場合によってはコメントアウト自体が原則禁止の場合もあるでしょう。

それでも、適切なコードの書き方を知っていた場合、基本的には必要な情報は実際のコード内にほぼすべて抑えられるはずです。

それでも、コメントアウトをしないといけない場合は少なからず存在するのでそれについて解説します。

ーコメントすべき内容1:コードの欠陥や改善予定

プロジェクトの内容は基本的にプロジェクトが進行するごとにあぷうでーとしていきます。その過程でバグが発生することはよくあることです。

そのような区間を示すのにわざわざ他のツールを使ったり、プロジェクトでずっと使っていく変数名などに書き込むのはスマートな選択肢とは言えないです。

故に、このような場合はコメントアウトを利用することが推奨されてます。

ーコメントすべき内容2:定数にまつわる背景

定数を定義するときには、sの定数が何をするのか、なぜそのような値になるのかという「背景」が存在する場合が多いです。

例:IMAGE_QUALITY = 0.64;

この名前だと画像の品質が10000だということしかわからないが、この場合書きたいのはなぜこの「MAX_INPUT」の最大値がこの値なのかというものです。

ただ、経緯というものは実際の処理と関係ないものであるので実際に名前に書くことは基本的にしません。

ですが、そういう情報を記載したほうが良い場面は多々あります。

そのためそのような場合はコメントアウトをすることは推奨されることが多いです。

例:IMAGE_QUALITY = 0.64; // この値がユーザーが許容できる最低限の画質

コードの単純化

条件分岐はループ処理というものはプログラムを読む際に最もわかりにくい処理です。

故にそのような部分を単純化したコードを書くことは非常に重要です。

ー条件式

ーー条件式の引数の並び順

以下の二つの条件ではどちらの方が読みやすいでしょうか。

例1:if(length >= 10)

例2:if(10 <= length)

多くの場合は「例1」の条件の方が読みやすいと思うでしょう。

このように「a>b」が良いのか「b<a」が良いのかで迷うこともあると思います。

ただ、一般的には

 右側:検証対象

 左側:比較対象

という風に並べるのが一般的です。

ーー条件は否定形よりも肯定形を使う

以下の二つの条件ではどちらの方がわかりやすいでしょう。

例1:

[C++]

if(a==b){

    ....

}else{

    ....

}

例2:

[C++]

if(a!=b){

    ....

}else{

    ...

}

この例だと「例1」の方が一般的には読みやすいといわれてます。

つまり、否定形よりも肯定形の方が読みやすいということです。

ーード・モルガンの定理を利用する

次のような複雑な条件式はコードを読んでいく際、非常に煩わしいものです。

例1:

[C++]

if( !( !can_Save || !can_close) )

ですが、電気回路や論理学で「ド・モルガンの定理」というものを知っていれば以下のような分かりやすい等価条件に置き換えることができます。

例2:

[C++]

if( can_Save && can_Close )

これによりどちらの条件も真であるときに条件を満たすというわかりやすいものになります。

 

これに使ったとモルガンの公式は以下のようなものです。

(1):not ( A and B ) = not ( A ) or not ( B )

(2):not ( A or B ) = not ( A ) and not ( B )

この公式で条件式が簡単になる場合は非常に置いたので複雑な条件式を書いた場合は常にド・モルガンの定理で簡略できるのではないと疑うのは非常に大切

ーーその他のブール代数の公式

論理式を簡略化するのに使われる公式は多く存在しますので、その代表的なものを挙げていきます。

当然、先ほど話した「ド・モルガンの定理」もその一つです。

 

同一則:A ・ A = A

    A + A = A

 

恒等則:A ・ 1 = A

    A + 0 = A

 

公理 :A + 1 = 1

    A ・ 0 = 0

 

補元則:A+!(A) = 1

    A・!(A) = 0

 

二重否定: !( !( A ) ) = A

 

交換則:A・B =  B・A

    A+B = B+A

 

分配則:A・( B+C ) = A・B + A・B

    A+( B・C ) = ( A + B )( A + C )

    A・( A+B ) = A

    A+( A・C ) = A

 

ーdo/whileループを避ける

多くの言語にはdo/whileという書き方が存在する。

whileとdo/whileの違いは条件式が初めから偽の場合、while文では一度も実行されないのに対して、do/whileでは必ず一度は実行されるというものです。

このdo/whileによりコードを短く書くことも可能な為、使われることも多いです。

ただ、このdo/whileは条件式が下にあるので、あまり使うことが推奨されない書き方の一つでもあります。

コードというのは多くの場合、上から下へ読んでいくのでこのdo/whileのコードの場合、do/whileを2回読む必要がある。

それに、ループがどれだけ続くのかわかりにくいという問題があります。

do/whileの性質上、この1回は必ず実行するため、実際に最初は条件式が偽であったとしても、その実行の過程で真に変わる可能性があるためループを読むのが難しくなります。

このループの読みにくさは、continueが絡んでくるとその傾向がより顕著に表れてきます。

ー関数に複数のreturn文を使っても構わない

プログラムの勉強を始めたての人は関数にretrun文を複数個置くのは好ましくないという話をされることがあるかもしれません。

ですが、これは大きな間違いで関数を早く返すのは良いことで、多くの場合はそれが推奨されている。

ー悪名高きgoto

goto文は諸悪の根源という話をよく聞きます。

そもそもgoto文とは処理を指定の位置へと移動させる制御文で、「return」「break」「continue」などのジャンプ文の一種です。

このgoto文を利用するとプログラム内の様々な位置に処理が遷移されることになるため、処理の流れが追いづらくなり読みづらいコードを生んでしまうことにつながります。

このgoto文を濫用することによってコードが読みにくくなったプログラムのことをスパゲッティコードといいます。

スパゲティコードの恐ろしさを知れる問題がAOJにあるので気になる人は解いてみてください。

構造化プログラミング | プログラミング入門 | Aizu Online Judge

f:id:kubokubokun:20180521172514p:plain

ーネストの深さは闇の深さ

 ーーネストが抱える問題

ネストが深くなるとコードが複雑になり、把握するのが難しくなります。

ある程度の常識があれば、横スクロールしないと見えないコードになるということはないです。

ネストの構造を把握するには「条件」「範囲」という情報を脳内で処理する必要があります。

ネストが深くなると以上のような脳内で処理すべきする情報が増えていきます。

多くの人の場合は3重、多くても4重が人間の脳で処理できる限度の量だと思います。

 

疲れたので終了

とりあえず、軽くまとめてみましたが本の内容が濃いのでもうひと記事が必要そうです。

最初に分かりやすいプログラムならコメントアウトは要らないと書きましたが、正直これは極論で自分も実際にプログラム書くときは割とコメントアウトはいれる方なので文章を書いてるときにうなり声を上げなら書いていました。

正直、この話は一種の宗教戦争に近そうなので自分の信じる神様を信じれば良いと思います。

まとめた内容は初心者プログラマーが備忘録として作った内容なので、少しというよりかなり的外れなこと書いてると思います。

そういう部分を見つけましたら

twitterの僕のアカウントに指摘してもらえると書き直します。

勉強にもなるんでお願いします。

次回はスコープの話とかですかね?

ということで最後まで拝見ありがとうございました ノシ

 

参考文献:

 

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

 

 

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

 

 

e-words.jp

www.slideshare.net

mathtrain.jp

slidesplayer.net

 

www.hassy-blog.com

www.sejuku.net 

marycore.jp

qiita.com

qiita.com

qiita.com

qiita.com

hateda.hatenadiary.jp

よりよいソースコードはどっち?