Tôi đã luôn sử dụng một *.htệp cho các định nghĩa lớp của mình, nhưng sau khi đọc một số mã thư viện tăng cường, tôi nhận ra tất cả chúng đều sử dụng *.hpp. Tôi luôn có ác cảm với phần mở rộng tập tin đó, tôi nghĩ chủ yếu là vì tôi không quen với nó.

Những lợi thế và bất lợi của việc sử dụng *.hpphơn là *.hgì?

Dưới đây là một số lý do để đặt tên khác nhau của tiêu đề C vs C ++:

• Định dạng mã tự động, bạn có thể có các hướng dẫn khác nhau để định dạng mã C và C ++. Nếu các tiêu đề được phân tách bằng tiện ích mở rộng, bạn có thể đặt trình chỉnh sửa của mình tự động áp dụng định dạng phù hợp
• Đặt tên, tôi đã tham gia vào các dự án có thư viện viết bằng C và sau đó trình bao bọc đã được triển khai trong C ++. Vì các tiêu đề thường có tên tương tự, ví dụ Feature.h so với Feature.hpp, chúng rất dễ phân biệt.
• Bao gồm, có thể dự án của bạn có các phiên bản phù hợp hơn có sẵn được viết bằng C ++ nhưng bạn đang sử dụng phiên bản C (xem điểm trên). Nếu các tiêu đề được đặt tên theo ngôn ngữ mà chúng được triển khai trong bạn có thể dễ dàng phát hiện ra tất cả các tiêu đề C và kiểm tra các phiên bản C ++.

Hãy nhớ rằng, C không phải là C ++ và việc trộn và kết hợp có thể rất nguy hiểm trừ khi bạn biết bạn đang làm gì. Đặt tên nguồn của bạn một cách thích hợp giúp bạn phân biệt các ngôn ngữ.

Tôi sử dụng .hpp vì tôi muốn người dùng phân biệt tiêu đề nào là tiêu đề C ++ và tiêu đề nào là tiêu đề C.

Điều này có thể quan trọng khi dự án của bạn đang sử dụng cả hai mô-đun C và C ++: Giống như người khác đã giải thích trước tôi, bạn nên thực hiện một cách cẩn thận và bắt đầu bằng "hợp đồng" bạn cung cấp thông qua tiện ích mở rộng

.hpp: Tiêu đề C ++

(Hoặc .hxx hoặc .hh hoặc bất cứ điều gì)

Tiêu đề này chỉ dành cho C ++.

Nếu bạn đang ở trong một mô-đun C, thậm chí không thử đưa nó vào. Bạn sẽ không thích nó, vì không có nỗ lực nào được thực hiện để làm cho nó thân thiện với C (quá nhiều sẽ bị mất, như quá tải chức năng, không gian tên, v.v.).

.h: Tiêu đề C tương thích hoặc C / C ++ tương thích

Tiêu đề này có thể được bao gồm bởi cả nguồn C và nguồn C ++, trực tiếp hoặc gián tiếp.

Nó có thể bao gồm trực tiếp, được bảo vệ bởi __cplusplusmacro:

• Điều đó có nghĩa là, từ quan điểm C ++, mã tương thích C sẽ được định nghĩa là extern "C".
• Từ quan điểm C, tất cả mã C sẽ hiển thị rõ ràng, nhưng mã C ++ sẽ bị ẩn (vì nó sẽ không được biên dịch trong trình biên dịch C).

Ví dụ:

#ifndef MY_HEADER_H
#define MY_HEADER_H

   #ifdef __cplusplus
      extern "C"
      {
   #endif

   void myCFunction() ;

   #ifdef __cplusplus
      } // extern "C"
   #endif

#endif // MY_HEADER_H

Hoặc nó có thể được bao gồm gián tiếp bởi tiêu đề .hpp tương ứng kèm theo nó với extern "C"khai báo.

Ví dụ:

#ifndef MY_HEADER_HPP
#define MY_HEADER_HPP

extern "C"
{
#include "my_header.h"
}

#endif // MY_HEADER_HPP

và:

#ifndef MY_HEADER_H
#define MY_HEADER_H

void myCFunction() ;

#endif // MY_HEADER_H

Tôi luôn coi .hpptiêu đề là một loại portmanteau .hvà .cpptập tin ... một tiêu đề cũng chứa các chi tiết triển khai.

