Những nhược điểm của tabstops đàn hồi là gì? [đóng cửa]

Nhìn vào đây: một cuộc chiến thần thánh điển hình trên các tab so với không gian .

Bây giờ nhìn vào đây: tabstops đàn hồi . Tất cả các vấn đề được giải quyết, và một loạt các hành vi mới rất hữu ích được thêm vào.

Các tab đàn hồi thậm chí được đề cập trong các tab so với không gian thảo luận? Tại sao không? Có những hạn chế đối với ý tưởng tabstop đàn hồi nghiêm trọng đến mức không ai từng thực hiện chúng trong một trình soạn thảo phổ biến?

EDIT : Tôi xin lỗi vì đã nhấn mạnh quá nhiều vào "tại sao họ không đề cập đến". Đó không thực sự là những gì tôi dự định; Câu hỏi đó thậm chí có thể lạc đề. Điều tôi thực sự muốn nói là, nhược điểm lớn nhất của việc này là gì ngăn cản việc áp dụng rộng rãi hơn một ý tưởng rõ ràng có lợi? (trong một thế giới lý tưởng nơi mọi thứ đã hỗ trợ nó)

(Hóa ra đó đã là một yêu cầu trên Microsoft Connect cho Visual Studio thực hiện các tab đàn hồi , và một yêu cầu trong Eclipse quá. Thêm vào đó là một câu hỏi hỏi về biên tập viên khác mà thực hiện các tab đàn hồi )

Thánh chiến là chủ quan

Tabstops đàn hồi của Nick là một khái niệm tuyệt vời có thể giúp nhiều người đồng ý về một giải pháp khả thi, mặc dù tôi rất nghi ngờ rằng nó sẽ hoàn toàn chấm dứt Cuộc chiến Thánh này: cuối cùng, đó cũng là vấn đề của hương vị và nhiều lập trình viên sẽ không di chuyển inch từ vị trí của họ về vấn đề này, thậm chí với chi phí thỏa hiệp. Vì vậy, đó sẽ là một lý do đầu tiên.

Chẳng hạn, nhiều người ở phía "khoảng trắng" vẫn sẽ không thích nó vì nó yêu cầu một phần logic bổ sung trong phần mềm của bạn để hiển thị hợp lý (ví dụ: chỉ xem một thay đổi trong chế độ xem web của SCM).

Vấn đề thực hiện

