Ｑ．一行80文字(半角80文字・全角40文字)で区切ることが多いがなぜか？
Ａ．パンチカード(ホレリスのIBMパンチカード)時代からの流れ

クラスにすると大変利点を感じるケース
・開始処理と終了処理が定型的なもの
  ＃ファイルアクセス(Open＆Close)的なもの
  →コンストラクタとデストラクタに処理を設置することにより
    処理の漏れを防ぐ(こともできる)
・一度だけ読む込む定数ファイル的なもの
  →アクセスは一度でメンバ変数に保持し、ゲッタで返却取得
・決まった場所に入出力する場合
  →ゲッタやセッタで

┌──────────────────────────────────────┐
│○Goto文の使用                                                    (⇔構造化)│
│○グローバル変数の濫用                                                      │
│○Private修飾子の軽視(Public修飾子の濫用)                                   │
│○Static修飾子の軽視                                                        │
│○Variant型の濫用                                                           │
│○Const修飾子の軽視                                                         │
│○Option_Explicitの軽視                                                     │
│○コンパイルオプションの緩慢化                                              │
│ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -│
│△構造体の濫用                                                              │
│△連想配列の濫用                                                            │
│△Return文・Break文・Continue文の濫用                                       │
└──────────────────────────────────────┘
  そりゃルールがなけりゃ楽だよ、でも、とってもめんどくさくなるんだよ。

「垂直(Vertical)」と「水平(Horizon)」について、
なんとなく「縦」と「横」というイメージがある。

でも、Excelにおけるページ分割、つまりページが縦に並んだ場合は「HPage」、
すなわち「水平(Horizon)」で制御される。

「縦」に並んでいるのだから「VPage」ではないのか？
と思うわけだが、「垂直(Vertical)」と「水平(Horizon)」のイメージにより
一概に「縦」と「横」にあてはめられないということらしい。

で、イメージは以下の通り。
┌───────────────┐
│垂直(Vertical)  水平(Horizon) │
│┌─┬─┬─┐  ┌─────┐│
││  │  │  │  │          ││
││  │  │  │  ├─────┤│
││  │  │  │  │          ││
││  │  │  │  ├─────┤│
││  │  │  │  │          ││
│└─┴─┴─┘  └─────┘│
└───────────────┘

つまり、横は横でも、横に広がるイメージらしい。(水平線ってくらいだから)

なので、ページが縦に並ぶのは、左のイメージで「水平(Horizon)」になるというわけ。

「コンピューター」「プリンター」「サーバー」「ユーザー」は、
「コンピュータ」「サーバ」「ユーザ」なのかという話。

「JIS Z8301:2005」より前までは以下のルールで末尾の長音符を省略としていた。
┌──────────────────────────────────────┐
│・(末尾の長音符号なしで)3音以上の場合には末尾に長音符号を付けない           │
│  →「プリンタ」                                                            │
│・(末尾の長音符号なしで)2音以下の場合には末尾に長音符号を付ける             │
│  →「カバー」                                                              │
│・複合語はそれぞれの成分語について適用する                                  │
│  →「モータカー」                                                          │
│・(文中の)長音符号・撥音(ん)・促音(っ)は1音扱いとして上記を適用する         │
│  →「サーバ」「ダンパ」「ニッパ」                                          │
│・拗音(ゃ・ゅ・ょ)は1音扱いとしないで上記を適用する                         │
│  →「シャワー」                                                            │
└──────────────────────────────────────┘
但し、「JIS Z8301:2005」において、省略してもしなくても
どちらでもよいことになった。

なお、1991年6月28日の内閣告示第二号「外来語の表記」にて
「長音は、原則として長音符号「ー」を用いて書く」とされた。
マイクロソフトは2008年、これに従って表記法を変更した。

いずれにしろ各社の対応はまちまちのようである。

評価という行為において、数値型(int型)と論理型(bool型)のいずれかを使用する場合
論理型は項目が多岐に渡り、数値型はあいまいになる。

例えば、データベース技術がどの程度あるかを確認する場合、
質問内容が以下のような感じになる。

【論理型の場合】
┌──────────────────────────────────────┐
│熟知しているものにチェックをいれてください                                  │
│  □SELECT  □INSERT  □UPDATE  □DELETE  □CREATE TABLE …                 │
└──────────────────────────────────────┘

【数値型の場合】
┌──────────────────────────────────────┐
│SQLの技能はどの程度？(1:不得意、2:やや不得意、3:普通、4:やや得意、5:得意)   │
└──────────────────────────────────────┘

デジタル(前者)とアナログ(後者)の関係みたいだ。
っていうか、論理型はデジタルの最たるものだもんね。

