Có ai thích phông chữ tỷ lệ? [đóng cửa]


51

Tôi đã đọc bài viết trên wikipedia về phong cách lập trình và nhận thấy điều gì đó trong một cuộc tranh cãi với mã được sắp xếp theo chiều dọc:

Sự phụ thuộc vào phông chữ đơn cách; định dạng bảng giả định rằng trình soạn thảo sử dụng phông chữ có chiều rộng cố định. Hầu hết các trình soạn thảo mã hiện đại đều hỗ trợ phông chữ tỷ lệ và lập trình viên có thể thích sử dụng phông chữ tỷ lệ để dễ đọc .

Thành thật mà nói, tôi không nghĩ rằng tôi đã từng gặp một lập trình viên thích một phông chữ tỷ lệ. Tôi cũng không thể nghĩ ra bất kỳ lý do thực sự tốt để sử dụng chúng. Tại sao ai đó thích một phông chữ tỷ lệ?


11
Tôi thích phông chữ tỷ lệ để đọc, nhưng tôi hoàn toàn sử dụng phông chữ đơn cách cho mã. Luôn luôn, luôn luôn, luôn luôn.
Frank Shearar

12
Để trích dẫn Wikipedia: [citation needed]:)
dr Hannibal Lecter

7
Nhiều năm trước, một giáo sư mà tôi có trong trường đại học nửa đùa nửa thật "... bởi vì nó không phải là chương trình trừ khi nó là chuyển phát nhanh mới."
Steven Evers

12
Lý do của tôi để sử dụng một phông chữ tỷ lệ là rất đơn giản. Đó không phải là những năm 1980 nữa. Chúng tôi đã chuyển từ thiết bị đầu cuối nhân vật. Báo chí, sách và trang web thường không sử dụng phông chữ đơn cách vì lý do dễ đọc. Tôi nghĩ rằng họ có một điểm.
Timwi

4
Verdana 11px là tuyệt vời.
Czarek Tomczak

Câu trả lời:


47

Điểm chung so với phông chữ tỷ lệ, nhận xét.

  • Bạn không thể căn chỉnh chính xác mã theo chiều dọc với phông chữ tỷ lệ. Ý tôi là, bạn có thể căn chỉnh chính xác mã theo chiều dọc với phông chữ tỷ lệ, nếu mọi người đang sử dụng các tab đàn hồi , nhưng than ôi ...
  • Một số phông chữ tỷ lệ làm cho khó phân biệt một số nhóm ký tự. (ví dụ: mrnm). Tuy nhiên, không phải tất cả các phông chữ lập trình đều hoàn hảo: Courier New có 'O' và '0' giống hệt nhau '1' và 'l'.
  • Một số IDE có hỗ trợ kém cho phông chữ có chiều rộng không cố định (như Visual Studio đã nói ở trên hoặc IDLE của Python). Trong một số bối cảnh, bạn cũng không thể sử dụng nó. (ví dụ: thiết bị đầu cuối.)
  • Chọn một phông chữ tỷ lệ để mã hóa sẽ giúp bạn trong các cuộc chiến thần thánh bất tận. Tuy nhiên, ở đây, vấn đề tồn tại giữa bàn phím và ghế.

Điểm có lợi cho phông chữ tỷ lệ

Cá nhân, tôi đã sử dụng cả phông chữ 'Ubuntu' và WenQuanYi Zen Hei Mono với niềm vui và thấy mình không thể thích cái này hơn cái kia. :)

Ubuntu
WenQuanYi Zen Hei Mono
Ubuntu 10 và WenQuanYi Zen Hei Mono 9, được so sánh. Không có người chiến thắng rõ ràng ở đây, nếu bạn hỏi tôi.

Điều đó nói rằng, phông chữ giống như thực phẩm. Một số người thích chúng tròn trịa, một số thích chúng nóng và cay - không có ai đúng phông chữ, hoặc tất cả chúng ta sẽ sử dụng nó ngay bây giờ. Yay cho sự lựa chọn!


