Tôi đang đọc Code Complete và trong chương về bố cục và phong cách, anh ấy đã dự đoán rằng các trình soạn thảo mã sẽ sử dụng một số loại định dạng văn bản phong phú. Điều đó có nghĩa là, thay vì mã trông như thế này

Procedure ResolveCollisions
{ Performs a posteriori collision resolution through spatial partitioning algoritm }
(
  CurrentMap : SpriteContext,
  PotentialColliders: SpriteList
)
var Collider  : Sprite, 
    Collidee  : Sprite, 
    Collision : SpriteCollision
begin
  DoStuff();
end.

nó có thể trông giống như thế này:

Thủ tục ResolveCollisions

Thực hiện độ phân giải va chạm posteriori thông qua thuật toán phân vùng không gian

Thông số

• CurrentMap : SpriteContext
• PotentialColliders : SpriteList

Biến cục bộ

• Collider : Sprite
• Collidee : Sprite
• Collision : SpriteCollision

    DoStuff();

Tôi đã thấy tô màu cú pháp và tô sáng và thậm chí là dấu ngoặc đơn, nhưng không có gì giống như thế này trong mã thực tế. Tôi đã tự hỏi nếu loại điều này thực sự tồn tại, hoặc có lẽ nếu nó được quyết định rằng nó không có đủ lợi ích hoặc đó là một ý tưởng hoàn toàn xấu.

Đã có ai trong số các bạn nhìn thấy mã được định dạng phong phú như thế này trước đây chưa, hoặc biết liệu ý tưởng đó có từng được xem xét và cuối cùng bị từ chối không?

Không có lý do kỹ thuật mà bạn không thể. Nếu các trình soạn thảo văn bản có thể làm nổi bật cú pháp, thì chúng có thể dễ dàng thay đổi các khía cạnh khác của màn hình để làm nổi bật mã.

Tuy nhiên, đó là một điều để có bất cứ điều gì đang được gõ thay đổi màu sắc khi biên tập viên tìm ra những gì bạn đang gõ. Có văn bản đột nhiên thay đổi kích thước và nhảy xung quanh trong khi bạn đang gõ sẽ trở nên thực sự đáng ghét.

Tuy nhiên, đối với hiển thị mã 'tĩnh', bạn có thể dễ dàng làm đẹp mã nguồn. Ví dụ: lấy bất kỳ nguồn chuyển đổi nửa chừng nào -> trình chuyển đổi html và thêm bất kỳ kích thước phông chữ và kiểu nào bạn muốn vào biểu định kiểu và bạn sẽ có mã được định dạng phong phú.

Lý do đơn giản: độc lập biên tập / công cụ.

Khi bạn làm cho bạn mã "giàu" - nó sẽ được gắn với trình soạn thảo mà bạn đã sử dụng - hoặc với những người có thể hiểu mã phong phú. Tất cả các biên tập viên khác không thể xử lý sự phong phú sẽ thể hiện sự vô nghĩa.

Trong cùng một hướng, mã phong phú sẽ không chơi tốt với các công cụ khác. Ví dụ: nếu bạn chỉ thay đổi một số định dạng, thì diff sẽ hiển thị một sự khác biệt, nhưng nó thậm chí không phải là một sự khác biệt mà bạn ít quan tâm nhất.

Và những gì về kiểm soát phiên bản? Làm thế nào bạn sẽ bảo nó bỏ qua tất cả các thay đổi trong định dạng và xem các tệp chỉ được sửa đổi khi có một số thay đổi "thực".

Cuối cùng tôi đoán, toàn bộ quan điểm của mã phong phú là khả năng đọc - và vì thế, tôi nghĩ các bình luận tốt hơn (và hơn thế nữa), tên định danh logic và thụt đầu dòng nhất quán sẽ đủ.

Về bản chất, văn bản lập trình được xử lý tốt nhất dưới dạng văn bản thuần túy - những gì bạn đang thấy là những gì thực tế. ( cũng phù hợp với ý tưởng Pythonic rõ ràng tốt hơn ngầm định )

Có lẽ mã được định dạng phong phú đã không bị bắt bởi vì nó không phải là một ý tưởng tuyệt vời. Cá nhân, tôi không thích những gì tôi thấy trong ví dụ bạn cung cấp. Tôi sử dụng tô màu và tô sáng cú pháp, nhưng định dạng đó quá phức tạp và nó sai lệch quá nhiều so với cách tôi thường thấy và viết mã.

Tại sao nó không tồn tại? Không có nhu cầu / nhu cầu cho nó.

Các biên tập viên hiện tại có thể đáp ứng nhu cầu của các lập trình viên với việc làm nổi bật cú pháp và một số tùy chọn phong cách nhỏ khác. Đó không phải là "văn bản phong phú" rồi sao?

