Cân nhắc thực tế cho các quy ước đặt tên HTML / CSS (cú pháp) [đã đóng]

Câu hỏi: những cân nhắc thực tế cho cú pháp classvà idgiá trị là gì?

Lưu ý rằng tôi không hỏi về ngữ nghĩa , nghĩa là các từ thực tế đang được sử dụng, ví dụ như được mô tả trong blogpost này . Có rất nhiều tài nguyên ở phía đó của các quy ước đặt tên, trên thực tế, che khuất việc tìm kiếm thông tin thực tế của tôi trên các bit cú pháp khác nhau : vỏ, sử dụng giao thoa (cụ thể là -dấu gạch ngang), các ký tự cụ thể để sử dụng hoặc tránh, v.v.

Để tóm tắt những lý do tôi hỏi câu hỏi này:

• Các hạn chế đặt tên cho id và class không tự nhiên dẫn đến bất kỳ quy ước nào
• Sự phong phú của các nguồn lực về mặt ngữ nghĩa của các quy ước đặt tên che khuất các tìm kiếm trên các cân nhắc cú pháp
• Tôi không thể tìm thấy bất kỳ nguồn có thẩm quyền về điều này
• Không có câu hỏi nào về lập trình viên SE về chủ đề này :)

Một số quy ước tôi đã cân nhắc sử dụng:

1. UpperCamelCase, chủ yếu là một thói quen chéo từ mã hóa phía máy chủ
2. lowerCamelCase, để thống nhất với các quy ước đặt tên JavaScript
3. css-style-classes, phù hợp với việc đặt tên các thuộc tính css (nhưng có thể gây khó chịu khi lựa chọn văn bản Ctrl + Shift + ArrowKey)
4. with_under_scores, mà cá nhân tôi chưa thấy sử dụng nhiều
5. alllowercase, đơn giản để nhớ nhưng có thể khó đọc cho tên dài hơn
6. UPPERCASEFTW, như một cách tuyệt vời để làm phiền các lập trình viên đồng nghiệp của bạn (có lẽ kết hợp với tùy chọn 4 để dễ đọc)

Và có lẽ tôi cũng đã bỏ qua một số tùy chọn hoặc kết hợp quan trọng. Vì vậy: những cân nhắc nào là có để đặt tên cho các quy ước, và chúng dẫn đến quy ước nào?

Tiền thưởng hay không, trong một chừng mực nào đó, sự lựa chọn sẽ luôn là "vấn đề ưu tiên" - sau tất cả, bạn sẽ cảm thấy thế nào nếu W3C khuyến nghị (hoặc thậm chí áp đặt) một quy ước nhất định mà bạn cảm thấy không đúng?

Mặc dù đã nói rằng, cá nhân tôi thích lowerCamelCasequy ước này và tôi sẽ đưa ra những lý do và cân nhắc thực tế mà tôi đã sử dụng để quyết định - tôi sẽ làm như vậy bằng một quá trình loại bỏ, sử dụng cách đánh số từ câu hỏi của bạn:

(5.) justnoteasilyreadablebecauseyoudontknwherewordsstartandend.

(6.) ASABOVEPLUSITSANNOYINGLIKESOMEONESHINGING.

(4.) history_incompabilities_plus_see: Tài liệu Mozilla Dev .

(3.) khó giải thích hơn một chút ... như bạn đã đề cập, khả năng lựa chọn trong trình soạn thảo văn bản là một vấn đề (như với dấu gạch dưới, tùy thuộc vào trình chỉnh sửa), nhưng đối với tôi, đó cũng là sự thật khiến tôi nhớ về cú pháp dành riêng cho các từ khóa dành riêng cho nhà cung cấp , ngay cả khi những từ bắt đầu bằng dấu gạch nối cũng như có các từ được phân tách bằng chúng.

Vì vậy, điều này lần lượt để lại (1.) và (2.), UpperCamelCase và lowCamelCase. Mặc dù có liên kết tinh thần với các lớp Java (theo một quy ước được xác định rõ ràng hơn, UpperCamelCase), đối với tôi, các tên lớp CSS dường như tốt hơn là bắt đầu bằng một chữ cái viết thường. Có lẽ đó là do tên thành phần và thuộc tính XHTML , nhưng tôi đoán bạn cũng có thể làm cho trường hợp có các lớp CSS sử dụng UpperCamelCase sẽ giúp phân biệt chúng. Nếu bạn cần một lý do khác, lowCamelCase là những gì W3C sử dụng trong các ví dụ cho tên lớp tốt (mặc dù chính URL, thật khó chịu, không đồng ý với tôi).

Tôi sẽ khuyên chống lại (4.), (5.) và (6.), vì những lý do đã nêu ở trên, nhưng giả sử rằng các đối số có thể được đưa ra cho một trong ba điều còn lại.

Việc bạn (hoặc bất kỳ ai khác cho vấn đề đó) có đồng ý với tôi về vấn đề này hay không là tùy thuộc vào bạn. Thực tế là bạn chưa có một định câu trả lời trích dẫn các nguồn có thẩm quyền bởi bây giờ có thể được thực hiện như một gợi ý rằng có không phải là một điều như một tiêu chuẩn nhất định về vấn đề này (khác chúng tôi muốn tất cả được sử dụng nó). Tôi không chắc đó là điều xấu.

Các từ trong tên lớp CSS phải được phân tách bằng dấu gạch ngang ( class-name), vì đó là cách các từ trong thuộc tính CSS và lớp giả được phân tách và cú pháp của chúng được xác định bởi thông số CSS .