Tôi đã không nhận ra rằng phông chữ Ubuntu đã được phát hành. Tôi nghĩ rằng nó hoạt động tốt ở đó.
Alan Pearce

+1 cho tôi xem WenQuanYi Zen Hei Mono, phông chữ đó thật tuyệt vời. Tôi gần như chắc chắn sẽ sử dụng nó trong luận án của mình. Phụ thuộc vào mức độ nó được in - trên màn hình trông tuyệt vời và không chiếm nhiều vị trí ngang, điều này rất quan trọng trong in ấn.
Konrad Rudolph

9
Thực sự, chỉ có một điểm béo lớn so với tỷ lệ: bạn thực sự không thể căn chỉnh vì không ai quan tâm đến các bàn đàn hồi. Điều này hoàn toàn kỳ quặc, được đưa ra làm thế nào nó mang lại lợi ích cho cả những người khó tính đơn cách và những người thực sự thích đọc các phông chữ có chiều rộng thay đổi đẹp mắt. Thôi nào, thế giới! Tabstops đàn hồi!
Roman Starkov

7
@romkyns: Áp dụng một kiểu thụt lề không dựa vào việc xếp hàng với các dòng khác. Đơn giản.
Zan Lynx

4
@ZanLynx Tôi đã làm, vì tôi thích phông chữ tỷ lệ hơn tôi thích căn chỉnh dọc ở những nơi khác ngoài điểm bắt đầu của dòng.
Roman Starkov

29

Có một lý do khiến cho thực tế không thể sử dụng các phông chữ ngoài mã đơn cách để mã hóa, nhưng không được đề cập trong các câu trả lời khác: các lựa chọn hình chữ nhật .

Tính năng này, thường không hữu ích và không được biết đến nhiều khi làm việc với văn bản thông thường, rất cần thiết cho các nhà phát triển. Bạn có thể tưởng tượng vô số tình huống: xóa //nhận xét trên một số dòng, thêm dấu ngoặc đơn hoặc các ký tự khác, v.v. Điều này thậm chí còn có giá trị hơn với sự hỗ trợ nâng cao của các lựa chọn hình chữ nhật, như trong Visual Studio 2010, nơi bạn không chỉ có thể chọn và xóa văn bản, nhưng chọn và thay thế nó.

Hãy lấy một ví dụ:

private IEnumerable<SELove> StackExchangeRocks()
{
    var howILoveSEWebsites = new []
    {
        new SELove { SiteName = "Stack Overflow", MyReputation = 5269,  MyRating = Rating.Outstanding, },
        new SELove { SiteName = "Programmers",    MyReputation = 16937, MyRating = Rating.Outstanding, },
        new SELove { SiteName = "Super User",     MyReputation = 650,   MyRating = Rating.QuiteGood,   },
        new SELove { SiteName = "Server Fault",   MyReputation = 489,   MyRating = Rating.Good,        },
        // Initialize other websites here.
    };

    return howILoveSEWebsites.OrderByDescending(c => c.MyRating);
}

private class SELove
{
    public string SiteName { get; set; }
    public int MyReputation { get; set; }
    public Rating MyRating { get; set; }
}

private enum Rating
{
    Outstanding,
    Good,
    QuiteGood,
}

Trong mã kế thừa này, tôi muốn thay thế xếp hạng trong mã bằng phương pháp sẽ tải xếp hạng của tôi từ các trang web Stack Exchange, để có thể luôn có dữ liệu cập nhật. Tôi bắt đầu cấu trúc lại MyReputationtài sản và bây giờ tôi muốn xóa phần khởi tạo, trong phạm vi. Hãy tưởng tượng rằng tôi không có bốn, nhưng tất cả 84 trang web SE.

Đây là những gì xảy ra khi sử dụng Consolas , một phông chữ đơn cách. Tôi nhấn Backspace, và đó là tất cả, tôi có thể dành thời gian còn lại để làm một cái gì đó thực sự hữu ích.