Điều này đã tồn tại cho LaTeX trong chế độ AucTeX cho Emacs. Tiêu đề của phần có kích thước lớn hơn, phụ và siêu ký tự được thay đổi kích thước phù hợp và bạn thậm chí có thể có ít bản xem trước của toán học (và có thể cả các môi trường khác như Thuật toán).

Điều này là tốt cho LaTeX vì ánh xạ từ các mã để đầu ra thường là nhiều hơn đơn giản hơn so với các chương trình khác; Tôi nghĩ rằng tôi hoàn toàn không thích điều đó đối với các ngôn ngữ có mục đích chung hơn.

Một điều khác mà Emacs có thể làm là thay thế các biểu tượng như ->và forallbằng →và ∀tương ứng trong Haskell. Có rất ít lý do loại điều này không thể được mở rộng để thực hiện định dạng như bạn đang đề xuất ngoại trừ việc nó không cần thiết ở Haskell.

Cách đây một thời gian, tôi đã hỏi câu hỏi này về định dạng mã, hỏi liệu các lập trình viên có muốn mã của họ được định dạng khi họ gõ không.

Câu hỏi của tôi chỉ đề cập đến khía cạnh thụt lề của định dạng, nhưng một số câu trả lời cũng có thể áp dụng cho định dạng mã nói chung. Tình cảm chung trong các câu trả lời cho thấy các lập trình viên phản đối việc mất quyền kiểm soát tuyệt đối về cách trình bày mã của họ.

Kinh nghiệm cá nhân của tôi đã khá khác nhau. Mặc dù tôi thường sử dụng các công cụ có sẵn công khai, đôi khi tôi cần phải viết XSLT trong trình chỉnh sửa bespoke của riêng mình. Trình chỉnh sửa này định dạng mã khi tôi nhập bằng cách thụt lề trái để tôi không gặp vấn đề với khoảng trắng không mong muốn (có ý nghĩa trong XSLT) và cho phép mã của tôi được bọc từ mà vẫn duy trì định dạng. Tôi thấy trải nghiệm khá tự nhiên, kiểu định dạng được điều khiển bởi ngữ cảnh và vị trí của nguồn cấp dữ liệu một mình (trải nghiệm này đặc biệt bổ ích khi sử dụng các thiết bị đầu vào cảm ứng).

Nếu XSLT không được cân bằng tốt, định dạng thực sự giúp hiển thị vấn đề nằm ở đâu. Phải mất một thời gian để điều chỉnh mã dịch chuyển theo chiều ngang khi bạn nhập nhưng nó không còn là điều gây xao lãng cho tôi nữa. Tuy nhiên, tôi đã thấy rằng các tính năng định dạng ảnh hưởng đến khoảng cách dọc của XSLT của tôi khiến trình chỉnh sửa gần như không sử dụng được, vì vậy tôi đã vô hiệu hóa các tính năng này.

Để quay trở lại câu hỏi của bạn, tôi nghĩ lý do tại sao định dạng mã phong phú không phổ biến hơn chỉ là vì phải mất một thời gian dài để nhận thức thay đổi trong thế giới lập trình. Thời gian của nó sẽ đến, có thể trùng với thời điểm mà việc chỉnh sửa mã được thực hiện chủ yếu mà không cần bàn phím.

Ngoài ra, trong nhiều ngôn ngữ (Haskell, Ruby, Python, Erlang, CoffeeScript một vài ngôn ngữ khác) thụt đầu dòng rất quan trọng. Vì vậy, nếu bạn đang thay đổi kích thước phông chữ, có thể rất khó để tìm ra.

Chủ yếu là truyền thống của nó. Tôi đã lập trình chuyên nghiệp được gần 20 năm và tôi nghi ngờ nó sẽ khiến tôi phát điên. Tôi viết sách bằng Emacs hoặc VI bằng sách giáo khoa, vì vậy tôi không phải là người hâm mộ WYSIWIG

CWEB của Knuth thực hiện điều này, nhưng nó chỉ hoạt động cho C / C ++ và Pascal. - Bạn nên xem thử mặc dù nó khá gọn gàng. Có hai chương trình: ctanglevà cweavekết hợp / tách các tệp CWEB thành TeX và C tương ứng.

Đã có ai trong số các bạn nhìn thấy mã được định dạng phong phú như thế này trước đây chưa, hoặc biết liệu ý tưởng đó có từng được xem xét và cuối cùng bị từ chối không?

Chắc chắn rồi. Xcode hỗ trợ các kiểu ngoài màu đơn giản cho các cú pháp khác nhau:

Đã lâu rồi tôi mới sử dụng nó, nhưng tôi nghĩ Metrowerks CodeWar Warrior cũng hỗ trợ văn bản theo kiểu, và đó là hơn 10 năm trước.

