Các tab so với không gian, các ký tự thụt lề thích hợp cho mọi thứ, trong mọi tình huống, bao giờ? [đóng cửa]

Các tiêu chuẩn mã hóa cho mã được lưu trữ trong drupal.org đề nghị sử dụng hai khoảng trắng để thụt mã; các trang web khác đề nghị sử dụng các tab để thụt mã.

Các nhân vật thụt lề thích hợp cho tất cả mọi thứ, và trong mọi tình huống là gì? Hãy giải thích câu trả lời bạn đưa ra.

Không gian

Một tab có thể là một số cột khác nhau tùy thuộc vào môi trường của bạn, nhưng một không gian luôn là một cột.

Về việc có bao nhiêu khoảng trắng (hoặc tab) tạo thành thụt đầu dòng, điều quan trọng là phải nhất quán trong toàn bộ mã của bạn hơn là sử dụng bất kỳ giá trị dừng tab cụ thể nào.

Tab

Bây giờ, tất nhiên, tính nhất quán quan trọng hơn một, và một IDE tốt làm cho sự khác biệt không đáng kể. Điều đó nói rằng, điểm của chủ đề này là một cuộc chiến thánh, vì vậy:

Tôi thích các tab:

• Chúng là một nhân vật đặc biệt dành cho thụt lề
• Chúng cho phép các nhà phát triển với các tùy chọn khác nhau về kích thước thụt lề thay đổi giao diện của mã mà không thay đổi mã (tách dữ liệu và trình bày để giành chiến thắng trong câu tục ngữ!)
• Không thể thụt lề một cái gì đó bằng các tab. Vì vậy, khi bạn sao chép mã từ một số trang web đã sử dụng 3 khoảng trắng vào tệp thụt lề 4 không gian của bạn, bạn không phải xử lý sai.

Sử dụng các tab để thụt đầu dòng, một tab cho mỗi mức thụt lề và cho phép mọi người chọn mức độ rộng mà họ muốn.

Sử dụng khoảng trắng nếu bạn sắp xếp các ký tự trong một dòng, để chúng luôn xếp hàng bất kể kích thước tab.

Và tìm và đấm tất cả các tác giả phần mềm ban đầu đã để điều ngu ngốc này trở thành một vấn đề ngay từ đầu.
(Nghiêm túc, tại sao điều này thậm chí là một cái gì đó được thảo luận? Tiếp theo bạn sẽ nói với tôi rằng bạn cũng muốn sử dụng nhiều ký tự để ngắt dòng!)

Tab

• cho phép những sai lầm đáng chú ý hơn , thật khó chịu khi vi quản lý vào không gian.
• là nhất quán , chúng chỉ được sử dụng để thụt lề, trừ khi bạn đang bình luận sai.
• có thể tùy chỉnh , bạn có thể chỉ định trong các tùy chọn của trình chỉnh sửa độ rộng của chúng.
• có năng suất cao hơn , tại sao gõ 4 khoảng trắng khi bạn có thể nhấn 1 tab.
• có kích thước nhỏ hơn nhiều không gian.
• chiếm nhiều không gian hơn một không gian
• mất ít thời gian để đi qua .
• có xu hướng hoạt động tốt hơn trong các IDE.

Không gian nên được sử dụng trong đó các tab hoàn toàn vô dụng.

Ngay cả để căn chỉnh các tham số và nhận xét, các tab vẫn hoạt động tốt hơn .

Tất cả các đối số cho các tab là lý thuyết tuyệt vời. Nhưng...

Trong lý thuyết, thực hành và lý thuyết là như nhau. Trong thực tế, họ không.

Có, với các tab bạn có thể quyết định mức độ thụt đầu dòng của bạn. Và có, bạn có thể sử dụng kết hợp các tab và khoảng trắng để sắp xếp mọi thứ. Và trong một thế giới lý tưởng, nó sẽ

Trong thực tế, bạn không thể thấy sự khác biệt giữa các khoảng trắng và tab, chúng dường như luôn bị lẫn lộn khi di chuyển mã xung quanh và xem mã trong một chương trình khác có các tab được đặt thành 8 cột là một điều phiền toái.