Thông thường khi tôi thấy (và sử dụng) .hppnhư một phần mở rộng, không có .cpptệp tương ứng . Như những người khác đã nói, đây không phải là một quy tắc khó và nhanh, chỉ là cách tôi có xu hướng sử dụng .hppcác tệp.

Việc bạn sử dụng tiện ích mở rộng nào không quan trọng. Một trong hai là OK.

Tôi sử dụng *.hcho C và *.hppcho C ++.

EDIT [Đã thêm đề xuất từ ​​Dan Nissenbaum]:

Theo một quy ước, các tệp .hpp được sử dụng khi các nguyên mẫu được xác định trong chính tiêu đề. Các định nghĩa như vậy trong các tiêu đề rất hữu ích trong trường hợp mẫu, vì trình biên dịch tạo mã cho mỗi loại chỉ trên khởi tạo mẫu. Do đó, nếu chúng không được xác định trong tệp tiêu đề, định nghĩa của chúng sẽ không được giải quyết tại thời điểm liên kết từ các đơn vị biên dịch khác. Nếu dự án của bạn là một dự án duy nhất của C ++ sử dụng nhiều mẫu, quy ước này sẽ hữu ích.

Một số thư viện mẫu nhất định tuân thủ quy ước này cung cấp các tiêu đề với phần mở rộng .hpp để cho biết rằng chúng không có tệp .cpp tương ứng.

một quy ước khác là sử dụng .h cho các tiêu đề C và .hpp cho C ++; một ví dụ tốt sẽ là thư viện boost.

Trích dẫn từ Boost FAQ,

Phần mở rộng tệp truyền thông "loại" của tệp, cho cả người và chương trình máy tính. Phần mở rộng '.h' được sử dụng cho các tệp tiêu đề C và do đó truyền đạt điều sai về các tệp tiêu đề C ++. Không sử dụng phần mở rộng không liên lạc gì và buộc kiểm tra nội dung tệp để xác định loại. Sử dụng '.hpp' xác định rõ ràng đó là tệp tiêu đề C ++ và hoạt động tốt trong thực tế. (Rainer Deyke)

Gần đây tôi đã bắt đầu sử dụng *.hppcho các tiêu đề c ++.

Lý do là tôi sử dụng emacs làm trình soạn thảo chính của mình và nó tự động vào chế độ c khi bạn tải một *.htệp và vào chế độ c ++ - khi bạn tải một *.hpptệp.

Ngoài thực tế đó, tôi thấy không có lý do chính đáng để lựa chọn *.hhơn *.hpphoặc ngược lại.

Tôi đang trả lời câu hỏi này như một lời nhắc nhở, để đưa ra nhận xét cho (các) nhận xét của tôi về câu trả lời "user1949346" cho cùng OP này.

Vì vậy, như nhiều người đã trả lời: một trong hai cách là tốt. Tiếp theo là nhấn mạnh ấn tượng riêng của họ.

Giới thiệu, cũng như trong các bình luận có tên trước đó đã nêu, ý kiến ​​của tôi là C++phần mở rộng tiêu đề được đề xuất là .hnếu thực sự không có lý do nào chống lại nó.

Vì các tài liệu ISO / IEC sử dụng ký hiệu này của các tệp tiêu đề và không có chuỗi nào khớp với .hppthậm chí xảy ra trong các tài liệu ngôn ngữ của chúng C++.

Nhưng bây giờ tôi đang nhắm đến một lý do có thể chấp nhận TẠI SAO dù cách nào cũng được, và đặc biệt là tại sao nó không phải là chủ đề của ngôn ngữ.

Vì vậy, ở đây chúng tôi đi.

Các C++tài liệu (Tôi đang thực sự tham gia tài liệu tham khảo từ phiên bản N3690) định nghĩa rằng một tiêu đề phải phù hợp với các cú pháp sau:

2.9 Tên tiêu đề

header-name:
    < h-char-sequence >
    " q-char-sequence "
h-char-sequence:
    h-char
    h-char-sequence h-char
h-char:
    any member of the source character set except new-line and >
q-char-sequence:
    q-char
    q-char-sequence q-char
q-char:
    any member of the source character set except new-line and "

Vì vậy, như chúng ta có thể trích xuất từ ​​phần này, tên tệp tiêu đề cũng có thể là bất cứ điều gì hợp lệ trong mã nguồn. Ngoại trừ việc chứa các '\n'ký tự và tùy thuộc vào việc nó có được bao gồm bởi <>nó không được phép chứa a >. Hoặc theo cách khác nếu nó được bao gồm bởi - bao ""gồm nó không được phép chứa a ".