Nhưng lý do rõ ràng nhất chỉ là rào cản kỹ thuật của nó để xâm nhập : đó là một khái niệm khác biệt cơ bản với những gì đã được thực hiện trong một số năm (nếu không phải là hàng thập kỷ) trong các IDE và trình soạn thảo văn bản. Nó sẽ yêu cầu viết lại một số trong số chúng để xử lý các dòng trong một sự kết hợp khá khác nhau, điều này gây khó khăn cho các hệ thống cũ và lớn hơn có khả năng chịu sự ghép nối sâu và chặt chẽ trong mã xử lý dòng của chúng. Đó là, tuy nhiên, dễ dàng hơn rất nhiều để làm gì khi bạn bắt đầu từ đầu (nghĩ về bản demo của Nick hoặc của Go 's tabwriter gói).

Đối với một giai thoại cá nhân, tôi nhớ đã tiếp cận tác giả một lúc trước để hỏi liệu có bất kỳ sự hỗ trợ nào trong tầm nhìn hay không, và trong trường hợp cụ thể này, ông đã đề cập đến điều này vì nó không tầm thường. Ông cũng yêu cầu sự giúp đỡ từ cộng đồng để giúp thực hiện tính năng này và đưa nó đến với công chúng.

Chúng ta có quan tâm đủ không?

Một lý do thứ ba, là một số nhà phát triển không bận tâm đến vấn đề này và không thực sự quan tâm đến mức họ sẽ đi xa hơn để hỗ trợ nỗ lực. Trong hầu hết các trường hợp, xung đột giữa không gian và tab không phải là một công cụ chặn doanh nghiệp, do đó, không có quá nhiều vấn đề đằng sau vấn đề này.

Nếu bạn muốn nó, bạn sẽ phải chiến đấu vì nó. Điều này có thể thực hiện được trong phần mềm nguồn mở. Và nếu bạn thay đổi đủ những thứ này, những nguồn đóng sẽ phải tuân theo nguy cơ mất một số cơ sở người dùng của họ, nếu một phần rất nhỏ của nó.

Vì vậy, nếu bạn muốn nó, hãy giúp Nick một tay.

Nhiều lần tôi đã phải chiến đấu với một trình xử lý văn bản để có được tài liệu theo cách tôi muốn mà không có một số quy tắc tự động ẩn kiểm soát vị trí của các từ của tôi. Tôi không muốn dành một giây để cố gắng tìm ra lý do tại sao biên tập viên cứ khăng khăng đặt những từ đó ở đó.

Đây là lần đầu tiên tôi nghe nói về những điều đó. Không chắc chúng có phải là một ý tưởng tốt hay không nhưng chúng dường như ít được sử dụng vì chúng tôi có các công cụ (chẳng hạn như thụt lề) tự động định dạng mã.

Điều gì xảy ra khi tôi mở các tab đàn hồi thông minh của bạn trong vim và chỉnh sửa nó? Làm tab tự động dọn dẹp hoặc bạn còn lại với một mớ hỗn độn?

Những nhược điểm chính, như tôi thấy chúng có thể phá vỡ các khác biệt, kiểm soát phiên bản và không tương thích với các trình soạn thảo không hỗ trợ chúng. Nó có thể có rất nhiều sửa đổi mã để hỗ trợ chúng và có những điều quan trọng hơn tính năng "một điều tab khác để định dạng mã". Rốt cuộc, tất cả chúng ta đều có thể sử dụng indenttất cả những điều trên nếu bộ nhớ phục vụ.

Thành thật mà nói, tôi không thấy chúng hữu ích một khi bạn vượt qua được sự phấn khích ban đầu. Chẳng hạn, dù sao thì tôi cũng không thích bình luận ở cuối dòng - Tôi luôn đặt bình luận của mình trên một dòng riêng. Cùng với đó, các tab đàn hồi mất đi công dụng chính của chúng.

Sau đó, tất nhiên bạn vẫn có thể sử dụng chúng để căn chỉnh các đối số hàm (và tham số) và danh sách dài các bài tập.

Nhưng đối với trước đây tôi có xu hướng chỉ thụt vào tất cả các đối số theo một cấp độ bổ sung và điều đó hoàn toàn tốt với tôi:

void foo(
    int x,
    int y,
    string z
)

Và tôi không thấy bất kỳ cần phải thay đổi điều đó.

Và đối với việc sắp xếp các bài tập, tôi không làm điều đó. Tôi đặt các không gian đơn xung quanh bài tập, thế thôi. Tôi cũng có xu hướng không tập hợp nhiều bài tập với nhau nên hiếm khi có vấn đề về khả năng đọc.

Tóm lại, các tab đàn hồi hoàn toàn không có ích cho tôi. Tất nhiên đây là một sở thích cá nhân có thể khác nhau nhưng tôi thấy rằng nó hoạt động tốt và tôi đoán rằng việc thiếu hỗ trợ cho các tab đàn hồi là do người khác nghĩ tương tự.

Nếu một biên tập viên sẽ thực hiện chúng, tôi vẫn không sử dụng chúng.

Một nhược điểm là nó không hoạt động nếu bạn muốn căn chỉnh trên một nhóm dòng và sau đó thụt vào dòng tiếp theo, vì nó nhóm các điểm dừng của các dòng liền kề.

def foo( bar,
         xyzzy ):
         wibble() # Too much indentation

Những gì tôi muốn:

def foo( bar,
         xyzzy ):
    wibble()

Đối với các ngôn ngữ niềng răng, điều này có thể ít gặp vấn đề hơn, vì bạn thường có thể giải quyết vấn đề này bằng cách đặt dấu ngoặc mở trên một dòng của riêng nó (như trong hoạt hình), nhưng đối với các ngôn ngữ nhạy cảm với khoảng trắng, điều này nhanh chóng trở thành một nỗi đau, và bạn cuối cùng phải quay trở lại sử dụng không gian.

Tại sao chúng ta không tạo ký tự tab dọc (VT, ASCII 11) để chỉ ra việc sử dụng các tab đàn hồi? Nó không phục vụ mục đích trong bất kỳ ngôn ngữ lập trình chính thống nào, nhưng được phân tích cú pháp dưới dạng khoảng trắng hợp lệ trong tất cả chúng, AFAIK.

Điều này có nghĩa là việc sử dụng các tab đàn hồi không còn là quy ước bên ngoài (ví dụ: "tệp này đã được định dạng bằng các tab đàn hồi, vui lòng bật chúng lên") nhưng một số trường hợp bạn chọn tham gia trong từng trường hợp.

Các trình soạn thảo văn bản hiện có thường hiển thị glyph hoặc một khoảng trắng thay cho tab dọc. Điều này không lý tưởng, nhưng một cái giá nhỏ phải trả, IMO.

Chúng không được đề cập vì chúng không được triển khai trong hầu hết các IDE của trình soạn thảo văn bản; chúng là một tính mới của việc sử dụng thực tế ít trong một dự án.

Spaces đã được sử dụng để bố trí lập trình kể từ thời của thẻ đục lỗ. Tab xuất hiện và ai đó rõ ràng nghĩ rằng chúng là một ý tưởng tốt (họ đã nhầm: p).

Trong thời đại mà hầu hết các biên tập viên hiện đại có thể tự động chuyển đổi các tab thành không gian ... chúng khá vô nghĩa.

Phải cài đặt thêm một công cụ khác để đối phó với những thứ tầm thường như các tab so với không gian chắc chắn không hấp dẫn tôi và tôi không nghĩ rằng nó sẽ phù hợp với hầu hết các đồng nghiệp của tôi.

Tôi nghĩ rằng họ sẽ tìm thấy nhiều sử dụng nếu IDE hỗ trợ họ (Microsoft!). Một khi mọi người tìm thấy họ có thể đập hộp hoa của họ ở bên cạnh và để chúng dễ đọc, họ sẽ làm được. Bạn có thể thêm nhiều bình luận được thêm vào mã nguồn đột ngột (đó chỉ có thể là một điều tốt).

Tôi cho rằng chúng ta cũng có thể thêm nhận xét "chú giải công cụ" vào danh sách 'sẽ tốt nếu ...', vì vậy các khối nhận xét lớn của bạn có thể được ẩn đi và xem dễ dàng khi cần. Có lẽ chúng ta cũng có thể có các khối nhận xét tạo thành một phần của tài liệu (không phải là công cụ loại cát, các đoạn tài liệu phù hợp với người dùng có thể đọc được nhúng trong mã, không chỉ các tiêu đề phương thức)

Nhược điểm: nó có thể làm cho nguồn khác biệt của bạn trông tệ nếu một loạt các dòng trông giống như chúng bị thay đổi khi thực sự chỉ có 1 được sửa đổi (nếu trình chỉnh sửa lưu tệp với các tab được chuyển đổi thành khoảng trắng). Hoặc, nếu tab đàn hồi được triển khai với một ký tự (hoặc nhiều khả năng là 2 tab) thì xem nguồn của bạn bên ngoài trình chỉnh sửa có thể trông tệ.

Tôi nghĩ rằng tôi thích ý tưởng này, 'tab tab' ở cuối dòng sẽ co giãn khối nhận xét và sắp xếp tất cả các nhận xét trên các dòng tiếp theo (có khoảng cách giữa hai tab).

Đây là cách tôi thấy: nếu hầu hết các công cụ phổ biến đã hỗ trợ các tab đàn hồi, nhiều người sẽ sử dụng chúng. Điều tương tự cũng xảy ra với chế độ điều hướng / chỉnh sửa của vi, với đánh dấu cú pháp và sau đó với Intellisense. Trong mỗi trường hợp, sự khôn ngoan đã được thiết lập là nó không hữu ích hoặc không cần thiết, nhưng nó đã được thực hiện và nó đã cất cánh.

Tất nhiên, các tab đàn hồi có tác động tương đối thấp. Hầu hết mọi người đều hài lòng với hiện trạng và vì vậy đừng quan tâm. Một lý do tương tự được áp dụng cho nhiều tình huống trong đó một số người chỉ hài lòng với những gì họ đã có và không thấy lý do gì để chuyển sang một thứ gì đó cao cấp hơn. Nói cách khác, vấn đề lớn nhất với các tab đàn hồi cũng giống như đối với hầu hết mọi ý tưởng hay khác: nó cần phải đạt được lực kéo.

Nhưng điều đó không có nghĩa là tính năng này không thể được chấp nhận tăng dần. Mỗi ngôn ngữ lập trình đơn lẻ được áp dụng tăng dần, mặc dù toàn bộ một nhóm yêu cầu trình biên dịch mới và IDE mới để bắt đầu sử dụng nó. Điều tương tự cũng đúng với mọi kiến ​​trúc phần cứng đơn lẻ và nhiều ví dụ khác. Đây cũng không phải là trường hợp thiếu tích hợp với các công cụ hiện có là một công cụ chặn hiển thị: ví dụ như vậy là đúng, ví dụ, định dạng của unified-diff diff, mà thay thế một định dạng ít đọc hơn trước đây mà các công cụ tự động hiểu được (chẳng hạn như bản vá). Những công cụ đã được nâng cấp theo thời gian.

Tôi đánh giá cao các vấn đề liên quan mà những người khác đã đề cập, nhưng mặc dù vậy, chắc chắn sẽ có những đội (như của tôi), những người sẽ chấp nhận điều này mà không do dự, trong toàn bộ chúng tôi. Các công cụ bên ngoài như khuếch tán, hợp nhất, vv ban đầu sẽ không hỗ trợ nó, nhưng chúng tôi sẽ thực hiện phần của mình để khuyến khích các nhà cung cấp đưa vào tính năng này. Đây là cách tiến bộ luôn luôn được thực hiện. Nó đòi hỏi một số đau đớn trong một thời gian chuyển tiếp tạm thời, nhưng cuối cùng, nó là giá trị nó.

Vấn đề lớn nhất mà tôi có với nó là khoảng cách không nhất quán trong toàn bộ tài liệu. Tôi biết với tư cách là một lập trình viên, tôi sẽ cảm thấy khó chịu khi thấy một vòng lặp hoặc nếu câu lệnh ở vị trí thụt lề 'tiêu chuẩn' và sau đó để ý ở các vết lõm khác nhau. Cá nhân tôi biết rằng tôi thích nhìn thấy tất cả các dấu ngoặc nhọn của mình được đặt trong tài liệu, không chỉ trong khối mã tôi đang xem.

Nhìn chung, tôi nghĩ rằng đó là một ý tưởng tốt, tuy nhiên, cá nhân tôi không thích nó.

Tôi vừa thử thực hiện các tab tab đàn hồi của jEdit, hoạt động rất tốt với các ngôn ngữ lập trình mà tôi quen thuộc (chủ yếu là các ngôn ngữ giống như HTML / XML và C). Tuy nhiên, với mã Python, đây là cách nó được hiển thị (khoảng trắng được sử dụng thay cho các tab để minh họa cách sắp xếp mọi thứ):

def foo(x):
             '''<1 tab before the docstring.
No tab       <tab
No tab       <tab
             <tab  <another tab
             <tab  <another tab
             <tab'''
             if 1 or 2:    #<Tab before this comment
                           yield True

Đối với một ngôn ngữ như Python dựa vào khoảng cách, đây là một công cụ giải quyết trừ khi bạn vô hiệu hóa chức năng được cung cấp bởi các tab đàn hồi. Các trình soạn thảo như Vim và Emacs làm cho việc vô hiệu hóa hầu hết các loại chức năng trở nên đơn giản nếu bạn biết tên của tùy chọn và cách tắt nó, nhưng chức năng này sẽ được yêu cầu vô hiệu hóa cho mã như trên.

Điều đó đang được nói, thật tuyệt vời cho x86 ASM, C, C ++, Go, XML, HTML và những thứ khác không phụ thuộc vào khoảng trắng quá nhiều:

import (
    "fmt"    // We love formatting functions.
    "io"     // Because I/O is useful.
    "os"     // Can't open a file without os.Open!
)

type Foo struct {
    Field1              int          // This is properly aligned
    ReallyLongField2    string       // with this.
    privateField        io.Reader    // Elastic tabstops are great for Go.
}

Tôi sẽ nói rằng các phương ngữ Lisp như Scheme có các quy ước riêng của chúng cũng sẽ làm cho các tabstop đàn hồi đưa ra mã "xấu xí". Nếu tôi thay đổi cài đặt tabstop của mình để khớp với quy ước của 2 cột và chèn các tab ở vị trí bất thường (giữa một hàm và các đối số của nó):

(let loop ((n 1))
  (if  (> n 10)
        '()
        (cons  n
               (loop (+ n 1)))))

so với càng dễ đọc hơn:

(let loop ((n 1))
  (if (> n 10)
      '()
      (cons n
            (loop (+ n 1)))))

Cấp, cái này không tệ như ví dụ Python, nhưng nó chắc chắn làm giảm khả năng đọc mã. Mặc dù tôi rất thích chức năng khi mã hóa bằng thứ gì đó như C # hoặc C ++, tôi ghê tởm chức năng khi mã hóa bằng ngôn ngữ như Python hoặc Scheme trong đó khoảng trắng là chức năng và / hoặc trực quan hữu ích. Các tab đàn hồi được tạo ra đặc biệt hữu ích mà không yêu cầu tiện ích thụt đầu dòng riêng biệt, nhưng rõ ràng nó không có nghĩa cho tất cả các ngôn ngữ lập trình.

Emacs đã xử lý thụt đầu dòng với sự hiện diện của dấu ngoặc đơn chưa được tiết lộ và sẽ tự động căn chỉnh wilma với fred . Tôi không biết tại sao Eclipse không làm như vậy. Ok, tôi có một ý tưởng, nhưng nó không đơn giản.

Bạn có thể yêu cầu Emacs căn chỉnh bình luận, không gặp nhiều rắc rối, nhưng AFAIK không ai ngoài bạn từng muốn điều đó.