より良いタイポグラフィ
日記を書き始めてから、文字のレイアウトにますます気を配るようになった。
僕は、自分が書いたものが丁寧にデザインされたものであり、他人に見られたときに心地よく感じてもらえるようにしたいと思っているので、関連する知識を調べたり学んだりしている。
そこで、以下のソースからいくつかのルールを抜粋し、補足する：
中央揃えの省略記号を使用する
その表示上は二つの漢字スペースを占め、六つの省略点を含み、水平および垂直方向ともに字面の中央に位置する。通常、二つの連続した
U+2026 HORIZONTAL ELLIPSIS […]を使用して実現される。Unicode 標準第 14 版の 6.2 章では、
U+22EF MIDLINE HORIZONTAL ELLIPSIS [⋯]を省略記号として使用することも推奨されている。この記号は適切な方向転換と置換メカニズムと組み合わせることで、表示上は縦書き横書きに関わらず、省略点が中央に配置され、より組版の要求に適合する。
しかし、このコメント によると、後者は数学記号に属する —— おそらく LaTeX の \cdots に対応する文字だろう —— さらに このコメント では がデフォルトで前者にマッピングされると指摘されているので、僕個人としては前者を使用することにしている。
本ウェブサイトでは、中央揃えの省略記号を実現するために、字形が中央揃えスタイルのフォントを特別に使用している。
注意
未実装
標準的な固有名詞を使用する
例えば GitHub の場合、公式がこの言葉を使用する際は常に GitHub であり、github や gitHub などを使用することは決してない。
Xcode も同様で、c は小文字だが、VSCode では C が大文字である。
もちろん、プログラミングには camelCase のような命名規則があるが、その場合 GitHub は何に対応するのか？github なのか、それとも gitHub なのか？
興味のある読者は camelCase 英語版 Wikipedia の Programming and coding の節を参照されたい。
僕はこう考えている。相手がそのようにデザインしたのだから、その特徴を保持するのが最善である。
ここに、個人が最終的に採用する命名をリストアップする：
| 分類 | 命名法 | 例 |
|---|---|---|
| 固有名詞 | - | GitHub、SurviRed、API、JSON |
| 変数・関数名 | camelCase | gitHub、surviRed、api、json |
| クラス名 | PascalCase | GitHubAPI、SurviRedJSON、APIJSON |
| 定数名 | CONSTANT_CASE | SURVIRED_API |
| ファイル名・URL | kebab-case | github-json |
括弧の過度な使用をやめる
括弧が何層にも入れ子になると、意味が極めて「歪曲」し、理解するのに回り道が必要になる。同時に、右括弧がいくつも連続して並ぶ状況が生じ、これは非常に美しくない。特に、括弧内の多重括弧が終わった後に次の文が続く場合、その指す前文を素早く見つけるのは非常に難しい。
例文：
僕は知っていたが聞く気はなかった（僕は普段から物事を遮断するのが得意な方だ（ただし、この前の週テストの理科総合（国語（？））試験の時、外で葬式をやっていて、葬送の音楽で僕は完全にやられた）のだが）、隣の同級生は興味津々で聞いていた。
より良い方法は、もちろん括弧をできるだけ使わないことで、表現したい内容をできるだけ展開（flatten）し、飛躍的な文には破線を使用する。
修正：
僕は知っていたが聞く気はなかった —— 僕は普段から物事を遮断するのが得意な方なのだが、この前の週テストの理科総合（国語？）試験の時、外で葬式をやっていて、葬送の音楽で僕は完全にやられた —— 隣の同級生は興味津々で聞いていた。
和欧混植時にスペースを追加する
ほとんどの場合、半角文字と全角文字の間にスペースを入れることで、文章がそれほど詰まっていないという印象を与えることができる。
例えば、次の文：
僕が好きなのはapple、嫌いのはpeachとorange。スペースを追加：
僕が好きなのは apple 、嫌いのは peach と orange 。ここでは各単語の左右両側にスペースを追加した。
しかし、実際には apple と orange の後に続くのは全角の句読点であり、この句読点は視覚的に半角記号とスペースと見なすことができるので、後ろのスペースを削除できる。
僕が好きなのは apple、嫌いのは peach と orange。しかし、「——」「……」のような全幅を占める句読点の場合、今見ると確かに少し詰まっているので、スペースを追加することをお勧めする。
これにはもう一つの利点がある。少し詳しく説明しよう：
テキストを編集する際、 または を使ってカーソルを移動することがよくあるが、これは非常に不便である。
そこで、 または を使用して高速ジャンプを行うことができる。Microsoft Word のようなエディタの場合、中国語の単語を賢く分割するので、ジャンプ時には単語の先頭または末尾にジャンプし、文全体の先頭または末尾にはジャンプしない。
一方、中国語の分かち書きを実装していないエディタの場合、追加されたスペースが「踏み台」として機能し、ジャンプがより便利になる。
計量単位
1 kg、1 m、1 s。数字と単位の間にはスペースが必要である —— これは実際には英語の組版要求である —— 一方、100% のような場合、パーセント記号にはスペースは不要である。
4G（第四世代移動通信技術）のような語は、それ自体が専門用語なので間にスペースは不要だが、4 G は確かに「四倍の重力」「四枚の金貨」のような意味を表すことができるので、これは文脈次第である。
同時に、Apple のこの点における細部について述べておくと、彼らは上記のように半角文字と全角文字の間の間隔（カーニング）を微調整するので、スペースを追加したのと同じように見える。むしろ、自分でスペースを追加すると間隔が大きくなりすぎる可能性がある。
しかし、すべてのデバイスがそのような特性を持っているわけではないことを考えると、自分でスペースを追加する方がより普遍的である。
スラッシュ
英語の組版では、「または」を表すスラッシュの両側にスペースは不要で、26 個の英字の一つとして扱われる（大霧）。
しかし、コードでは、スラッシュは通常除算を表すので、両側にスペースが必要で、より良い可読性を提供する。
引用符
こんにちは、僕たちは “ ” ‘ ’ " ' 「 」 『 』 です。今日はみんなが見たいものをお届けします。
「または」
「A または B」は二者択一？それとも二者のいずれか一方でも可？
数学、プログラム、または論理学においては、「または（OR）」はデフォルトで後者を指し、厳密には「論理和」と呼ばれる。前者を表す場合は、「排他的論理和（XOR）」を使用する。
自然言語では、排他的論理和に傾く傾向があるが、具体的には文脈次第である。例えば、上記の「数学、プログラム、または論理学において」という文は、論理和を表している。
では、A/B はどうだろうか？これは実際には二者択一か二者のいずれか一方かを強調せず、両者とも必ず現れなければならないことを表す場合もある。つまり A ∧ B を表すこともある。例えば I/O。
要するに、OR と XOR を使用すればこのような問題を避けることができる。