Nói cách khác: nếu bạn có một môi trường hỗ trợ tên tệp như thế prettyStupidIdea.>, thì bao gồm:

#include "prettyStupidIdea.>"

sẽ hợp lệ, nhưng:

#include <prettyStupidIdea.>>

sẽ không hợp lệ Cách khác xung quanh giống nhau.

Và ngay cả

#include <<.<>

sẽ là một tên tập tin tiêu đề hợp lệ.

Ngay cả điều này sẽ phù hợp với C++, nó sẽ là một ý tưởng khá ngu ngốc, tho.

Và đó là lý do tại sao .hppcũng hợp lệ.

Nhưng đó không phải là kết quả của các ủy ban thiết kế quyết định cho ngôn ngữ!

Vì vậy, thảo luận về việc sử dụng .hppcũng giống như làm về nó .cc,.mm hoặc những gì tôi đã đọc trong các bài viết khác về chủ đề này.

Tôi phải thừa nhận rằng tôi không có đầu mối .hpptừ ¹ , nhưng tôi sẽ đặt cược một nhà phát minh của một số công cụ phân tích cú pháp, IDE hoặc một cái gì đó liên quan C++đến ý tưởng này để tối ưu hóa một số quy trình nội bộ hoặc chỉ để phát minh ra một số (thậm chí có thể nhất thiết cho chúng ) quy ước đặt tên mới.

Nhưng nó không phải là một phần của ngôn ngữ.

Và bất cứ khi nào một người quyết định sử dụng nó theo cách này. Có thể là vì anh ấy thích nó nhất hoặc bởi vì một số ứng dụng của quy trình công việc yêu cầu nó, nó không bao giờ ² là một yêu cầu của ngôn ngữ. Vì vậy, bất cứ ai nói "pp là bởi vì nó được sử dụng với C ++", đơn giản là sai về định nghĩa ngôn ngữ.

C ++ cho phép bất cứ điều gì tôn trọng đoạn trước. Và nếu có bất cứ điều gì mà ủy ban đề xuất sử dụng, thì nó đang sử dụng .hvì đây là phần mở rộng bị kiện trong tất cả các ví dụ của tài liệu ISO.

Phần kết luận:

Miễn là bạn không thấy / cảm thấy bất kỳ nhu cầu sử dụng .hhơn .hpphoặc ngược lại, bạn không nên bận tâm. Bởi vì cả hai sẽ là một tên tiêu đề hợp lệ có cùng chất lượng đối với tiêu chuẩn. Và do đó, bất cứ điều gì YÊU CẦU bạn sử dụng .hhoặc .hpplà một hạn chế bổ sung của tiêu chuẩn thậm chí có thể mâu thuẫn với các hạn chế bổ sung khác không phù hợp với nhau. Nhưng vì OP không đề cập đến bất kỳ hạn chế ngôn ngữ bổ sung nào, đây là câu trả lời đúng và có thể chấp nhận được cho câu hỏi

" * .h hoặc * .hpp cho định nghĩa lớp của bạn " là:

Cả hai đều chính xác như nhau và áp dụng miễn là không có hạn chế bên ngoài.

¹ _{Từ những gì tôi biết, rõ ràng, chính khung tăng cường đã đưa ra .hppphần mở rộng đó .}

² _{Tất nhiên tôi không thể nói những gì một số phiên bản trong tương lai sẽ mang lại cho nó!}

Tôi thích .hpp cho C ++ để làm rõ cho cả biên tập viên và các lập trình viên khác rằng đó là tiêu đề C ++ chứ không phải là tệp tiêu đề C.

C ++ ("C Plus Plus") có nghĩa là .cpp

Có các tệp tiêu đề có phần mở rộng .hpp không có cùng luồng logic.

Bạn có thể gọi bao gồm bất cứ điều gì bạn thích.

Chỉ cần xác định tên đầy đủ trong #include.

Tôi đề nghị rằng nếu bạn làm việc với C để sử dụng .hvà khi nào sử dụng C ++ .hpp.

Đó là cuối cùng chỉ là một quy ước.