Hình ảnh cho thấy với Consolas, hình chữ nhật chọn thuộc tính danh tiếng.

Và đây là điều tương tự với Segoe UI . Ôi!

Hình ảnh cho thấy với Segoe UI, một số thuộc tính danh tiếng chỉ được chọn một phần, trong khi trên các dòng khác, phần đầu của thuộc tính xếp hạng được chọn.


9
Điều này xảy ra bởi vì bạn đã sử dụng khoảng cách xảy ra để khớp với phông chữ không gian. Nếu bạn có khoảng cách phù hợp với phông chữ tỷ lệ, bạn sẽ không gặp vấn đề này.
Kos

6
@Kos: vì vậy thay vì nhấn, giả sử, ba tab, bạn sẽ nhấn mười lăm lần phím cách, hơn là thông báo rằng bạn đã nhập quá nhiều và xóa khoảng trắng cuối cùng? Có vẻ hơi phức tạp, bạn nghĩ sao?
Arseni Mourzenko

6
Eclipse thực sự hỗ trợ sử dụng một phông chữ khác nhau cho chế độ chọn hình chữ nhật, điều này làm cho vấn đề này ít gặp vấn đề hơn.
Nicholas

8
@Kos RE: "khoảng cách phù hợp với phông chữ tỷ lệ": Nhưng sau đó nếu một lập trình viên khác sử dụng một phông chữ khác nhau trên cùng một tệp, nó sẽ không xếp hàng. Nếu tất cả các biên tập viên sử dụng phông chữ đơn cách, nó sẽ luôn xếp hàng (giả sử mã không lạm dụng các tab để căn chỉnh).
Max Nanasy

5
Tôi đang sử dụng một phông chữ tỷ lệ trong 2 năm mà không có bất kỳ tab đàn hồi nào. Tôi không sử dụng các lựa chọn hình chữ nhật bởi vì có một thứ khác thay thế hoàn toàn nó trong hầu hết các IDE: lựa chọn nhiều caret. Trong ví dụ này, tôi sẽ chọn "MyReputing =", sau đó nhấn Chọn lần xuất hiện tiếp theo bằng CTRL-DSublimeText và VSCode, ALT-Jtrong trình chỉnh sửa IntelliJ / JetBrains. Tiếp theo, SHIFT-CTRL-RIGHT ARROWđể mở rộng lựa chọn sang mã thông báo tiếp theo ở bên phải và thế là xong. Ưu điểm chính là không ai cần căn chỉnh công cụ để chỉnh sửa. Nhược điểm, nếu bạn có một cái gì đó phù hợp, nó sẽ không còn.
Hay

15

Tôi đã từng sử dụng một phông chữ tỷ lệ, chủ yếu là vì tôi thấy dấu câu thực sự dễ phân biệt hơn, nhưng theo thời gian tôi đã từ bỏ vì không ai khác làm điều đó và mọi người vô tình giả định các phông chữ cách đều nhau (như bài viết trên wikipedia, cố gắng làm bảng định dạng, nghệ thuật ascii trong ý kiến ​​và như vậy).

Thêm vào đó, các vấn đề trong Visual Studio , mà Microsoft không muốn khắc phục, về cơ bản khiến cho không thể sử dụng các phông chữ tỷ lệ được thiết kế tốt.


9
Yêu bình luận của bạn mini-battle với microsoft về lỗi đó. Và câu trả lời vui vẻ của họ về cơ bản là "Xin chào! Cảm ơn! Rất vui được gặp bạn! Chúng tôi sẽ không làm gì cả. OK, cảm ơn vì đã trò chuyện với bạn!" Chỉ cần tưởng tượng nếu mọi người hành động như vậy trong cuộc sống thực ...
danio