Tôi đã từng sử dụng các tab. Sau đó, tôi bắt đầu làm việc như một phần của một nhóm và chia sẻ mã. Tôi nhanh chóng trở thành một người ủng hộ không gian. Vì vậy, trong khi tôi có thể đồng cảm với những điều không tưởng của các tab, tôi không thể tưởng tượng việc không sử dụng khoảng trắng.

Một số ý kiến ​​liên quan có thể được quan tâm:

• Guido nói không gian
• Joel nói không gian
• Atwood nói không gian
• Zawinski nói không gian, loại

Tab cho chiến thắng.

Tôi chắc chắn. ghét. 4. không gian.

Tại sao? Chủ yếu là vì tôi mệt mỏi khi điều hướng mã của mình bằng bàn phím và phải liên tục nhấn left left left leftđể đi qua một vết lõm. Điều này được sinh ra từ các phiên bản đầu của Notepad ++ và thậm chí cả notepad Windows đơn giản, nơi không có nút định dạng. Tôi đã có rất nhiều vấn đề khi mọi người chỉ sử dụng 3 khi tôi đã sử dụng 4 ở mọi nơi khác trong số những thứ khác.

Lý do khác là ký tự tab tồn tại đặc biệt để thụt lề và chỉ sau đó được chấp nhận để điều hướng. Tại sao chúng ta làm space space space spacekhi một đơn giản tabsẽ làm việc? Tại sao IDE phải xử lý chính xác 2-5 mã và định dạng khi một tab đơn giản và tùy chọn tùy chọn sẽ hoạt động?

Thật không may, tôi là thiểu số.

Cá nhân tôi thích sử dụng các tab trong mọi thứ, vì mỗi nhà phát triển có thể kiểm soát lượng thụt vào mỗi tab. Bằng cách đó bạn có được sự linh hoạt trong màn hình.

Điều đó đang được nói, tôi thường bắt chước bất kỳ phong cách mã hóa nào trong tệp để bắt đầu (vì tôi dành nhiều thời gian để thực hiện công việc bảo trì).

Tôi không nghĩ rằng có những thứ như thụt lề thích hợp (ít nhất là không phải không có chiến tranh nhỏ).

Cá nhân tôi thích bốn không gian. Chúng cho phép tôi đọc mã nhanh hơn nhiều và chúng trông giống nhau trong mọi trình soạn thảo - ngay cả Vi.

Không gian, bởi vì khi bạn căn chỉnh các bình luận ở bên phải mã, hoặc danh sách tham số hàm hoặc các biểu thức đa dòng phức tạp hoặc những thứ thuộc về bản chất đó, bạn muốn tác phẩm đẹp của mình xuất hiện đúng với mọi người . Nếu bạn sử dụng các tab và cho phép mọi người đặt các tab của họ khác nhau, họ sẽ ngắt liên kết cho tất cả các trường hợp ngoại trừ mã đơn giản nhất.

Bên cạnh đó, rõ ràng là tất cả mọi người trên thế giới nên sử dụng vim, điều này khiến cho việc tầm thường trở nên thụt lề, không cố định và điều hướng qua "điểm dừng tab" ngay cả trong các tệp được thụt lề.

Tab là sự lựa chọn tự nhiên và chính thống, vì chúng theo định nghĩa được sử dụng để thụt lề.

Thật không may, các tab được thực hiện không đồng đều, vì vậy giải pháp thế giới thực duy nhất là 4 không gian.

Bạn rõ ràng cần một cách tiếp cận kết hợp.

Nếu bạn đang chia sẻ mã với các nhà phát triển khác, bạn cần phải chuẩn hóa và vì điều đó là không thể (koff koff), bạn cần làm cho mọi người thực hiện bốn khoảng trắng.

Sau đó, bạn cần một biên tập viên đủ thông minh để không ngu ngốc về điều đó, để biết rằng nó nên xử lý một dòng có bốn khoảng trống ở phía trước của nó giống như nó được thụt vào. Bất kỳ trình soạn thảo IDE hoặc lập trình viên hiện đại nào cũng có thể tự động chuyển mã bằng dấu cách thay vì các tab.

Tại sao ai đó không thể thực hiện điều này:

• mã được lưu trữ trong một định dạng nhỏ gọn có lợi cho hệ thống được đề cập
• khi mỗi nhà phát triển mở mã, nó được định dạng chính xác theo cách họ muốn
• khi họ đã hoàn thành với nó, trở lại định dạng nhỏ gọn

