Những ưu và nhược điểm của ngôn ngữ sử dụng khoảng trắng so với {} 'để chỉ phạm vi là gì? [đóng cửa]

Dường như có một cuộc xung đột về việc sử dụng khoảng trắng hoặc mã thông báo như dấu ngoặc để biểu thị phạm vi. Tôi đã thấy nhiều lời khen ngợi giải pháp của python cho vấn đề thụt đầu dòng không nhất quán, nhưng nhiều người không đồng ý:

Bất kỳ ngôn ngữ nào có khoảng trắng là mã thông báo cần phải chết.

đăng sau cùng câu trả lời:

Tôi đã sắp xếp các mã thông báo chống khoảng trắng, cho đến khi tôi thực sự thử nó. Có lẽ nó giúp bố cục không gian trắng cá nhân của tôi khá phù hợp với những gì mọi người ở vùng đất trăn sử dụng. Có lẽ tôi hơi tối giản, nhưng nếu bạn định thụt lề, tại sao phải bận tâm với {} s?

Tôi có thể thấy một số đối số rõ ràng cho mỗi bên:

sử dụng khoảng trắng:

• giúp giảm sự thụt dòng không nhất quán trong mã
• xóa màn hình bằng cách thay thế các mã thông báo hiển thị bằng khoảng trắng để phục vụ cùng một mục đích

sử dụng mã thông báo:

• dễ dàng hơn nhiều để cắt và dán mã đến các cấp độ khác nhau (bạn không phải sửa lỗi thụt lề)
• phù hợp hơn. Một số trình soạn thảo văn bản hiển thị khoảng trắng khác nhau.
• phổ biến hơn hiện nay.

Có điểm nào tôi bỏ lỡ không? Bạn thích cái nào hơn Bất kỳ lời nói khôn ngoan sau khi đã làm việc với người này hay người kia trong một thời gian dài?

Tái bút Tôi ghét nó khi các ngôn ngữ không sử dụng cùng một mã thông báo cho mỗi cấu trúc điều khiển. VB thực sự khó chịu với các câu lệnh End Ifvà End Whilecâu lệnh của nó , hầu hết các ngôn ngữ khác chỉ sử dụng {} 'cho mọi thứ. Nhưng có lẽ đó là một chủ đề cho một câu hỏi khác ...

Tôi nghĩ rằng rất nhiều người trong số chúng tôi lập trình viên (bao gồm cả bản thân tôi) có xu hướng "logic hóa" mọi quyết định. Điều đó tốt, nhưng không phải câu hỏi nào cũng có câu trả lời hợp lý. Ví dụ, tôi nghi ngờ rằng các đầu bếp đăng câu hỏi trên Chefoverflow (nếu điều đó tồn tại) yêu cầu những ưu và nhược điểm của bánh táo so với bánh anh đào. Đó là một câu hỏi mà bạn thích tốt hơn.

Với ý nghĩ đó, tôi nghĩ câu trả lời đơn giản nhất là nói "Một số người thích niềng răng, một số người thích khoảng trắng" và để nó ở đó.

Có nguy cơ nghe giống như một fanboy hoàn toàn, tôi nghĩ rằng tất cả những người tuyên bố rằng khoảng trắng giúp giảm bớt sự thụt dòng không nhất quán trong mã Code chưa bao giờ sử dụng Visual Studio. Với một lệnh duy nhất (tôi nghĩ rằng phím tắt mặc định là Ctrl + K, D), tất cả các vết lõm là nhất quán tức thời¹. Hơn nữa, khi dán mã, vết lõm được sửa ngay lập tức mà không phải làm gì cả, và điều tương tự cũng đúng khi viết mã mới hoặc khi bọc một thứ gì đó trong một ifhoặc một khối khác (định dạng lại xảy ra khi }gõ). Hơn nữa, nhấn Enter sau khi hoàn thành câu lệnh luôn đặt con trỏ ở mức thụt lề chính xác cho câu lệnh tiếp theo, ngay cả khi câu lệnh trước đó được thụt lề thêm vì mộtifhoặc tương tự, làm cho rất khó để vô tình nghĩ rằng một tuyên bố vẫn còn dưới một ifkhi nó không.

Điểm tôi đang cố gắng thực hiện không phải là Visual Studio là tuyệt vời. Điểm tôi đang cố gắng thực hiện là IDE có thể tự động sửa lỗi thụt lề (và các vấn đề định dạng khác), nhưng chỉ khi ý nghĩa của chương trình không phụ thuộc vào định dạng của nó. Điều này cung cấp cho lập trình viên một cơ hội lớn hơn để tập trung vào nhiệm vụ lập trình thực tế. Một cú pháp như Python là phản tác dụng: không thể viết một IDE có thể khắc phục lỗi khắc phục mã xác thực mã Python vì chính thụt chỉ định một số ngữ nghĩa.