2
Bạn nhận được sự ủng hộ vì sự thông cảm, mặc dù tôi không sử dụng phông chữ theo tỷ lệ cho một số lý do bạn trích dẫn, người đánh máy bên trong của tôi liên tục khao khát sự hỗ trợ của biên tập viên, trong thiết kế và lập trình.
Jon Purdy

Thật kỳ lạ, tôi chỉ nghĩ rằng dấu câu thực sự khó phân biệt hơn (đặc biệt là các điểm dừng hoàn toàn) vì nó chiếm ít không gian hơn. Tôi cũng nhớ rằng Notepad ++ đã sử dụng Comic Sans MS trên các bình luận trong thời gian dài nhất.
DisgruntledGoat

6
Nếu bạn thấy dấu câu khó xác định trong một phông chữ đơn cách, có các phông chữ đơn cách khác - điều đó không có nghĩa là bạn cần sử dụng một phông chữ tỷ lệ.
Không ai là

Chính xác cho dấu chấm câu tốt hơn, đôi khi tôi sử dụng EnvyCode Một hoặc B .
zanlok

9

Cá nhân tôi không quan tâm. Miễn là bạn giữ các tab của mình được căn chỉnh và phông chữ dễ đọc, tôi không quan tâm đến việc liệu tôi có sử dụng khoảng cách đơn cách, tỷ lệ hoặc một số khoảng cách khác không. Chỉ cần không bắt đầu thay thế các tab của tôi bằng dấu cách và bạn sẽ không có cãi nhau với tôi.


3
Tôi hoàn toàn đồng ý. Và với các tab (trái ngược với không gian được mã hóa cứng), bạn có thể chuyển đổi giữa phông chữ đơn cách và phông chữ tỷ lệ và điều chỉnh độ rộng của tab cho phù hợp. Tuy nhiên, điều tôi chưa thấy là một trình chỉnh sửa trong đó bạn có thể đặt độ rộng tab theo đơn vị EM.
Tháng Tám Karlstrom ngày 8 tháng

6

Tôi sử dụng một phông chữ tỷ lệ (Arial là phông chữ tốt nhất mà tôi đã tìm thấy cho đến nay, Verdana là một á quân thân thiết) và thành thật mà nói tôi vẫn còn băn khoăn rằng mọi người sử dụng phông chữ có chiều rộng cố định; Tại sao bạn lại muốn hy sinh khả năng đọc như vậy? Tôi có thể hiểu nếu định dạng bảng là mong muốn, nhưng không, vì nó tạo ra một cơn ác mộng bảo trì bất kể phông chữ.


4
Tôi ngạc nhiên khi bạn thích Arial và Verdana. Tôi thấy họ hơi thô bạo và thiếu chuyên nghiệp. Bạn đã thử Calibri chưa?
Timwi

2
Tôi đang sử dụng 8pt Verdana. Tên định danh dài dễ đọc hơn. Tôi có thể xem 70 dòng mã mà không cần cuộn và các dòng ngắn hơn nhiều, vì vậy mã là một cột hẹp, giống như trong một tờ báo. Điều này cho phép tôi chia chế độ xem của trình soạn thảo thành hai cột dọc: Tôi xem khai báo trong một chế độ xem và viết mã ở chế độ khác. Ngoài ra khi gỡ lỗi, màn hình đầy các cửa sổ gỡ lỗi, chế độ xem mã phù hợp với không gian nhỏ. Sử dụng phông chữ tỷ lệ là loại bỏ mong muốn sắp xếp theo chiều dọc và đặt các hộp dấu hoa thị xung quanh các bình luận.
Calmarius

2
Tôi thấy 147 dòng mã trong Visual Studio trên màn hình 1920x1200 xoay 90 ° cho chế độ dọc, sử dụng với phông chữ Lucida Console.
zanlok

158 dòng có phông chữ Monaco trong Vim ... Màn hình của tôi thậm chí không phải là HD
Mark K Cowan

4