Các từ trong tên ID cũng nên được phân tách bằng dấu gạch ngang, để phù hợp với kiểu cú pháp của tên lớp và tên ID thường được sử dụng trong URL và dấu gạch ngang là dấu tách từ gốc và phổ biến nhất trong URL.

Đó chủ yếu là vấn đề ưu tiên; không có tiêu chuẩn được thiết lập, nói gì đến một nguồn có thẩm quyền, về vấn đề này. Sử dụng bất cứ thứ gì bạn cảm thấy thoải mái nhất; Chỉ cần nhất quán.

Cá nhân, tôi sử dụng css-style-with-dashes, nhưng tôi cố gắng tránh các tên lớp nhiều từ và sử dụng nhiều lớp bất cứ khi nào có thể ( button important defaultthay vì vậy button-important-default). Từ kinh nghiệm của tôi, đây dường như cũng là lựa chọn phổ biến nhất trong số các trang web và khung chất lượng cao.

Chữ thường có dấu gạch ngang cũng dễ gõ hơn các tùy chọn khác (không bao gồm nowordseparatorswhatsoeverquy ước khó đọc ), ít nhất là trên bàn phím Hoa Kỳ, vì không yêu cầu sử dụng phím Shift.

Đối với id, có một cân nhắc thực tế bổ sung rằng nếu bạn muốn tham chiếu các phần tử bằng ID của chúng trực tiếp trong javascript (ví dụ document.forms[0].btn_ok), dấu gạch ngang sẽ không hoạt động tốt - nhưng sau đó, nếu bạn đang sử dụng jQuery, có lẽ bạn sẽ sử dụng chúng thông qua $()bất cứ cách nào, vì vậy sau đó bạn có thể có $('#btn-ok'), điều này làm cho điểm này chủ yếu là tranh luận.

Đối với hồ sơ, một ước tôi đi qua thường xuyên sử dụng mụn cóc Hungary trong ID để chỉ các loại nguyên tố, đặc biệt đối với hình thức kiểm soát - vì vậy bạn phải #lblUsername, #tbUsername, #valUsernamecho nhãn Tên truy nhập, nhập vào, và validator.

Tôi tin tưởng mạnh mẽ rằng điều quan trọng nhất là tính nhất quán.

Có hai cách để xem xét điều này:

1. Một cuộc tranh luận tốt có thể được đưa ra alllowercasehoặc css-style-clauses(có lẽ là sự lựa chọn tốt hơn) bởi vì chúng sẽ phù hợp nhất với mã mà họ sẽ tham gia. Nó sẽ cho vay một dòng chảy tự nhiên hơn vào mã nói chung và sẽ không có gì bị sai lệch hoặc sai lệch .

2. Một đối số tốt tương tự có thể được tạo cho một kiểu khác với tên thẻ HTML hoặc mệnh đề CSS, nếu nó sẽ phân biệt ID và lớp theo cách hỗ trợ khả năng đọc. Ví dụ: nếu bạn đã sử dụng UpperCamelCasecho ID và các lớp và không sử dụng nó cho bất kỳ cấu trúc hoặc mục đích nào khác, bạn sẽ biết bạn đã đánh vào mỗi lần bạn nhìn thấy mã thông báo ở định dạng đó. Một hạn chế mà điều này có thể áp đặt là nó sẽ hiệu quả nhất nếu mỗi ID hoặc lớp là một tên từ 2+, nhưng điều đó hợp lý trong nhiều trường hợp.

Khi viết câu trả lời này, tôi đã phát hiện ra rằng tôi nghiêng về lựa chọn thứ hai nhiều hơn, nhưng tôi sẽ bỏ cả hai vì tôi nghĩ cả hai trường hợp đều có giá trị.

Đó thực sự là một vấn đề ưu tiên, hoặc là sự lười biếng. CamelCasing dễ gõ hơn, nhưng tôi thích sử dụng ký hiệu gạch dưới vì tôi thấy nó dễ đọc và gỡ lỗi hơn so với CamelCase. Không có một quy ước mã hóa nào tuân theo, tôi chưa bao giờ làm việc tại một nơi có các nguyên tắc mã hóa giống như địa điểm trước đó.

Hầu hết các công ty đều có hướng dẫn mà bạn thường phải tuân theo bất kỳ cách nào để giữ cho mã sạch sẽ và dễ dàng hơn cho mọi người làm việc. Nếu bạn là một người làm việc tự do, thì bạn có thể đi ra ngoài vì bạn là người duy nhất làm việc về mã. Theo tôi, chỉ có 2 quy ước mã hóa: ký hiệu CamelCase hoặc Underscore. Lời khuyên của tôi là chọn một và sau đó gắn bó với nó.

Bạn dường như không biết đến một thực tế đơn giản: hầu hết CSS không được lập trình viên thực hiện .

Nó được thực hiện bởi các nhà thiết kế đồ họa.

Họ không quan tâm đến các cuộc chiến chỉnh sửa của chúng tôi và không quan tâm đến những gì chúng tôi làm với phím shift.
Họ thậm chí có thể không biết chìa khóa ưa thích đó ở đâu_ . (hoặc tên của nó là gì)

Họ không quan tâm đến thẩm mỹ mã , họ quan tâm đến thẩm mỹ thẩm mỹ .

(Và họ có thể có một điểm ở đó)

Họ không đọc thông số kỹ thuật , họ nhận được hướng dẫn.
Và sau đó kiểm tra lại các tài liệu tham khảo trên w3schools.

Một số người trong số họ có thể tin rằng họ không thể sử dụng tên lớp chữ hoa vì lý do.
Chúng chứa đầy những hiểu lầm kỳ lạ, chủ yếu là không liên quan.