2020-06-22

きれいなコードを書こう5

今日もがんばるぞ！今日は4章から。

…一応、元ネタの本のリンクをちゃんと貼っておこう。絶対見つからないとは思うけど、万一があるから・・・
www.oreilly.co.jp

前回までのまとめ

第三章は「誤解されない名前をつけよう」という話だった。
・包含/排他的範囲にはbeginとendを使う
閾値を含むか含まないか、といった命名には困ることがあると思うが、とりあえずbeginとendを使っておこうな！
・ブール値の名前
ブール値を格納する変数の名前は、格納するtrue/falseの値が何のためのものか分かるようにしてあげること。
Check_〇〇ではなく、need_Check〇〇で「チェックが必要ならtrue入れてね」、checked_Bool_〇〇で「チェックした結果が入ってます」、といった書き分けを。
・ユーザの期待に合わせる
「期待」というか「予想」というべきか。めちゃくちゃ簡単な処理するっぽいメソッド名なのに、異様にメモリ食うような中身にしたらダメよという話。
一般的に「この名前ならこう動くんだろうな」っていう予想を悪い意味で裏切るのはやめよう。
・複数の名前を検討する
名前を考えるときは、「本当にその名前がベストか？」を考えていくつかの候補から最善策を選ぼう。templateだったら「あくまでtemplateだからこれは使わないってことなのかな・・・？」「templateをお手本として、継承したものを使用するんだぞ」という意味か、解釈が複数存在してしまうので、defaultとかinheritとかの名前も検討しよう。

最善の名前とは「誤解されない名前」だ。しっかり吟味していこう。
二章では「抽象的な名前ではなく具体的な名前を使おう」という話だった。同じテーマの本なので当然だが、どちらも「意味が可能な限り一意になる名前をつけていこうね」という言葉にまとめられると思う。

第四章「美しさ」

ここまでがコードの「中身」の分かりやすさに着目したものとするなら、この章では「見た目」の話に移行していると言える。

なぜ美しさが大切なのか？

はっきり言えば、「その方が理解しやすいから」だ。中身を読んで初めて秩序がつかめるより、パッと見た瞬間の印象で秩序を感じられるほうが理解しやすい。
public変数とprivate変数が入り乱れて定義されていたり、インデントがずれていたりすると、見た目だけで読みたくなるし、理解の障壁となる。

一貫性のある簡潔な改行位置

三つのインスタンスを作るとする。

ConnectDataBase JuneReservation = new ConnectDataBase("192.***.***.1", 5000, "2020/06/22");
ConnectDataBase OctoverReservation = 
    new ConnectDataBase("192.***.***.125", 15000, "2020/10/05");
ConnectDataBase AugustReservation =
    new ConnectDataBase("192.***.***.255", 11000, "2020/08/31");

こんな感じで。
コーディング規定で「一行〇文字まで」っていうのが決められていて第二引数の桁数で改行が入ってしまったという設定。
書き方は間違っていない（よね？）が、ぱっと見のレイアウトが異なるので理解しにくい。

ConnectDataBase JuneReservation = 
    new ConnectDataBase("192.***.***.1"  , 5000 , "2020/06/22");

ConnectDataBase OctoverReservation = 
    new ConnectDataBase("192.***.***.125", 15000, "2020/10/05");

ConnectDataBase AugustReservation =
    new ConnectDataBase("192.***.***.255", 11000, "2020/08/31");

こんな感じ・・・？
はてぶろ上だとレイアウトがエディタと違うのであくまでイメージとして。。。

メソッドを使った整列

引き続きレイアウトの話になるが、再現が困難なので言葉で書く。
同じような処理が複数行にわたって続いているなら、メソッドにして切り出し、本来そこでやりたい処理だけがスパッと分かるようにしてあげるべき。メソッド化のメリットを語っているところなので、まあオブジェクト指向の話とも言えるのだが、やはり見た目を分かりやすくするうえでもこの辺は大事ということなのだろう。

縦の線をまっすぐにする