「または」と「もしくは」の関係は以下の通り。
┌───────────────────┬──────────────────┐
│■または■                            │■ or ■                            │
├───────────────────┼──────────────────┤
│■、■または■                        │■ or ■ or ■                      │
├───────────────────┼──────────────────┤
│      (■もしくは■)                  │   (■ or ■)                       │
│または(■もしくは■)                  │or (■ or ■)                       │
├───────────────────┼──────────────────┤
│      (        (■もしくは■)         │   (   (■ or ■)                   │
│       もしくは(■もしくは■))        │    or (■ or ■))                  │
│または(        (■もしくは■)         │or (   (■ or ■)                   │
│       もしくは(■もしくは■))        │    or (■ or ■))                  │
└───────────────────┴──────────────────┘

数字の一とマイナスの違いぐらいはわかるけど、
他にもいろいろ紛らわしい文字があるのやら(文字コードはUTF-8)。

【全角半角変換ができるもの】(VBAの「StrConv(,vbNarrow)」「StrConv(,vbWide)」)
┌────┬─┬──────────┐  ┌────┬─┬──────────┐
│0xEFBC8D│－│全角ハイフンマイナス│⇔│    0x2D│- │半角ハイフンマイナス│
├────┼─┼──────────┤  ├────┼─┼──────────┤
│0xE383BC│ー│全角長音            │⇔│0xEFBDB0│ｰ │半角長音            │
└────┴─┴──────────┘  └────┴─┴──────────┘

【全角のみのもの】(半角変換ができないもの)
┌────┬─┬──────────┐
│0xE28090│‐│全角ハイフン        │
├────┼─┼──────────┤
│0xE28095│―│ホリゾンタルバー    │
├────┼─┼──────────┤
│0xE29480│─│罫線(細)            │
├────┼─┼──────────┤
│0xE29481│━│罫線(太)            │
├────┼─┼──────────┤
│0xE4B880│一│漢字(壱)            │
└────┴─┴──────────┘

【シフトJISにはないもの】(UTF-8)
┌────┬─┬──────────┐
│0xE28092│‒ │フィギュアダッシュ  │
├────┼─┼──────────┤
│0xE28094│— │半角ダッシュ        │
├────┼─┼──────────┤
│0xE28093│– │二分ダッシュ        │
├────┼─┼──────────┤
│0xE28892│− │半角マイナス        │
└────┴─┴──────────┘

┌──────────────┬─────┬─────────────────┐
│一般的な大分類              │参照      │更新                              │
│                            │読込      │書込                              │
├──────────────┼─────┼─────┬─────┬─────┤
│ファイルアクセスの分類      │読込      │書込      │上書      │削除      │
│                            │READ      │WRITE     │REWRITE   │DELETE    │
├──────────────┼─────┼─────┼─────┼─────┤
│DBアクセス(SQL文)の分類     │          │追加      │変更      │削除      │
│                            │          │挿入      │更新      │削除      │
│                            │READ      │WRITE     │REWRITE   │DELETE    │
│                            │SELECT    │INSERT    │UPDATE    │DELETE    │
│                            ├─────┼─────┴─────┼─────┤
│                            │          │併合                  │削除      │
│                            │SELECT    │MERGE                 │DELETE    │
│                            │SELECT    │UPSERT                │DELETE    │
└──────────────┴─────┴───────────┴─────┘

同一明細にて、「追加(INSERT)・変更(UPDATE)・削除(DELETE)」を
同時に指定できる場合、漫然と「追加→変更→削除」の順で処理してもよいが、
「変更→削除→追加」の方がいいのではいだろうか。
※ここでは、追加(INSERT)は新規ID(自動的に末番)を付番し、
  変更(UPDATE)・削除(DELETE)は既存IDに対して更新するものとする

つまり、マトリックス表的には以下の関係となる。
┌──┬──┬──┬──┐
│ → │追加│変更│削除│
├──┼──┼──┼──┤
│追加│ ＼ │ × │ × │
├──┼──┼──┼──┤
│変更│ ○ │ ＼ │ ○ │
├──┼──┼──┼──┤
│削除│ ○ │ × │ ＼ │
└──┴──┴──┴──┘
  ×削除→変更
    先に削除をしてしまうと同一IDに変更指示があった場合、
    変更処理にて該当なしエラーとなってしまう。
    結果的に削除されるのであれば、おとなしく変更を先にしてしまえばよい
  ×追加→変更・削除
    追加にて新規IDが付番されるのだが、変更・削除にてたまたまそのIDを
    指定していると、該当なしエラーとなるべきところ通ってしまう

ということで、「変更→削除→追加」の順がベスト。

もちろん、場合によりけりだけど。