Tôi nhớ trong cuốn sách của Bjarne Stroustrup Ngôn ngữ lập trình C ++ , các phông chữ cách đều nhau được sử dụng cho mã. (Tôi không thể tìm thấy bất kỳ trang mẫu nào trên web)

Tôi không nhớ lý do chính xác, nhưng nghĩ rằng anh ấy đã đề cập đến điều này và một thay đổi khác (tôi nghĩ chính ngôn ngữ C ++) như một lời giới thiệu mới trong cuốn sách đó.

Cá nhân, tôi thích những không gian cố định. Consolas là yêu thích của tôi.


1
Kiểm tra trang 5 của Phiên bản đặc biệt của tôi: phông chữ tỷ lệ thường được coi là tốt hơn cho văn bản, sử dụng chúng cho phép ít ngắt dòng phi logic hơn và hầu hết mọi người đã quen với nó. Tôi thấy nó dễ đọc. Stroustrup đang trình bày mã ở đây, không cố gắng tạo mã và điều đó có thể làm cho mọi thứ trở nên khác biệt.
David Thornley

4
@David, vâng, anh ấy đang trình bày mã. Nhưng, nó được trình bày để "đọc" và câu hỏi cố định so với tỷ lệ là dành cho "đọc" mã, IMHO.
Nivas

4

Đối với các ngôn ngữ có dòng ngắn và nhiều không gian mở, tôi thích phông chữ đơn cách. Tôi thấy rằng các phông chữ có chiều rộng thay đổi có thể cải thiện khả năng đọc nơi bạn có các dòng dài và cú pháp dày đặc.

Vấn đề với hầu hết các phông chữ tỷ lệ là chúng không được thiết kế để lập trình. Trang này hiển thị một số phông chữ được.

Cắt phông