Codegear C ++ Builder sử dụng .hpp cho các tệp tiêu đề được tạo tự động từ các tệp nguồn Delphi và các tệp .h cho các tệp tiêu đề "của riêng bạn".

Vì vậy, khi tôi viết một tệp tiêu đề C ++, tôi luôn sử dụng .h.

Trong một trong những công việc của tôi vào đầu những năm 90, chúng tôi đã sử dụng .cc và .hh cho các tệp nguồn và tiêu đề tương ứng. Tôi vẫn thích nó hơn tất cả các lựa chọn thay thế, có lẽ vì nó dễ gõ nhất.

Bjarne Stroustrup và Herb Sutter có một tuyên bố cho câu hỏi này trong hướng dẫn C ++ Core của họ được tìm thấy trên: https://github.com/isocpp/CppCoreGuiances/blob/master/CppCoreGuiances.md#S-source cũng đang đề cập đến những thay đổi mới nhất trong phần mở rộng tiêu chuẩn (C ++ 11, C ++ 14, v.v.)

SF.1: Sử dụng hậu tố .cpp cho các tệp mã và .h cho các tệp giao diện nếu dự án Y của bạn không tuân theo quy ước khác Lý do

Đó là một quy ước lâu đời. Nhưng tính nhất quán là quan trọng hơn, vì vậy nếu dự án của bạn sử dụng cái gì khác, hãy làm theo điều đó. Ghi chú

Quy ước này phản ánh một mẫu sử dụng phổ biến: Các tiêu đề thường được chia sẻ với C để biên dịch thành cả C ++ và C, thường sử dụng .h và dễ dàng hơn để đặt tên cho tất cả các tiêu đề .h thay vì có các phần mở rộng khác nhau cho chỉ các tiêu đề được dự định được chia sẻ với C. Mặt khác, các tệp triển khai hiếm khi được chia sẻ với C và do đó thường được phân biệt với các tệp .c, do đó, tốt nhất nên đặt tên cho tất cả các tệp thực hiện C ++ một cái gì đó khác (chẳng hạn như .cpp).

Tên cụ thể .h và .cpp không bắt buộc (chỉ được đề xuất làm mặc định) và các tên khác đang được sử dụng rộng rãi. Ví dụ là .hh, .C và .cxx. Sử dụng tên như vậy tương đương. Trong tài liệu này, chúng tôi đề cập đến .h và .cpp> như một cách viết tắt cho các tệp tiêu đề và triển khai, mặc dù phần mở rộng thực tế có thể khác nhau.

IDE của bạn (nếu bạn sử dụng một) có thể có ý kiến ​​mạnh mẽ về đủ.

Tôi không phải là một fan hâm mộ lớn của quy ước này bởi vì nếu bạn đang sử dụng một thư viện phổ biến như boost, tính nhất quán của bạn đã bị phá vỡ và bạn nên sử dụng .hpp tốt hơn.

Như nhiều người ở đây đã đề cập, tôi cũng thích sử dụng .hpp cho các thư viện chỉ có tiêu đề sử dụng các lớp / hàm mẫu. Tôi thích sử dụng .h cho các tệp tiêu đề kèm theo các tệp nguồn .cpp hoặc các thư viện tĩnh hoặc chia sẻ.

Hầu hết các thư viện tôi phát triển đều dựa trên mẫu và do đó chỉ cần có tiêu đề, nhưng khi viết ứng dụng, tôi có xu hướng tách khai báo khỏi triển khai và kết thúc bằng các tệp .h và .cpp

May mắn thay, nó là đơn giản.

Bạn nên sử dụng phần mở rộng .hpp nếu bạn đang làm việc với C ++ và bạn nên sử dụng .h cho C hoặc trộn C và C ++.

Tôi sử dụng .h vì đó là những gì Microsoft sử dụng và những gì trình tạo mã của họ tạo ra. Không cần phải đi ngược lại hạt lúa.

Trong "Ngôn ngữ lập trình C ++, Ấn bản thứ ba của Bjarne Stroustrup", cuốn sách C ++ phải đọc, anh ấy sử dụng * .h. Vì vậy, tôi giả sử thực hành tốt nhất là sử dụng * .h.

Tuy nhiên, * .hpp cũng tốt!

Thật dễ dàng cho các công cụ và con người để phân biệt một cái gì đó . Đó là nó.