Mọi người đều vui vì tất cả đều thấy định dạng 'của riêng mình'

Điều đó có khó không?

Spaces hoặc Tab - Những gì Atwood thực sự nói là chọn một thứ và nhất quán trong dự án của bạn. Chén thánh duy nhất của định dạng mã là đảm bảo rằng nó nhất quán để kẻ thái nhân cách duy trì mã của bạn sau khi bạn không cảm thấy buộc phải khắc phục tình trạng này vĩnh viễn.

Điều đó nói rằng, nếu bạn đang làm việc trong Python hoặc bất kỳ ngôn ngữ nào khác, nơi khoảng trắng là một cấu trúc lập trình thực tế tôi không thể tưởng tượng được bằng cách sử dụng các tab.

Tôi là một chàng trai 4 không gian, các tab không nhất quán.

Rõ ràng các tab gây rối trong Delphi vì vậy tôi không sử dụng các tab trong Delphi.

Tuy nhiên, tôi làm mọi thứ khác bằng Emacs và luôn sử dụng các tab vì các tab của tôi đi chính xác nơi tôi muốn chúng đi.

Câu trả lời là không thể có một ký tự thụt thích hợp duy nhất cho mọi tình huống. Định dạng bằng cách sử dụng các ký tự là không linh hoạt và có thể gây ra xung đột khi các kiểu khác nhau được sử dụng trong một nhóm.

Phương pháp duy nhất để định dạng mã hoàn hảo và linh hoạt với các kiểu định dạng khác nhau là thực hiện nó hầu như, không có bất kỳ ký tự thụt đầu dòng nào. Trình soạn thảo mã duy nhất tôi biết hỗ trợ điều này mặc dù là trình soạn thảo được sử dụng trong mẫu bên dưới:

Để thể hiện định dạng ảo , ảnh chụp màn hình bên dưới là từ trình soạn thảo XSLT * sử dụng phương pháp thụt lề này (cũng có một đoạn video ngắn ở đây ). Mỗi ký tự trong XSLT đã được tô sáng màu vàng, nhằm mục đích minh họa, cho phép nhìn thấy rõ ràng các tab hoặc ký tự khoảng trắng trong nội dung. Việc thụt mã được xử lý bởi hệ thống kết xuất của trình soạn thảo điều chỉnh lề trái (có nền trắng).

Các ký tự không gian hàng đầu duy nhất đứng trước các dòng Sách , bởi vì đây là nội dung văn bản bằng chữ, không phải mã, các ký tự khoảng trắng này phải được giữ nguyên.

Với định dạng ảo, bạn chọn độ rộng thụt lề cho phù hợp với môi trường và kiểu thụt đầu dòng mà không ảnh hưởng đến bất kỳ ký tự nào trong tệp nguồn. Bạn thậm chí có thể đặt chiều rộng thụt thành 0, nếu bạn cần một chế độ xem phẳng của mã như dưới đây:

Để đối chiếu điều này với định dạng ký tự không gian, cùng một XSLT được mở trong trình chỉnh sửa không có định dạng ảo được chuyển đổi bởi trình định dạng tự động của trình soạn thảo đó sang:

Các khối màu vàng trống lớn hơn trong ảnh chụp màn hình ở trên hiển thị rõ ràng các ký tự khoảng trắng được thêm bởi trình định dạng của trình chỉnh sửa thông thường. Thật không may, giờ đây chúng không thể được phân biệt với nội dung thực nên XSLT sẽ phải được sửa đổi để khắc phục vấn đề này.

Tóm lược

XSLT có thể là một trường hợp cực đoan, nhưng nguyên tắc này đúng với nhiều ngôn ngữ lập trình: Các ký tự nên được sử dụng cho nội dung và một phương pháp thay thế được tìm kiếm khi định dạng.

** Tiết lộ: Trình chỉnh sửa XSLT với định dạng ảo được phát triển bởi chính công ty của tôi *

Không được đề cập cho đến bây giờ: Có các ngôn ngữ (Python, Haskell) trong đó vấn đề thụt lề. Nhưng 1 ký tự được tính là 1 ký tự, có thể là khoảng trắng hoặc tab để vết lõm mà trình biên dịch nhìn thấy có thể không giống với ký tự bạn nhìn thấy trên màn hình nếu bạn sử dụng tab.