4
liên kết chết với Mã Google :(
Florian Castellane

2

Các môi trường Smalltalk như Pharo sử dụng phông chữ tỷ lệ và do phong cách ngôn ngữ, nó trông rất tốt ở đó. Nhưng trong các ngôn ngữ kiểu C như Go hoặc các ngôn ngữ khác như Erlang hoặc Python, tôi thích các phông chữ đơn cách hơn.


2

Tôi đã dành một chút thời gian để tìm một phông chữ tốt, dễ đọc cho Eclipse một thời gian trước và dưới XP tôi đã sử dụng Verdana khá lâu. Consolas giải quyết điều đó bởi vì nó thực sự tuyệt vời cho lập trình.

Đây là những phát hiện của tôi:

  • Hầu hết các phông chữ tỷ lệ được thiết kế cho văn xuôi và chỉ có một dấu chấm câu nhỏ (mà lần lượt thường là một hoặc hiếm khi hai ký tự). Họ ngôn ngữ C có rất nhiều dấu câu, điều này đơn giản là không - theo ý kiến ​​của tôi - nhìn hay và khó đọc hơn mức cần thiết.
  • Các ký tự có độ dài thay đổi có nghĩa là độ dài của các dòng khác nhau. Điều này khiến cho gần như không thể đoán được con trỏ sẽ kết thúc khi điều hướng bằng các nút mũi tên. Tôi thấy điều này gây phiền nhiễu.
  • Khoảng cách dọc vấn đề quá. Điều này thường không phải là một cái gì đó có thể bị ghi đè dễ dàng và hầu hết các phông chữ tỷ lệ có ít chỗ giữa các dòng hơn tôi muốn.
  • Rất ít IDE được thử nghiệm với phông chữ tỷ lệ. Điều này tạo chỗ cho các lỗi tinh vi như đặt con trỏ vào vị trí sai, ký tự sơn lại không chính xác và tương tự.

Do đó tôi thấy rằng nó không đáng để tôi gặp rắc rối.


Lưu ý về căn chỉnh và các bố cục khác: Tôi đã đặt Eclipse để tự động định dạng từng tệp cho mỗi lần lưu, vì vậy tất cả các bố cục ưa thích sẽ tự động được đặt lại. Eclipse sử dụng các tab thay vì nhiều khoảng trắng và chúng có thể được định vị chính xác ngay cả với các phông chữ tỷ lệ. Do đó bố trí bộ định dạng thể chồng lên nhau, nhưng chúng tôi sử dụng cấu hình bộ định dạng tiêu chuẩn không có điều đó.

Tôi tin rằng việc thực thi định dạng tự động cho mọi người trên mỗi lần lưu sẽ giảm thiểu các lỗi tích cực trong hệ thống kiểm soát nguồn, khi thực hiện phân tích pháp y.


0

Không bao giờ, bởi vì phông chữ Monospaces cho phép tôi so sánh các thuộc tính khác nhau.

So sánh:

name1 = ["William", "Shakespear", 1564, "Peotry"]

name2 = ["John", "Locke", 1632, "Triết học"]

name3 = ["Jonathan", "Littell", 1967, "văn xuôi"]

Đến:

name1=["William",  "Shakespear", 1564, "Peotry"     ]
name2=["John",     "Locke",      1632, "Philosophy" ]
name3=["Jonathan", "Littell",    1967, "Prose"      ]

Các phông chữ tỷ lệ không thể đặt các thuộc tính tương đương chính xác lên nhau.


2
Tôi muốn biết môi trường này là vấn đề gì đối với bạn. Bạn có thể sử dụng các tab có cả phông chữ theo tỷ lệ và chiều rộng cố định để sắp xếp chúng theo cột. Trường hợp vấn đề phát sinh là nếu bạn sử dụng dấu cách thay vì tab.
cám dỗ

2
@teemar: xem xét "iii12345", "AAA12345" và "nnn12354" chồng lên nhau. Lỗi ("345") dễ phát hiện hơn nhiều. bạn không thể đặt các tab ở giữa một giá trị.
Adam Matan

1
@teemar Tab không được Python khuyến nghị và chiều rộng của chúng khác nhau ở các trình soạn thảo khác nhau, điều này có thể dẫn đến mã bị sai lệch.
Adam Matan

2
@Adam Matan Đó chính xác là lý do tại sao bạn không nên định dạng ưa thích.
Tháng Tám Karlstrom ngày 8 tháng

0

Mặc dù tôi cảm thấy rằng phông chữ tỷ lệ đẹp hơn, nhưng trong một số trong số chúng, đặc biệt là phông chữ sans-serif, không thể thấy sự khác biệt giữa chữ "I" và "l". Đợi đã, tôi đã đặt tên biến đó là gì?


2
Verdana có serifs trên I để phân biệt dễ dàng hơn.
Calmarius

1
0 và O là một vấn đề lớn khác. Cũng 'vs `và. vs, là tốt. Đôi khi & và $ là một vấn đề (đáng lo ngại trong perl / php) Tuy nhiên, Verdana tốt cho hầu hết các mục trên mặc dù không tuyệt vời ở 0s. Đáng buồn thay, trên các dự án hiện có với các tab trộn lẫn với không gian xấu, tôi thường từ bỏ và sử dụng Bảng điều khiển Lucida. Tuy nhiên, nếu bạn hỏi về cách đặt tên biến, bạn không sử dụng hoàn thành mã hiện đại hoặc ít nhất là sao chép / dán như bạn nên.
zanlok

Một phông chữ tỷ lệ mà tôi biết có 0Oo1lLiI không rõ ràng là "Latin Modern Mono Prop" của TeX, một họ hàng tương đối cách nhau của "Latin Modern Mono" được thiết kế hoàn toàn cho mã (tuy nhiên, tôi thấy kết xuất hơi mờ) . Dấu câu vẫn là một vấn đề, có quá ít khoảng cách cho tầm quan trọng của nó trong mã IMHO và tạo ra sự mơ hồ, ví dụ như hai trích dẫn đơn so với một trích dẫn kép: '' vs ",'' vs "
Beni Cherniavsky-Paskin
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.