インデントや、同様の処理の最初の文字の位置などを揃えてあげる。これにより、タイプミスが検出しやすくなるし、ループ系の処理ならその終端が分かりやすくなり、コードを理解する一助になる。
「似ているコードは似ているように見せる」と書いてあった。「読めば分かるでしょ」ではなく、とにかく視覚的に分かりやすく書くことを意識したい。

一貫性と意味のある並び

複数の変数を定義するときと、それらを呼び出すときとで並び順が変わっていると、抜け漏れが発生していることに気が付きにくくなる。また、「この順番で処理しないと動かないってことかな？」と言った勘繰りを生むきっかけになってしまう（本当にそうなら、定義順を変えるべきだ）。
思いついたままに書くだけでなく、後から見直して自分でも引っ掛かるところは修正しよう。

今日はここまで

コメントが短いので雑になってきた感があるが、本書の方もコード実例で紹介している部分が多いので表現しにくい・・・実際のコーディングで自分の手になじませていこう

2020-06-21

きれいなコードを書く4

やるぞ。

前回のまとめ

第三章　誤解されない名前
解釈が分かれる可能性がある名前は徹底的に排除していこうな、という話。
・filter()
フィルターをかけた結果、閾値のどっち側が残るのか分かる名前にしたほうがいいね
・Clip()
これも同じで、閾値「までを」クリッピングするのか、閾値「より小さい」ところをクリッピングするのか分かるようにしたいね
・限界値を含めるときはminとmaxを使う
「1~10番目まで〇〇する」みたいな場合、10を格納する変数（定数）はMAX_LENGTHみたいにMAXをつけよう。これも以上か未満か、の時に困らないため。
最小値の場合も同様にMINをつけてあげような。
・範囲を指定するときはfirstとlastを使う
これもminとmaxと同じ。

二章をまとめると、「中身が分かりやすくなるように具体的な単語を使っていこうな」って話でした。
三章では「中身分かるように気を利かせたつもりでも、解釈が複数存在するかどうか気を遣おうな、って内容。

包含/排他的範囲にはbeginとendを使う

この節、少し引っ掛かったので丁寧めにかく。
6月21日の間に発生したログをファイル出力する、というメソッドを作ったとする。
メソッドの呼び出し時に、引数を
ExportLog("Jun 21 12:00am","Jun 21 11:59pm")
とさせるのはちょっとややこしくて嫌なので
ExportLog("Jun 21 12:00am","Jun 22 12:00am")
みたいに呼び出せるように作ったとする。つまり「排他的範囲指定」をするように作ったわけだ。
このメソッドを定義する際の『仮引数』をどうしましょうかという話。
結論から言うと、包含でも排他でもbeginとendを使うのがベターらしい。英語ではendが排他・包含どちらにも使えるからしゃーない、という話だった。

ぶっちゃけ「結論出ないならこの説明いります？」と思ったが、「結論が出ない」という結論を知っておくことで無駄に考える時間が省けるということだろう。

ブール値の名前

trueとfalseを格納する変数は絶対と言っていいほど出てくると思うが、これに意味を設定しようという話。
例えば、check_DBConnectみたいなbool値を格納する変数があったとする。
これが「trueのときチェックを実行する」のか、「DBへの接続状態をチェックした結果」が入っているのか、ぱっと見では分からない。
前者であれば、needCheckingDBConnectとかにして、後者ならDBConnectingStatusとかにしたほうが幾分分かりやすい。

また、変数名に否定形を使うと一回脳内で逆に変換しなきゃいけないので辞めたほうがいい。
DisconnectingDBStatusだったら「『DBに接続してない』が『false』だからDBに接続『してる』ってことか！」みたいなね。
やめよう。脳は必要最低限しか使わないようにしよう。

ユーザの期待に合わせる

これは「プログラマの一般認識」から逸脱するな的な話なので、一般認識が無い自分だとよくわからない話だった。
例として、getCsvData()みたいにしてたら、csvファイルを「単体で」読み込むと思ってしまうので
このメソッドに「特定フォルダ配下のcsvファイルすべてを読み込み、一列目の値がAのもののみ引っこ抜く」みたいにすると想像以上に処理に時間がかかるのでやめとこうな、といった感じ。
初見で「ああこう動くんだろうな」っていう印象から逸脱するようなことを書くな、という話。