Trong sử dụng thông thường (bằng boost, v.v.), .hppcụ thể là các tiêu đề C ++. Mặt khác, .hdành cho không phải C ++ - chỉ các tiêu đề (chủ yếu là C). Để phát hiện chính xác ngôn ngữ của nội dung nói chung là khó vì có nhiều trường hợp không tầm thường, vì vậy sự khác biệt này thường làm cho một công cụ sẵn sàng dễ sử dụng để viết. Đối với con người, một khi có được quy ước, nó cũng dễ nhớ và dễ sử dụng.

Tuy nhiên, tôi chỉ ra rằng quy ước không phải lúc nào cũng hoạt động, như mong đợi.

• Nó không bị ép buộc bởi đặc tả của các ngôn ngữ , cả C và C ++. Có nhiều dự án không tuân theo quy ước. Một khi bạn cần hợp nhất (để trộn) chúng, nó có thể gây rắc rối.
• .hppbản thân nó không phải là sự lựa chọn duy nhất Tại sao không .hhhay .hxx? (Mặc dù vậy, bạn thường cần ít nhất một quy tắc thông thường về tên tệp và đường dẫn.)

Cá nhân tôi sử dụng cả .hvà .hpptrong các dự án C ++ của mình. Tôi không tuân theo quy ước trên vì:

• Các ngôn ngữ được sử dụng bởi mỗi phần của dự án được ghi lại rõ ràng. Không có cơ hội trộn C và C ++ trong cùng một mô-đun (thư mục). Mỗi thư viện của bên thứ 3 được yêu cầu tuân thủ quy tắc này.
• Các đặc tả ngôn ngữ phù hợp và phương ngữ ngôn ngữ được phép sử dụng bởi các dự án cũng được ghi lại. (Trên thực tế, tôi thậm chí còn ghi lại nguồn gốc của các tính năng tiêu chuẩn và sửa lỗi (theo tiêu chuẩn ngôn ngữ) đang được sử dụng .) Điều này có phần quan trọng hơn so với việc phân biệt các ngôn ngữ được sử dụng vì nó quá dễ bị lỗi và chi phí kiểm tra (ví dụ: khả năng tương thích trình biên dịch) có thể là đáng kể (phức tạp và tốn thời gian), đặc biệt là trong một dự án đã có trong C ++ gần như thuần túy . Tên tập tin quá yếu để xử lý việc này.
• Ngay cả đối với cùng một phương ngữ C ++, có thể có các thuộc tính quan trọng hơn phù hợp với sự khác biệt. Ví dụ, xem quy ước dưới đây.
• Tên tệp về cơ bản là những mảnh siêu dữ liệu dễ vỡ. Việc vi phạm quy ước không quá dễ dàng để phát hiện. Để ổn định xử lý nội dung, một công cụ cuối cùng không chỉ phụ thuộc vào tên. Sự khác biệt giữa các phần mở rộng chỉ là một gợi ý. Các công cụ sử dụng nó cũng không nên được mong đợi hoạt động giống nhau mọi lúc, ví dụ: phát hiện ngôn ngữ của .hcác tệp trên github.com. (Có thể có một số điều trong các nhận xét như shebang cho các tệp nguồn này là siêu dữ liệu tốt hơn, nhưng thậm chí nó không thông thường như tên tệp, do đó nói chung cũng không đáng tin cậy.)

Tôi thường sử dụng .hpptrên các tiêu đề C ++ và các tiêu đề nên được sử dụng (duy trì) theo cách chỉ tiêu đề , ví dụ như các thư viện mẫu. Đối với các tiêu đề khác .h, có một .cpptệp tương ứng khi thực hiện hoặc đó là một tiêu đề không phải C ++. Cái sau là tầm thường để phân biệt thông qua nội dung của tiêu đề bởi con người (hoặc bằng các công cụ có siêu dữ liệu nhúng rõ ràng, nếu cần).

Phần mở rộng của tệp nguồn có thể có ý nghĩa đối với hệ thống xây dựng của bạn, ví dụ: bạn có thể có một quy tắc trong tệp tạo tệp của bạn .cpphoặc .ctệp, hoặc trình biên dịch của bạn (ví dụ: Microsoft cl.exe) có thể biên dịch tệp thành C hoặc C ++ tùy thuộc vào tiện ích mở rộng.