Tuy nhiên, bạn không muốn quá nhiệt tình với các kiểu - bất kỳ văn bản, mã nguồn nào khác, có thể khó đọc hơn khi các kiểu khác nhau quá nhiều. Cụ thể, tôi nghĩ rằng kích thước trộn là gây mất tập trung và bất cứ điều gì khiến các cột không xếp hàng đều gây khó chịu. Có một lý do hầu hết các lập trình viên vẫn sử dụng phông chữ đơn cách.

Một câu hỏi khác là liệu văn bản theo kiểu có nên được sử dụng như một phần của cú pháp ngôn ngữ hay không. Ví dụ, trình biên dịch có nên sử dụng thực tế là một số văn bản được tạo kiểu theo một cách nhất định để xác định rằng văn bản là một khai báo hàm không? Điều đó thoạt nghe có vẻ điên rồ, nhưng các ngôn ngữ như Python và Fortran đã sử dụng thụt lề làm cú pháp. Tuy nhiên, tôi nghĩ nhiều khả năng chúng ta sẽ tiếp tục thấy phong cách được điều khiển bởi cú pháp thay vì ngược lại. Có rất nhiều lợi ích đến từ việc có thể sử dụng văn bản đơn giản (trình biên dịch đơn giản hơn, độc lập nền tảng, tùy chọn lập trình viên) và các truyền thống khác đã phát triển để làm cho mã có thể đọc được khi không có kiểu (thụt lề, dòng trống, ký tự đánh dấu và tính năng soạn thảo như gấp mã và menu điều hướng).

Tôi nghĩ rằng định dạng phong phú của mã nguồn không phổ biến lắm vì nó được dùng để nhập thông tin, trong đó cấu trúc và ý nghĩa quan trọng hơn nhiều (và cũng dễ gõ hơn). Phông chữ, biểu tượng đặc biệt thêm và khoảng trắng chỉ thêm nhiễu hình ảnh không cần thiết. Nó có thể thích hợp cho các tài liệu được tạo ra mặc dù.

Không bao giờ kết thúc cuộc chiến ngọn lửa về cùng một chủ đề trong thế giới sắp chữ giữa những người thích các biên tập viên WYSIWYG (như MS Word) và các hệ thống như TeX (LaTeX).

Nói chung, không có câu trả lời dứt khoát. Tất cả phụ thuộc vào công cụ, trường hợp sử dụng và sở thích cá nhân.

Các công cụ như Doxygen hoặc JavaDoc đã định dạng mã văn bản phong phú. Họ thêm siêu văn bản mã cho mục đích duyệt web. Bạn không cần phải chèn các thẻ đặc biệt cho định dạng cơ bản.

Đây không phải là WYSIWYG.

Tôi sợ nói rằng điều này không tồn tại.

Trước đây tôi đã từng làm việc với một số Centura (còn được gọi là Gupta hoặc SQL / Windows - một " 4GL cũ" ). Thật sự không thể chỉnh sửa mã Centura trong một trình chỉnh sửa tiêu chuẩn như notepad làm ở mức độ định dạng cực cao cần thiết.

Mặc dù có vẻ như đó là một ý tưởng tốt để có một tệp nguồn được định dạng như thế này, tôi thấy việc phát triển khá hạn chế và đau đớn.

Ngoài ra, định dạng thường gây ra sự cố khi hợp nhất trong kiểm soát nguồn.

Ngoài các câu trả lời khác, tôi muốn chỉ ra rằng bên cạnh những khó khăn kỹ thuật trong việc sử dụng định dạng phong phú, nó cũng là đối tượng của sở thích cá nhân.

Nếu bạn chỉnh sửa văn bản thuần túy, bạn có thể chọn phông chữ và màu bạn thích và chúng được đặt tự động. Nếu bạn chỉnh sửa văn bản có định dạng, nếu bạn không thích màu sắc và phông chữ cụ thể được đặt thủ công thì sao?

Tôi nghĩ điều này là do chưa có ai tách mã đọc và viết mã. Ít nhất nó không trở thành xu hướng. Đôi khi bạn phải đọc mã bạn đã chạm từ lâu hoặc mã được tạo bởi các nhà phát triển khác. Bạn có thể sẽ phải mất nhiều thời gian cho đến khi sẵn sàng thay đổi một byte trong nguồn này. Đây có thể là chế độ "đọc" có thể làm bất cứ điều gì cần thiết để dễ hiểu hơn (cỡ chữ, định dạng lại, tập lệnh phụ, siêu tập lệnh, v.v.). Khi bạn đã sẵn sàng, trình chỉnh sửa có thể chuyển sang chế độ "ghi" và ít hạn chế hơn và tuân theo "quy tắc ít bất ngờ nhất"