複数の名前を検討する

「ここまでの話全部これじゃね？」って感じがするが、名前を考えるときにはいくつかの候補を上げようという内容だ。
上がっていた実例を自分風にアレンジするとこうなる。

実行した端末が接続しているプリンタ情報を出力するメソッドを作ったとする。
ExportPrinterInfo(filePathToExport)
みたいな感じで。出力先のフォーマットによって、別々のファイルパスを定数に格納していたとする。
EXPORT_FILE_TEMPLATE = "c:\~~";
EXPORT_FILE_NUM1 = "d:/~~"
みたいな・・・ちょっと設定苦しいけど・・・

で、このとき「Templateがデフォルトで使うやつ」なのか、「Templateに設定されたパスをお手本にして他の設定値も書いてね」的な意味のTemplateなのか分からんじゃん、みたいな…
こういうのを防ぐためにいろんな名前を考えましょうね、ということらしい。

今日はここまで

本の内容を丸パクリすると申し訳ないし、何かしらで罰せられるかもしれないので自己流に変更して書いていることが多いのだが、
今回みたいに「プログラマあるある」が基になっていると例を考えるのに苦労するな・・・
さておき、第四章では「美しさ」の話に入る。何かを設計する人って手法に対して「美しくない」みたいなこと言うよね。あれなんなのって思ってたけど、次で分かるかな？

2020-06-20

きれいなコードを書こう3

やるぞ。

前回までのまとめ

第二章は「名前に情報を詰め込む」という内容だった。
・明確な単語を選ぶ
getとかじゃなくdownloadとか、対象や目的が推測しやすい言葉を使う。
sizeじゃなくHeightやMemoryBytesとか中身が分かるようにする
・汎用的な名前を避ける
retvalじゃなくてexamScoreとかね。
ただし寿命が長くないものはtmpとかでもいい。
大事なのは理由もなく汎用的な名前を使わないということ。
・具体的な名前を使う
メソッド名であれば「それが何をするものか」がはっきりわかるようにしてあげたほうがいい。
SaveDatabaseでなくKickCheaterとか。あと、複数の機能を持たせた結果、名前に関係ない概念の動作が入るくらいなら分離してやること。
サッカーゲームでKickBallにヘディングやスローイン機能がくっつくくらいならHeadingBallとかThrowBallにしたほうが分かりやすい。
・名前に情報を詰め込む
変数に計測可能な値を突っ込むならその単位を書くといい。timeForWaitならtimeForWait_msみたいな。
もう一つの観点として、危険や注意を喚起する情報を名前に入れることが挙げられていた。
・名前の長さを決める
長い名前が問題ではなく、無意味に長いことが問題。
無くてもいい情報は名前から省く。スコープが小さいならすぐ辿れるので長い名前にしなくていい。略称は一般的なものだけ使うようにする。
・名前のフォーマットで情報を伝える
フォーマット規則をチームで共有しておけば、名前からその実体を特定できる。アンダーバーや大文字、小文字など。
言語によって使えるフォーマットは変わると思うが、大事なのはプロジェクトで一貫性を持たせることだ。

第三章　誤解されない名前

はい、まとめが長くなったが、ここからは新しい内容だ。
名前が違う意味に勘違いされないかをよく考えましょうね、という章らしい。
具体例が色々載っているので、「禁止ワード」くらいの感じで覚えていきたい。

filter()