Do đó, trong các ngôn ngữ như Haskell, không gian là phải. Trong Makefiles, TABS là phải. Trong tất cả các vấn đề khác, đó là vấn đề sở thích cá nhân và ngày nay không phải là vấn đề lớn - mọi biên tập viên đàng hoàng đều có lệnh "(dẫn đầu) đến khoảng trắng" và "(dẫn) khoảng trắng đến tab".

Tôi đã từng sử dụng các khoảng trắng, nhưng gần đây tôi đã sử dụng các tab hoàn toàn vì đó là những gì Eclipse được đặt thành khi cuối cùng tôi nhận thấy. Tất cả các nhà phát triển khác trong nhóm của tôi đều sử dụng Eclipse, do đó, việc chuẩn hóa các tab khi chúng tôi nhận ra rằng chúng tôi đã sử dụng chúng từ lâu và không có lý do gì để thay đổi không gian. Tôi đã rất ngạc nhiên bởi nó không phải là vấn đề.

Đặt kích thước tab được hiển thị thành 3 hoặc 5 ký tự trong IDE của bạn giúp đơn giản hóa rất nhiều việc phân biệt giữa các phần mã được thụt lề bởi các khoảng trắng (hầu như luôn luôn là 4 ngày này) và các ký tự được thụt lề bởi tab.

Rất nhiều tranh luận đã được đưa ra, nhưng không ai đề cập đến việc chúng ta có thể hướng tới đâu trong tương lai .

Tab cũng không gian!

Mã lý tưởng nên được coi là dữ liệu và không được lưu trữ trong bất kỳ định dạng văn bản cụ thể nào. Bất kỳ nhà phát triển có thể áp dụng quan điểm ưa thích của riêng mình. Hơn nữa, chế độ xem này không nên giới hạn chỉ trong văn bản , mà có thể bao gồm các bảng, bộ chọn màu và công thức toán học.

Ý tưởng này không quá xa vời. Đó là Trình soạn thảo lập trình định hướng ngôn ngữ (MPS) của JetBrain , lần đầu tiên khiến tôi nhận ra điều này giải quyết toàn bộ cuộc thảo luận, đồng thời bổ sung rất nhiều khả năng bổ sung. (Có, điều này là có thể với các trình soạn thảo, nhưng làm việc trực tiếp trên văn bản sẽ thêm rất nhiều sự phức tạp không cần thiết, trái ngược với cách tiếp cận mà MPS thực hiện.)

Trái ngược với các tab và khoảng trắng, có rất ít nhược điểm có thể được đề cập để làm việc trực tiếp trên các cây cú pháp trừu tượng . Tất cả những gì cần thiết là cho công nghệ phát triển thành một sản phẩm khả thi về mặt thương mại. Những dấu hiệu đầu tiên của điều này đang hiển thị. Được xây dựng chủ yếu dựa trên MPS, một trình soạn thảo hành động thương mại, Real Wax đã được tạo.

Tôi rất thích thấy một trong những người chơi lớn nhảy vào khái niệm về công nghệ này và xem điều gì sẽ xảy ra!

Không phải là tốt hơn, cũng không phải là tồi tệ hơn. Điều quan trọng duy nhất là phải nhất quán.

Nếu bạn là một nhóm, hãy chọn bất cứ thứ gì bạn thích. Xem xét hành vi mặc định của trình soạn thảo yêu thích của bạn, nhưng chọn bất cứ điều gì bạn thích.

Nếu bạn ở trong một đội, hãy làm những gì nhóm làm. Giai đoạn = Stage.

Trong các công việc khác nhau của tôi, tôi đã sử dụng hai không gian, bốn không gian, tám khoảng trắng, tab, khoảng trắng và tab, tôi nghĩ rằng tôi cũng có thể đã sử dụng một khoảng trắng. Tôi nói với biên tập viên của tôi phải làm gì sau đó tôi không nghĩ về nó nữa, biên tập viên làm việc chi tiết.

Điều khác duy nhất là đảm bảo bạn chọn một trình soạn thảo thông minh. Emacs hay vi? Bây giờ đó là một cuộc chiến thần thánh tôi sẵn sàng chiến đấu :-)