プログラミングはプロポーショナルフォントの方が読みやすい ? 109
ストーリー by reo
やったことがないからやってみよう 部門より
やったことがないからやってみよう 部門より
ある Anonymous Coward 曰く、
本家 /. 記事「Programming With Proportional Fonts?」より。
/.er はプログラミングにはどんなフォントを使っているだろうか?
プログラマーである Maas-Maarten Zeeman 氏は自身のブログで「プロポーショナルフォントは等幅フォントよりも 14 % 速く読める」との研究を例にあげ、プロポーショナルフォントの使用を勧めている。
同じテキストを等幅フォントとプロポーショナルフォントで表示させた場合、プロポーショナルフォントの方が短い幅で済み、短時間で読めるとのこと。また、例えば同じ文字数の単語であったとしても、その文字種によって単語の表示幅が微妙に異なる方が単語認識を素早く行えるという。
ちなみに Zeeman 氏のお気に入りフォントは OS X では Lucida Grande、Windows では Lucida Sans だそうだ。
/.J 諸兄方は等幅派だろうか? それともプロポーショナル派? また、お気に入りのフォントは?
コードを読んだり書いたりするのは絶対等幅フォントですね (スコア:3, すばらしい洞察)
インデントやタブ幅も重要です。
Re:コードを読んだり書いたりするのは絶対等幅フォントですね (スコア:1)
それ故、minX, minYとかminX, minYだと後者の方が記号っぽく読みやすい・・・と信じてたんですが、こうして見比べると前者の方が読みやすいな。
# オフトピだけど、変数名にleft, top, right, bottom, height, widthを使うと
# 似たような式が数行並んでる部分の縦が綺麗にそろわないのが気にくわない。
後は、等倍の方が、左から右へ目線を送るスピードが一定だから読みやすいに違いない、とか、 線の太さが同じで飾りが少ない方が識字に必要な脳内リソースが少なくて済むから疲れないに違いない、とか。 漠然とそんな気がしてただけで、このネタを見るまでちゃんと意識したことは無かったですが、 なんかそんな印象から等倍フォントを固持してます。
Re:だよね。 (スコア:1)
それは、The Art of Computer Programming という本でしたか？
それとも、Programming Language C++ という本でしたか？
やりたいことによる (スコア:2, すばらしい洞察)
大切なことは、ゼロとオー、大文字Iと小文字l、数字1などの判別が容易であること
これらの条件を満たすとどうしてもプログラミング専用フォントになってしまい、そう
するとプロポーショナルフォントは少ない。
C/C++で書くなら、フォントなんてプロポーショナルだろうが等幅だろうが関係なく
みやすければいい。
F77やアセンブラで書くなら、等幅がいいし、ASCIIベースの通信を書き下すときも
やはり等幅がいい。そういう仕事があるなら、普段から等幅にしといたほうがいい
という観点もある。
Re:やりたいことによる (スコア:3, 参考になる)
あと、プロポーショナルフォントだとピリオドやカンマ、セミコロンなどの記号がごま粒のように小さく、その他の記号も軒並み存在感のないような出来のものばかりです。プログラミングでは、これら記号が重要なことが多いので、等角フォントばりに記号も目立つプロポーショナルフォントがあったらいいと思っています。
Re:やりたいことによる (スコア:2, すばらしい洞察)
全角スペースだってそこだけ背景赤で表示してもらえればおおむね気づくわけでして
フォントのお仕事でないかもしれないなあと最近つらつら考え中
Re:やりたいことによる (スコア:3, すばらしい洞察)
そのへんはどっちかってと「危険な記号」をハイライト表示しないエディタの不備というような気はします
それはむしろフォント側の不備をエディタがフォローしているだけと言った方が正しい気がする。
カンマやピリオドのような頻繁に出てくる記号をハイライトされたらうざすぎて視認性にはマイナス。
ハイライトが頻出しすぎると「テキストの強調」という本来の効果が低下してしまいます。
なので紛らわしい記号はフォントだけで識別できるようにし、ハイライトは特定キーワードのようなもっと重要な目的に使うのが正しいあり方だと思います。
うじゃうじゃ
Re:やりたいことによる (スコア:1)
>どこから「危険」って出てきた？
「重要なもの、注目すべきもの、注意してみるべきもの、区別が必要なのに区別しづらいもの」
→「見分けられないと困るもの」
→「（見分けられないと）危険なもの」
という表現のバリエーションでしょう。
元の言葉と違うということは分かっているからこそのカギカッコ括りで。
日本語としてはそんな珍しい事柄でもありませんね。
お気に入りのフォントは? (スコア:2, 興味深い)
Courier New最高！
しかしこれに合う日本語フォントってのが…
ブロックでのコピー（カット）＆ペースト (スコア:2, 参考になる)
プログラムに限らずテキストでもブロック単位でのコピペ使ったりしません？
プロポーショナルフォントだとこれができなくなるのでエディタ類では必ず等幅です。
コメントはまぁいいかも (スコア:1, すばらしい洞察)
コメントの文章の部分だけなら、プロポーショナルもいいと思いますけど、
似た条件式が複数行に渡って並んでたりすると、桁がそろった方が便利だと思う。
プログラムって、別に全部読み下したいわけじゃないしね。
でも、別に他人がどんなフォント使おうと実際どうでもいい話ではある。
Re:コメントはまぁいいかも (スコア:1)
新人。プログラマレベルをポケモンで言うと、コラッタぐらい
ネイティブかどうか、またプログラミング歴でも違うんでは (スコア:1, 興味深い)
英語ネイティブな人だとプロポーショナルの方が判読が速いというのは
ありそうですね。日本人はマス目文化なので固定幅フォントの方が好きという
人も多いでしょう。
それと、キャラジェネ使ったテキストVRAM時代からプログラムを書いてた人は
固定幅フォントにするんじゃないですかね。8ビット機でアセンブラ書いてたよんとか。
アセンブラは固定幅じゃないと読みづらいですねえ。
私なんかもそうで、エディタでも何でも速攻で固定幅に設定し直します。
Re:ネイティブかどうか、またプログラミング歴でも違うんでは (スコア:4, すばらしい洞察)
違うな。
コーディングシートにプログラムを書いていた人は等幅フォントを選ぶと思う。
あとはエディタの振るまいとかも影響大かと。
vimでiとかkを押したときにカーソルが蛇行すると見づらいと思う。
Re:ネイティブかどうか、またプログラミング歴でも違うんでは (スコア:1)
類する感じでFORTRAN(77)な人も。
オールマシン語 (スコア:2)
固定幅
プロポーショナル
うーむ、これくらいじゃ短すぎてあんまり変わらん。
Re:オールマシン語 (スコア:3, 興味深い)
ぐお、2x年ぶりくらいなもんで間違えました。こうか。
# まあどっちでもいいんですけど。
左様、NOPでループしているだけでござる (スコア:2)
相対ジャンプはノンゼロのときでぃす。
(JR NZ)
# 合ってるのか、もう自信ないですぅ…。
Re:ネイティブかどうか、またプログラミング歴でも違うんでは (スコア:1)
ここにぶらさげるものでは無いよな気もしてきたけどまぁいいや。
本家のコメントをてきとーに斜め読みしてみかけた等幅推奨部隊のコメント。
# 向こうの人の言う AA で有機分子の構造を書かれたのをみたことはあり。
# コード中では AA をみたことないかなぁ。何書いてるんだろ。
# コードの設計、構造的なつながりとかかなぁ?
なんだかんだ等幅が圧倒的な主流に見えます。
そしてコメント内容はこっちと大きく変わらないかなぁ。
ただし、一般的な文章としてはプロポーショナルのほうが読みやすい
ってのは多分そうなんだろって感じ。少なくともそこへのツッコミは
高いスコアとってないし、雰囲気的にも。読み抜けてたり空気読めて
なかったらすまん。
# ちなみに funny なコメントは理解できてないことが結構ある。
# insightful, informative は理解しやすい。interesting は基準が良く分からん。
# …理解できてないのか、自分?
ちなみに個人的にも等幅一択。
垂直方向の整列はデバッグの時に余計な紛れを見やすくしてくれるとか色々。
そしてなにより重要なことは慣れ。
やってみたらプロポーショナルでも意外に何とかなるかな?
すくなくとも (スコア:1)
Re:すくなくとも（横レス） (スコア:1)
その昔、私の持っていたタイプライターは１の代わりにLの小文字を使うことになっていたというのを思い出した。
でも、アレのおかげでタッチタイプ（ブラインドタッチ？）が出来る様に成ったんだと懐かしさに浸ってます。
それはさておき、横文字圏の人たちは前後のつながりで区別するんでしょうね、我々日本人が漢字の読み方を判別するように。
BDF M+サイコー (スコア:1)
テキストエディタ、バイナリエディタ、IDEは全部これにしています。
昔はウィンドウのUIまでこれに統一してたけど、最近はOSの設定には手を入れないようになったので
そこまではやらなくなった。
おしいむらくは、正しいポイント数を指定しないとまともに表示されないこと。
VisualStudioでソースをプリントアウトすると真っ白けの紙切れが出てきたりします。
（そのときは、仕方ないので、印刷だけはMSゴシックで我慢してる）
フォントが小さめで画面に情報を詰め込めるのもメリットですが、
フルHD以上を出せる特殊なディスプレイで使うと小さすぎて見にくくなるのが難点です。
どんなポイント数でもきちんと出るBDFM+、欲しいなぁ。
目的によるが基本的には等幅派 (スコア:1, 興味深い)
ざっとソースに目を通す目的であれば、
確かにプロポーショナルフォントの方が読みやすいのかもしれない。
実際、レビュー目的で印刷するときはプロポーショナルなセリフ体を使っている。
ただ、自分でコーディングする時のエディタは等幅でないと厳しい。
行末の位置や文字数で無意識に行うチェックができなくなってしまう。
例えば変数名が１文字増えたから行末も１文字ずれるはずだ、とか
ブロック内とブロック外に同じ文字数の行があったら
インデント分のずれが生じるはずだとか、
そういった感覚からミスに気づくことができなくなってしまう。
それに他の方もコメントしていたが、
矩形の選択や削除も困難になるし、
カーソルの上下移動時にカラムがずれてしまうのも痛い。
書籍ならアリかも (スコア:1)
本家のコメントにもありますが [slashdot.org]、「The C++ Programming Language」ではコードをプロポーショナルフォントで記述していますね。これ、日本語版の「プログラム言語C++」でも一緒。
こういった書籍で使うのならばアリかな？と思います。
他のコメントで指摘されている、縦に揃わない問題も、書籍用に組版するならいくらでも調整が効きますし。
ただ、実際のプログラミング作業では使いたくありません。
ワープロみたく、タブ位置を自由に調整できるエディタが普及しているなら意見が逆になっていたかもしれませんが。
ん？ でも、HyperTalkやAppleScriptのエディタって、デフォルトがプロポーショナルフォントだったような記憶が。記憶違いかな？
こいつらはあまり縦に揃えようと思わない言語だったしなぁ。
とか
とか、縦に揃えて書けたとしても却って違和感が。
巧妙に潜伏したバグは心霊現象と区別が付かない。
次のお題 (スコア:1)
モノクロで書くもの？
あなたはどっち派？
私はモノクロ派です。
コメントいっぱい書いても誰も読んでくれないので調べたら
あるIDEではコメントは薄～い緑かなんかになってて
「無視してくれ」状態で愕然としたことがあります。
編集過程でリアルタイムに色が変わるのもうざい。
みかちゃんフォント (スコア:1)
みかちゃんフォントでコメントがかいてあると
とってもやさしいきもちでよめるとおもうのです
Re:みかちゃんフォント (スコア:1)
なんと、こんなOSがあったとは……
しかしTerminalもみかちゃんフォントとは徹底してますね……ｗ
しかしいいページを教えてもらいました。ちょっと興味が出てきましたよｗ
そもそも (スコア:1)
> プログラマーである Maas-Maarten Zeeman 氏
この人の場合に「14%早く読めた」だけであって、ほかの人の場合も同じ結果かどうかは別議論ですよね？（ソース見てないけど）
それに、可読性の話だけであって、メンテナンス性やコーディングの効率も良くなるとは言っていないわけで。
でも、ピリオドやコロン、セミコロン等可読性が落ちると言う意見には同意なので「Zeeman 氏の場合」なんだろうな・・・
Re:当然です (スコア:3, すばらしい洞察)
本家でも言うてる [slashdot.org]けど、Python では致命的。
Re:当然です (スコア:3, 参考になる)
その記事を読めばわかると思いますが、Pythonのようなオフサイドでのブロック構造を壊してしまうのは、複数のスペースを1つのスペースに変換してしまうエディタ(むしろワープロに多い機能)であって、プロポーショナルフォントではありません。
プロポーショナルフォントでも空白文字の幅が常に等しければ、行頭からの空白文字数と水平位置の関係は保たれるので、Pythonでも問題なく読み書きできます。
Re:当然です (スコア:1)
本家コメントでSkapare氏がおっしゃっている"consistent indentation（一貫したインデント）"は、Guide氏のコーディングスタイルガイド [python.org]を指しています。
スペースのみ、もしくはタブのみのインデントであれば、プロポーショナルフォントであろうともPythonのブロック構造を崩すことはありません。問題なく使用できます。
# 試しにMS-Word / Lucida Sansで自分が書いたコードを表示させてみましたけど、インデントにはなんら問題はありませんでした。
# でもI（大文字アイ）とl（小文字エル）がほとんど判別できない(^^;)
他の言語では、インデントにタブとスペースを混在させているもの（4桁インデント／8桁タブ）をしばしば見かけますが、Pythonではご法度です。（インデントがブロック構造と直結しているため、インデント間違いが動作に影響を及ぼしますから）
Re:当然です (スコア:2, おもしろおかしい)
Re:当然です (スコア:2)
Re:当然です (スコア:1, おもしろおかしい)
ドラゴンと量子物理学者みたいな強力な怪物が（下り階段が2つある）ノームの鉱山との分かれ道にいるはずがない！と思ってしまった。
Re:当然です (スコア:1)
甘い。このフロアには変化の罠があるはずだと警戒すべきだ。
そうでなければ生き残れないぞ。
Re:当然です (スコア:1)
それよりも扉の位置に注目してほしい。
すべての扉は部屋の隅にあり、通常の方法では通過することができない。
つまりこの二つの部屋は密室となっていて、犯人はまだこの中にいるということだ！
「探してみたらテレポートのトラップありましたよ」
うじゃうじゃ
Re:どっちでもいい (スコア:1)
Re:どっちでもいい (スコア:1)
> 欧文フォントの中には１と小文字のエルが全く同じ形をしているものもあります。
コンピュータ以前の、英文タイプライター時代から、1と0のキーがなくて、代わりに l と O を使えっていうものがありましたしねぇ。
欧米はそのあたりがおおらかというか、AN Unification してしまって
文脈でどちらか判断するってとこで気にしてないに違いない…
Re:どっちでもいい (スコア:1)
コンパイラ(インタープリタ)も文脈で判断してくれるのであれば私は全然問題ないんですけどね。
しかし...
void g(char*f) { printf(f, 345); }
void h(char*f) { printf(f, 345LL); }
void f() { char *a = "%11d", *b = "%lld"; g(a); h(b); }
こんな感じになっていてg()やh()がf()と別ファイルで定義されていれば文脈で判断しようがないですね。
Best regards, でぃーすけ
Re:どっちでもいい (スコア:1)
Iとlは普通は色分けされませんぜ旦那。
さておき、私もプログラミングに限ってはあまりその辺で困ったことは無かったりしますが、
その他の状況（出力見たり、ログ見たり……）や、コンソールを使う際に何度か見分けが
付かなくて困ったことがあるので、
エディタとコンソールは基本的に等幅です。
# 昔からの慣れというのもありますが。
# 今は「VL ゴシック」使用中
Re:どっちでもいい (スコア:1, おもしろおかしい)
Re:どっちでもいい (スコア:1)
Adobe Illustrator
とかな
Re:どっちでもいい (スコア:1)
> MSゴシックは勘弁
「ＭＳ ゴシック」ってポイント数によっては文字の幅がずれちゃうんですね。
等幅といいながらプロポーショナルより不揃いだったりして。
Re:どっちでもいい (スコア:1)
３の整数倍（１．５の整数倍）で無いとうまくいかないという現象にあたった覚えが…
Re:どっちでもいい (スコア:1)
> プログラムコードは「読み物」じゃないし。
そんなこと書くとクヌース先生に叱られます。
Re:俺的には日本語コメント混在のソースを書くので (スコア:1)
それはソース内に怪しい文字があると警告するようにエディタを設定した方が良いのでは？
等幅でもスペースの幅を目をこらしてみる必要はないですし
そもそも、全角と半角が区別がつかないぐらいに制御してくれるエディタ自体、珍しいような
#結局は読み慣れているのが一番読みやすいだろうから、等幅でも良いと思うけど。
Re:ターミナルなんだよ (スコア:2)
プロポーショナルフォントな HEX ダンプはイヤだな。確かに。
そういや IPv6 アドレスってプロポーショナル表記な文書が多い気がする...
みんつ
Re:ターミナルなんだよ (スコア:1, 荒らし)
1行表示がメインだし、短縮もするからだろうか...?
# コードとか変数指定だったらHTMLでも大概は固定幅になりそうだけど、どうだろ
M-FalconSky (暑いか寒い)
Re:数字は等幅のほうが (スコア:1)
右詰めを勝手にやってくれるなら。
zが2000になったりすると全部インデントし直すのは辛い。
スペース消したつもりが間違えて数字削っちゃって…とかもありそう。
Re:数字は等幅のほうが (スコア:1)
これは幅が違いますよね？
iiiiiiiii
wwwwwwwww
ではこれの幅は銅ですか？
0123456789
1111111111
8888888888
ほとんどのフォントは数字は等幅だろうから
よほど変なフォントを使わない限り大丈夫だろう。