Bởi vì bạn phải cung cấp toàn bộ tên tệp cho lệnh #include, phần mở rộng tệp tiêu đề là không liên quan. Bạn có thể bao gồm một .ctệp trong một tệp nguồn khác nếu bạn muốn, bởi vì đó chỉ là một văn bản bao gồm. Trình biên dịch của bạn có thể có một tùy chọn để loại bỏ đầu ra được xử lý trước, điều này sẽ làm rõ điều này (Microsoft: /Pđể tiền xử lý để tập tin, /Etiền xử lý stdout, /EPbỏ qua các #linechỉ thị, /Cđể giữ lại các bình luận)

Bạn có thể chọn sử dụng .hppcho các tệp chỉ liên quan đến môi trường C ++, tức là họ sử dụng các tính năng không được biên dịch trong C.

Không có lợi thế cho bất kỳ tiện ích mở rộng cụ thể nào, ngoài tiện ích mở rộng đó có thể có ý nghĩa khác với bạn, trình biên dịch và / hoặc các công cụ của bạn. header.hlà một tiêu đề hợp lệ. header.hpplà một tiêu đề hợp lệ. header.hhlà một tiêu đề hợp lệ. header.hxlà một tiêu đề hợp lệ. h.headerlà một tiêu đề hợp lệ. this.is.not.a.valid.headerlà một tiêu đề hợp lệ trong phủ nhận. ihjkflajfajfklaflà một tiêu đề hợp lệ. Miễn là tên có thể được phân tích cú pháp đúng bởi trình biên dịch và hệ thống tệp hỗ trợ nó, đó là một tiêu đề hợp lệ và lợi thế duy nhất cho phần mở rộng của nó là những gì người ta đọc vào nó.

Điều đó đang được nói, việc có thể đưa ra các giả định chính xác dựa trên tiện ích mở rộng là rất hữu ích, vì vậy sẽ là khôn ngoan khi sử dụng một bộ quy tắc dễ hiểu cho các tệp tiêu đề của bạn. Cá nhân, tôi thích làm một cái gì đó như thế này:

1. Nếu đã có bất kỳ hướng dẫn được thiết lập, hãy làm theo chúng để tránh nhầm lẫn.
2. Nếu tất cả các tệp nguồn trong dự án là cho cùng một ngôn ngữ, hãy sử dụng .h. Không có sự mơ hồ.
3. Nếu một số tiêu đề tương thích với nhiều ngôn ngữ, trong khi các tiêu đề khác chỉ tương thích với một ngôn ngữ, thì các tiện ích mở rộng dựa trên ngôn ngữ hạn chế nhất mà tiêu đề tương thích. Một tiêu đề tương thích với C, hoặc với cả hai C & C ++, được .h, trong khi một tiêu đề tương thích với C ++ nhưng không phải C được .hpphay .hhhay cái gì của phân loại.

Tất nhiên, đây chỉ là một trong nhiều cách để xử lý các tiện ích mở rộng và bạn không nhất thiết phải tin tưởng vào ấn tượng đầu tiên của mình ngay cả khi mọi thứ có vẻ đơn giản. Ví dụ, tôi đã thấy đề cập đến việc sử dụng .hcho các tiêu đề bình thường và .tppcho các tiêu đề chỉ chứa định nghĩa cho các hàm thành viên lớp templated, với .hcác tệp xác định các lớp templated bao gồm các .tpptệp xác định các hàm thành viên của chúng (thay vì .htiêu đề chứa trực tiếp cả hai khai báo hàm và định nghĩa). Một ví dụ khác, nhiều người luôn phản ánh ngôn ngữ của người đứng đầu trong phần mở rộng của nó, ngay cả khi không có cơ hội mơ hồ; đối với họ, .hluôn là một tiêu đề C và .hpp(hoặc.hh , hoặc.hxx, v.v.) luôn là một tiêu đề C ++. Và một lần nữa, một số người sử dụng .hcho "tiêu đề được liên kết với một tệp nguồn" và .hppcho "tiêu đề với tất cả các chức năng được xác định nội tuyến".

Xem xét điều này, lợi thế chính sẽ đến khi liên tục đặt tên các tiêu đề của bạn theo cùng một kiểu và làm cho phong cách đó trở nên rõ ràng đối với bất kỳ ai kiểm tra mã của bạn. Bằng cách này, bất kỳ ai quen thuộc với phong cách mã hóa thông thường của bạn sẽ có thể xác định ý của bạn với bất kỳ tiện ích mở rộng nhất định nào chỉ bằng một cái nhìn lướt qua.