¹ _{(Tôi biết có một trường hợp đặc biệt mà VS từ chối định dạng lại, cụ thể là literals mảng mà span nhiều dòng, nhưng đó là bên cạnh điểm.)}

Cá nhân tôi thấy tôi cần dòng trống được giới thiệu bằng cách có mã thông báo trên dòng riêng của nó để khiến tâm trí tôi nhận ra rằng mã nằm trong phạm vi khác.

Tôi ghét nó khi ở python mọi người đi:

if something
    do something
    do somethingelse

    cleanup
else
    do the other thing

Trong khi ở vùng đất token tôi ghét khi mọi người sao chép và dán và không dọn sạch vết lõm ,

if something
{
I have been too lazy
      {
            to clean up
            }
what I pasted
}

hoặc không sử dụng một dòng riêng cho mã thông báo .

if something {
    I find this confusing
}
else {
especially when combined with the previous 
do something
}

Tôi có thể đọc cả ba, nhưng chúng không như tôi mong đợi và tôi phải nỗ lực để phân tích chúng và như Joel nói khi mọi thứ không hoạt động như bạn mong đợi, điều đó làm bạn thất vọng.

Pro: Không có cuộc chiến thần thánh thụt lề / uốn cong trong thế giới Python theo như tôi biết. Đưa ra quyết định này thay mặt cho các nhà phát triển có lẽ đã cứu được một số nỗi đau.

Con: Hàm ẩn danh được giới hạn trong một dòng. Nghe có vẻ ổn, nhưng tôi thường thấy mình viết lên nhiều dòng lambdatrong Scheme (chủ yếu để cung cấp cho maphoặc applyở một nơi chính xác, vì vậy sẽ không có ý nghĩa gì khi khai báo riêng).

Vấn đề tôi tìm thấy với một ngôn ngữ khoảng trắng là với các biểu thức điều kiện nhiều trang. Thêm một dòng ở giữa trang hai và thoát khỏi một khoảng trống ở giữa tất cả các mớ hỗn độn, có thể làm thay đổi mạnh mẽ logic của mã của bạn. Và ngay cả khi mã của ai đó là "chính xác", cố gắng đọc nó sẽ tạo ra một trò chơi đoán khủng khiếp. Cái "nếu" này là "cái khác" để làm gì? Tôi có thể đếm niềng răng dễ dàng hơn nhiều so với tôi có thể đếm các ký tự trống vô hình. Và các máy móc đăng bài trên trang web này tiếp tục đập chúng vào một không gian duy nhất.

IMHO "{{{{{" is more reliable than "     ".

{} thêm dự phòng. Quá nhiều dư thừa là xấu, quá ít là xấu. Và hướng dẫn nhập nó là xấu, đặc biệt. Nếu nó khó sử dụng.

Vì vậy, trong thời điểm xấu / không có IDE, kiểu khoảng trắng có thể tốt hơn một chút. Nhưng với IDE mạnh mẽ, niềng răng tốt hơn.

Tôi không nghĩ rằng nó thực sự so với .
Pythoneers thường chỉ trích các lập trình viên niềng răng như thể họ sẽ dễ dàng vi phạm thụt vì họ có thể.
Trong thực tế, tôi luôn sử dụng thụt đầu dòng nhất quán 100% ngay cả trước khi biết về Python và phạm vi thụt lề của nó.

Thực tế là các ngôn ngữ niềng răng cũng có thể áp đặt thụt lề chính xác trong trình biên dịch và chúng ta sẽ có cả hai thế giới tốt nhất. Xem? không so với tất cả.

Pythoneers sẽ lập luận rằng niềng răng là vô dụng khi thụt là một phần của cú pháp, nhưng chúng không phải, niềng răng cải thiện khả năng đọc. Tôi đã thử lập trình Python và đó là một ngôn ngữ rất thú vị đối với tôi, nhưng bạn đã thử có if-elifchuỗi hơn 2 hoặc 3 cấp độ thụt lề chưa? Trông chúng không còn gọn gàng nữa.

PS: Tôi đã viết niềng răng nhưng theo cách tổng quát hơn, ý tôi là mã thông báo phân cách. Cú đúp mở đầu có thể được coi là dư thừa, nhưng một ngôn ngữ có thể đi như thế này (thực tế tôi chắc chắn có những ngôn ngữ chính xác như thế này nhưng tôi không biết rõ về chúng):

if condition:
    statement
    other_statement()
end

PS2: 2019, 4 năm sau câu trả lời này. Tôi đã học Python và hoàn toàn quen với việc thụt ngữ nghĩa của nó và không thấy khó đọc chút nào. Đặc biệt với sự trợ giúp của các IDE hiện đại vẽ các thanh dọc để hỗ trợ xác định các khối thụt lề.