「フィルターした結果なにがでてくるの？？？」っていうね。
filter("Hz <= 800Hz"）みたいなやつだったら800Hz以上がフィルターされるのか、800Hz以上をフィルターするのか分からん。
Select()だったら800Hz以下をフィルターするんですね～って分かる。
微妙な差だし、「分かんだろ！」ってなりそうだけど、この『きっと』伝わるみたいな不確定要素を徹底的に探す、というのがこの章の要点だ。

Clip(text,length)

はい。テキストの「始めから」何文字か、「終わりから」何文字か分からんていうことやね。
あと、lengthもmax_lengthとかの方がいいよね。

限界値を含めるときはminとmaxを使う

「何文字以上の入力禁止」とかの制約がある場合、上限値をLENGTH_LIMITにしていたら
enterChar <= LENGTH_LIMITとするのか
enterChar < LENGTH_LIMITとするのかが分からない。
こういう場合はMAX_LENGTH_LIMITとしてあげれば「ああ、最大でそこまでなんですね」と分かるので書き間違えなくて済む
enterChar <= MAX_LENGTH_LIMITが正解だ。

範囲を指定するときはfirstとlastを使う

上述の「範囲」に関する命名時の工夫は他にも手段がある。
配列の1~10番目までを対象に何かをする場合、startNum=1, stopNum=10とすると
ループ処理において10になったらやめればいいのか、10までやるのかが分かりにくい。
ということでfirstNum = 1, lastNum=10とすれば10が最後の要素だと分かる。

一端ここまで

ちょっと他にも一本ブログを書いたので疲れてきた。
脳のキャパ的に一度ここで止めておく。

2020-06-20

求人広告代理店出身の僕が人事担当者に教えたい広告作成のコツ

求人広告のコツ

僕は新卒で求人広告の代理店に入った。ブラックだったので二年で辞めたけど、ブラックだったからこそたった二年にしてはいろんなノウハウを学んだ。
せっかくだからそのときの学びを記録しておきたい。曲がりなりにも一応広告に関わっていたので、広告の見方も変わった。その辺について書いてみる。

はじめに：（少なくとも求人の）広告は理詰めで作られている

一番大事なことだから初めに書くが、広告に「なんとなくよさそう」で書かれている文章なんてマジで一文もない。
もしあなたが企業の採用担当で、広告代理店の営業担当者に「この文章はどうしてこうなってるんですか」と聞いて具体的な答えが返ってこなかったら、その営業とは縁を切るべきだ。
求人広告は多くの場合、記載できる文字数の上限が決められている。冷静に考えて、曲がりなりにも従業員を抱えて必死に金を稼いでいる企業のことを300文字だの600文字だので完全に説明できるはずがない。
企業が持つ魅力（あるいはそのポテンシャル）を慎重に選び取り、採用したい人物に向けて的確に表現しなければならない。遊びが介入する余地なんてガチのマジで一ミリもない。

「おふざけ」さえも理詰めで作っている

「でもウケ狙いの広告だってあるじゃん」という声も聞こえそうだが、それすらめちゃくちゃ真剣に考えて絞り出したユーモアだ。間違いない。
ウケ狙いの広告を出すのはどんな業界か？不動産、業種問わず若いベンチャー企業、ブルーワーク系…そんなところだと思う。
彼らが「おふざけ」をやるのは、「おふざけが好きな人間が欲しいから」だ。金に余裕があるから一発カマしてるわけでは絶対にない。
こと求人広告に関しては、ターゲットの人物像に突き刺すための文言を選んでいる。つまりターゲットから言葉が出てくるのであって、広告の作り手から言葉が出てくるわけではない。この辺は後述する。

ここまで断言できるのは、「求人広告を作っているのは『天才クリエイター』では絶対にないから」だ。
確かに、マーケティングとかしなくても商品の魅力を伝えたり、人心を掌握するようなデザインを直感で作れるナチュラルボーンの天才クリエイターは存在する。
だが、そんな人材を電通や博報堂、その他デザイン事務所が放っておくだろうか？そうした人たちがわざわざ「求人」の分野で力を発揮しようと思うだろうか？
求人広告を作るのは、「広告業界の一線で戦えない人たち」だ。ここに異論をはさまないでほしい。一応言っておくが、僕ももちろんこの凡夫側の人間だ。だから辞めたんだしね。

さて、そんな凡人が効果の出る広告を作るにはどうするか。
天才が作った画期的な広告を分析し、その効果がどのように生み出されるかを一般化し、模倣する。これしかないのだ。
そういうわけで、冒頭の主張に戻る。「求人広告は理詰めで作られている」。
逆に言えば、どんなに才能がなくても「理詰めで考えれば求人広告は作れる」ということでもある。
企業の採用担当の方におかれましては、この点をしっかり押さえて業務に臨んでいただきたいものである。

ぶっちゃけ前の企業でもこういった話はお客さんにしていたが、自分もそういった凡夫の集積地にいる以上は声高に話せないこともたくさんあった。
今はまったく関係ない仕事をしているので思う存分こういう話ができる。今後、勉強の息抜きにこのシリーズを続けていきたいと思うので、たまに見てもらえれば幸いです。
他の技術系の勉強過程は一ミリも皆さんの役に立たないので読まなくていいです。

2020-06-20

きれいなコードを書こう2

昨日の続きから。
軽く振り返っておこう。

前回までのまとめ

・コードは「短く書く」のではなく「理解する時間が短くなるように書く」が大原則
・明確な単語を選ぶ
できるだけ具体的な情報を組み込んだ名前を付けよう。例）getは抽象的過ぎ→downloadとかにする
・汎用的な名前を避ける
retval(return value)では何が返ってくるのか分からない。意味を含ませること。例）retval→sum_examscore
※寿命の短い（数行さかのぼれば分かるもの）は別にいい。tmpとか。
要するに意味もなく中身が推測できなくなるような命名をするなということ。

余談だが、僕が高校三年生の時に化学を担当してくれた先生は、毎回授業の最初に「前回のまとめ」を生徒自身に口頭で述べさせていた。
これめっちゃ利くのでおすすめ。ちなみに僕は50分授業のうち45分寝ていたため目の敵にされていた。（一か月くらい経ってから卒業まで、最初から最後まで自主的に立ったまま授業を受けた。）

さて、ここからは今回のまとめだ。

抽象的な名前よりも具体的な名前を使う

職場で書いたコードではメソッド名にReadIni()みたいなのを使っていた。
あ～iniファイルを読むんですね～ってなるけど、「型は？」「何の情報？」「対象のiniは？」みたいな情報が分からない。
より具体的にするならReadFTPSvrNameIni()（FTPサーバ名を取ってくる）とかの方がいい…っていうことが本に書いてあった。（解釈が正しいかは分からない）

もう一つ、本には「直行する概念は無理に一つにまとめようとせずに、別々に使えるようにするといい」と書いてあった。
例として、「あるオプションコマンドにデバッグ情報を印字する（ログ出し）機能と、ローカル用のデータベースを設定する機能を持たせようとしたら？こういうときは命名の軸がぶれてしまうのでオプションは二つに分けよう」というようなことが書いてあった。
「一つにまとめると便利っぽいけど、意味が分からなくなったら元も子もない。それなら分けて、意味がぱっと分かるようにしよう」という話だ。なんかこう、オブジェクト指向っぽいですね（わかってない）

接尾辞や接頭辞を使って情報を追加する

ここには「名前にどんな情報を追加するか」という例が紹介されていた。

1. 単位
ミリ秒ならms、バイト数ならbyteとかね。

2. その他の重要な属性
例えばパスワードなら暗号化されているかどうかは重要なポイントになる。
passwordという変数名よりplaintext_passwordとかの方が扱いが分かりやすい。
文字コードがutf8のhtmlならhtmlよりhtml_utf8の方がいい。

このようにサブ情報的なものを追加することはコードの理解を速くする助けになる。

名前の長さを決める

なっげ～名前は嫌われるけど、それは「入力しにくいから」じゃない。今は単語補完機能はほとんどの開発環境に実装されている。
問題は「不必要に」長いやつだ。じゃあその必要性はどう判断すればいいのか？
スコープが一つの判断基準になる。たとえば一つのループ処理やif文の分岐処理内で定義された変数であれば、内容を把握しやすいのでクソ短くても大丈夫だ。

if ( dayOfTheWeek == "Friday"){
    string n;
    n = SearchTokyoTorikizoku();
    console.writeline(n);
}

めちゃ適当だがこれだったら「ああ、鳥貴族の店舗名かなんかが格納されるんだな」みたいになるので別に問題ない。（ないか？）
だが、このnがグローバル変数だったら他のどこで呼ばれるか分からんし、格納するのが店名なのか店番号（int）なのかとかが分からないのでもうちょっと長い名前で定義したほうがいい。
スコープ範囲＝未知との遭遇率と考えて、未知度合いをコントロールする。

さて、一方でイミフな短いやつもある。
以前見たやつだと「CV」とかね。csv valueのことだった。イミフ。
省略していいのは業界の共通認識のものだけだ。stringならstr、documentならdocみたいな。
当たり前のように外界に独自の略語をまき散らしていいのは女子高生だけだ。

上記を満たしつつ、無くても意味が伝わる場合には語数を減らそう。
convertToStringはtoStringでも意味がわかる。

名前のフォーマットで情報を伝える

僕もすでに何度か使っているが、アンダーバーやダッシュ、大文字で名前に情報を組み込むこともできる。
定数なら全部大文字、変数は頭だけ小文字で単語の初めは大文字にする、メソッド名は頭も大文字にする、といったルールが決まっていれば、名前を見ただけでそれが何をしているものか理解できる。
例）
NUMBER_OF_CAR→車のナンバーが定数で格納されてんだな
wheelAmount→タイヤの数かな？変数に入ってるからどっかで取得でもしてんのかな
DriveHighWay→高速道路に乗るためのメソッドかな
みたいな。

ただ、これをする際は「組織内でフォーマット規約をばっちり決めて共有しておくこと、厳守すること」が必須になる。一人の無法者のせいで秩序が完全崩壊することはままあるので注意する。
ちなみに今僕が務めている会社ではフォーマットがどこかに存在するらしいが、新任にそれが共有されてない。なんなんだ。

今日はここまで

「名前に情報を詰め込むようにしろ」「具体的なものにしろ」「長さが問題なのではなく『無意味に』長さが変わっているのが問題」「秩序立てることで表現の幅が広がる」といったのがこの章の内容だった。
次回は第三章、「誤解されない名前」だ。引き続きしっかり勉強すっぞ。

2020-06-19

コードをきれいに書こう

先日、大学の先輩にお声掛けいただいて新しい職場への転職が決まった。やったぜ…
もともと転職を目標に始めた勉強だったので、一つ成果（？）が出て大変うれしい。
嬉しすぎてAPEXのランクシリーズでプラチナ帯に突入するまで勉強をほっぽりだしてしまった。

が、そもそも未経験の領域で仕事をしていくので事前に勉強しておかないと死ぬ。絶対死ぬ。
ということで改めて勉強をしていこう。HTMLはどうしたっていうね。まあまあ、完璧主義も良くないからね。

これからしばらくはこちらの書籍をまとめながら「きれいなコードを書くぞ」という勉強をしていく。
www.oreilly.co.jp

今まで職場の人に育成（といってもC#の読み方も書き方も独学だったので何を教わったかは分からない）してもらっていたので
ちゃんと開発をするところでのコードの書き方にはめちゃくちゃ不安があるので、これでしっかり勉強していきたい。
導入もそこそこに始めていこう。

第一章　理解しやすいコード

導入の章なのでぱぱぱとまとめる。
「優れた」コードとはどういうものを指すのか。
結論を言うと「基準はいろいろあるが、他の人が最短時間で理解できること」つまり「読みやすい」ことだ。
これに比べたら「最小限の行数で書いてある」ことは二の次。
実際、現在の職場では古の時代に書かれたのであろうイミフコードをやまほど見た。
見る人が見れば「テクニカル！グッド！」てなるんかもしれんが、結果大多数の人にとって分かりづらくメンテナンスがしにくいなら意味はない。
まして未経験から配属された僕だ、改修案件では毎回解読に費やす工数が膨大だった。

コードを短くするのではなく、コードを理解するまでの時間を短くする

これが重要だ。この本では、他の人（未来の自分含む）にとって読みやすいコードを書くための考え方がたくさん書かれている。しっかりものにするぞ。

第二章　名前に情報を詰め込む

「名前は短いコメントだ」とこの章のはじめに書いてある。
抽象的で汎用性の高い命名は、応用が利くように思えても単純に情報が不足していることになる。つまり読みにくい。
そこで、下記のポイントに注意して命名せよということだ。

明確な単語を選ぶ

汎用的な名前を避ける（あるいは、使う状況を選ぶ）

抽象的な名前よりも具体的な名前を使う

接尾辞や接頭辞を使って情報を追加する

名前の長さを決める

名前のフォーマットで情報を伝える

一つずつ咀嚼していこう。

明確な単語を選ぶ

例えばGetPage()というメソッドがあったとする。
「ページってどこから取ってくるの？」「フォーマットは？」みたいな疑問が湧くので、もっと明確な単語を使うべきだ。
ネットからページを読み込むならDownloadPage()とした方が媒体が分かりやすい。

もう一つ例が載っている。
Size()というメソッドだ。これ実際めちゃくちゃ見た気がする。C++で。
何の大きさなんだよマジで。画像の大きさならHeight()だし文字の長さならLengthChar()とかにしてくれ。

とかく単語選びの際は「よく見るね」な単語だけでなく、類義語の中でどれを使うと分かりやすいかよく吟味すべきだ。

汎用的な名前を避ける（あるいは、使う状況を選ぶ）

tmpとかretvalとかね。何に使ってるのか1ミリも分からん。「一瞬しか使わんからどうでもいい」のか「コード全体からしたら意味が小さすぎるから適当につけた」のか。
return valueとか「戻り値」だからね。戻り値があるメソッドなんてめっちゃあるだろ。この戻り値は何なんだよ。

ということで、戻り値が足し算の結果ならsum_ExamScoreとかつかったほうがいいよねと。

一方で、よく基本情報とかに出てくる下記のような処理なら別に気を使わなくていい。

tmp = right;
right = left;
left = tmp;

これはtmpという変数の寿命（スコープ）がめちゃくちゃ小さいので、後からコードを読むときに一瞬で何のことか分かるからだ。
あくまでも「読みやすさ（解読時間の短さ）」がキモだ。目的と手段の逆転には重々注意しなくては・・・

今日はここまで

時間的に今日はここまで。
関係ないけど「ニック式英会話」っていうyoutubeチャンネルめっちゃおすすめです。

2020-05-26

Webの勉強をしようPart2

つい興がのってまとめないまま進んでしまった…
結局自分で何か作らないと忘れてしまうのは重々承知だが、
一旦ここまでのことをまとめてみる。

<!DOCTYPE html>
<html lang="ja">
    <head>
        <meta charset="utf-8">
        <title>ドットインストール</title>
        <meta name="description" content="プログラミング学習サービスのドットインストールです">
        <link rel="icon" href="favicon.ico">
    </head>
    <body>
        <!-- memo -->
        <img src="img/logo.png" width="300" height="50" alt="ドットインストールのロゴです">
        <h1>ドットインストール</h1>
        <p>プログラミング学習サービスです！</p>
        <ul>
            <li><a href="#about">このサービスについて</a></li>
            <li><a href="#history">沿革</a></li>
        </ul>

        <h2 id="about">このサービスについて</h2>

        <h2 id="history">沿革</h2>
        <table>
            <thead>
                <tr>
                    <th>年</th>
                    <th>出来事</th>
                </tr>
            </thead>
            <tbody>
                <td>2014</td>
                <td>会社設立</td>
            </tbody>
            <tbody>
                <td>2016</td>
                <td>サイトリニューアル</td>
            </tbody>
        </table>
        <p>&lt;br&gt;あはは</p>
        <pre>
            <code>
                &lt;p&gt;ここで一句。
                いますぐに&lt;br&gt;
                はじめてみよう&lt;br&gt;
                HTML&lt;br&gt;
                &lt;/p&gt;
            </code>
        </pre>

        <h2>主な特徴</h2>
        <ul>
            <li>すごい</li>
            <li>やばい</li>
            <li>つよい</li>
        </ul>

        <h2>使い方</h2>
        <ol>
            <li>動画を見る</li>
            <li>コードを書く</li>
            <li>コードを改造する</li>
        </ol>
        <h2>よく聞かれる質問</h2>
        <dl>
            <dt>質問A</dt>
            <dd>回答A</dd>
            <dt>質問B</dt>
            <dd>回答B</dd>
        </dl>
        <p><a href="#">先頭へ戻る</a></p>
    </body>
</html>

widthとheight

画像のサイズを調整するのに使っている。
imgタグの中にこれを書くことで画像の表示サイズを設定できる（pixel単位）

alt

altタグも同様にimgタグの中に記述する。
altは画像が何らかの理由で表示されなかった場合に表示するテキスト。
音声読み上げブラウザで読み上げられるものでもある。

strong

上述のHTML内では削除してしまっているが、文章を強調表示するときに使用する。
strongタグで囲われたテキストは太字で表示される。

blockquote

文章をどこかから引用してきたときに使う。
正直インデントが入るだけなのでぱっと見では使う必要があるか分からない。
このblockquoteタグにはciteというパラメータを一緒に記述でき、そこに引用元のURLを書いておくのがルールらしい。

<blockquote cite="https://hogehoge~">
<p>これは引用文だよ</p>
</blockquote>

こんな感じ。

hr

ホリゾンタルタグ。話題が変わったところや、他の項目に移る前にこれを入れておくと横線が表示される。
このとき、解説で「あくまで文章の意味の変化を表したいときに書いてください。」「デザインのつもりで入れてしまうと、今後学習するCSSとのすみ分けができないので」みたいな話が入った。
これがこの3日間HTMLの勉強をしていて一番強く印象に残ったところで、あくまでHTMLは「文書をかく」のが目的であって、「デザイン」とかはCSSという考え方をはっきり持っておこうと思った。
この辺の境を曖昧にしてしまうと、後からレイアウトや文書に変更を加えたくなったときに「あれ、これだけ動きが違う！どこに書いたんだ？」と焦ることになる。
これはC#の勉強の時にクラスごとの意味付けをはっきりさせなかったせいで大いに手こずった経験から、その重要さがよく分かった。
strongも含め、見た目をかっこよくしたいときにはCSSの方で解決するんだということを強く意識しておきたい。

実態参照

小難しいワードだが、簡単に言うと「記号とかがHTMLの機能に関連したものと判断されないようにするための書き方をしようね」ということだった。
タグを表す不等号であれば

< なら &lt;
> なら &gt;

と書かないといけない。

pre

HTML文書内では、テキストはすべてpタグで囲ったり、brタグなどで改行をしたりと細かく文書の形式を指定しなければならない。
「めんどくせ～～」ってなったときは表示させたい文章をそのまま書いた後、
preタグで囲ってしまうと手っ取り早い。
以下のような感じ。

<pre>
やっほっほ
    わっはっは
ひっひっひ
</pre>

これは以下のように表示される





やっほっほ

    わっはっは

ひっひっひ

はい。
長いので一旦区切って、次に回す。

前回までのまとめ

第四章「美しさ」

なぜ美しさが大切なのか？

一貫性のある簡潔な改行位置

メソッドを使った整列

縦の線をまっすぐにする

一貫性と意味のある並び

今日はここまで

前回のまとめ

包含/排他的範囲にはbeginとendを使う

ブール値の名前

ユーザの期待に合わせる

複数の名前を検討する

今日はここまで

前回までのまとめ

第三章 誤解されない名前

filter()

Clip(text,length)

限界値を含めるときはminとmaxを使う

範囲を指定するときはfirstとlastを使う

一端ここまで

はじめに：（少なくとも求人の）広告は理詰めで作られている

「おふざけ」さえも理詰めで作っている

前回までのまとめ

抽象的な名前よりも具体的な名前を使う

接尾辞や接頭辞を使って情報を追加する

名前の長さを決める

名前のフォーマットで情報を伝える

今日はここまで

第一章 理解しやすいコード

コードを短くするのではなく、コードを理解するまでの時間を短くする

第二章 名前に情報を詰め込む

明確な単語を選ぶ

汎用的な名前を避ける（あるいは、使う状況を選ぶ）

抽象的な名前よりも具体的な名前を使う

接尾辞や接頭辞を使って情報を追加する

名前の長さを決める

名前のフォーマットで情報を伝える

明確な単語を選ぶ

汎用的な名前を避ける（あるいは、使う状況を選ぶ）

今日はここまで

widthとheight

alt

strong

blockquote

hr

実態参照

pre

第三章　誤解されない名前

第一章　理解しやすいコード

第二章　名前に情報を詰め込む