Có tập tin tiêu đề C ++ mà không cần mở rộng là một thực hành tốt?

9

Tôi có một cuộc tranh luận với một đồng nghiệp của tôi về các hướng dẫn của C ++ để tuân theo.

Ông hiện đang thiết kế tất cả các thư viện của mình theo cách đó:

Anh ta sử dụng chữ in hoa và chữ thường không nhất quán trong tên tệp của mình
Một số tiêu đề của anh ta không có bất kỳ phần mở rộng

Tôi tin rằng không có phần mở rộng là thứ dành riêng cho các tệp tiêu chuẩn C ++ và việc sử dụng chữ in hoa dễ bị lỗi (nhất là khi bạn xử lý mã có nghĩa là hoạt động trên cả Windows và Linux).

Quan điểm của ông là ông tuân theo Qtcác quy ước (ngay cả đối với mã không sử dụng Qt) và tiếp tục nói: "Nếu Qt làm theo cách đó, thì nó không thể xấu."

Bây giờ tôi cố gắng giữ một tinh thần cởi mở, nhưng tôi thực sự cảm thấy tồi tệ khi tôi phải làm việc trên / với các thư viện của anh ấy. Có một bộ quy tắc chung được thiết lập liên quan đến điều này? Liệu tiêu chuẩn nói lên điều gì về nó?

Cảm ơn rât nhiều.

c++ naming

— ereOn
nguồn

3

#define signalNhiều như vậy ("Nếu Qt làm theo cách đó, thì nó không tệ.") - Tôi không thể nói rằng cá nhân tôi đồng ý với tất cả các lựa chọn thiết kế của họ.

— justin

@Justin: Tôi cũng không có gì Qt. Tôi thậm chí nghĩ rằng đó là một thư viện tuyệt vời nhưng một số lựa chọn thiết kế của họ thực sự cảm thấy sai đối với tôi.

— vào

1

@Justin Tôi đã thấy các macro bắt đầu bằng mã _phổ biến, được sử dụng rộng rãi, nhưng nó chắc chắn trái với tiêu chuẩn.

— Luchian Grigore

1

nhưng đây là một lý do thực sự để tránh các tiêu đề không có phần mở rộng: IDE chính và trình soạn thảo văn bản của tôi sẽ không tự động nhận ra chúng. tôi chỉ sử dụng *.hppcho một tiêu đề c ++ và tất cả các công cụ của tôi "có được".

— justin

5

Qt sử dụng quy ước đó chính xác bởi vì các lập trình viên thông minh thì không. Điều đó có nghĩa là các tiêu đề của bạn sẽ không xung đột với các tiêu đề Qt mới.

— MSalters 17/212

16

Theo tôi biết, tiện ích mở rộng (hoặc thiếu) sẽ không gây ra sự cố cho bạn. Tôi sẽ nói rằng việc bỏ hoàn toàn phần mở rộng là bất tiện vì nó gây khó khăn cho việc tìm kiếm tệp tiêu đề (ví dụ với các ký tự đại diện * .h và * .hpp) và việc xác định nội dung của tệp khó khăn hơn (ví dụ: trình chỉnh sửa của bạn dựa vào phần mở rộng để chọn chế độ tô sáng cú pháp phù hợp).

Từ quan điểm mã, nó không tạo ra nhiều khác biệt, thậm chí vỏ không có vấn đề gì, miễn là bạn sử dụng một trường hợp nhất quán ở mọi nơi và không chỉ dựa vào sự khác biệt của trường hợp để phân biệt các tệp. Từ quan điểm thuận tiện, dễ dàng sử dụng chữ thường hơn và có phần mở rộng (.h hoặc .hpp).

Tuy nhiên, điều quan trọng hơn là bất kỳ điều nào ở trên là chọn một quy ước cho toàn bộ nhóm phát triển của bạn và tuân thủ nó . Điều tồi tệ hơn nhiều là phải tìm kiếm cách một tập tin được đặt tên, đặt tên và phần mở rộng mà nó sử dụng bất cứ khi nào bạn muốn bao gồm một cái gì đó - tất cả những thứ này nên "có thể đoán được" với kiến thức về thứ bạn đang cố gắng sử dụng.

— Adam Bowen
nguồn

Chọn một quy ước và gắn bó với nó không phải là một ý tưởng tồi, nhưng nếu quy ước hiện tại có thể được cải thiện thì sao? Trong trường hợp đó, có lẽ đó là một ý tưởng tốt để thay đổi khóa học.

— kotlinski

@kotlinski Đây là một trong những trường hợp bạn không thể làm gì để cải thiện tình hình vì bất cứ điều gì bạn chọn đều là vấn đề ưu tiên. Trên thực tế, có một số phần mở rộng, tôi nói, tốt hơn là không có, bởi vì HĐH (đọc, Windows) có thể xác định chương trình nào để mở tệp dựa trên tiện ích mở rộng.

— Paul

@PaulManta: Nhưng không phải bạn đang tranh cãi với chính mình ở đây sao? Đầu tiên, bạn nói rằng không có cách nào để cải thiện bất cứ điều gì. Sau đó, bạn nói có một phần mở rộng là tốt hơn không. Đó là một loại thái độ thất bại, nói rằng không có thay đổi là có thể.

— kotlinski

@kotlinski Nói chung, tôi đoán điều đó phụ thuộc vào việc bạn sẽ làm việc với bao nhiêu mã cũ, liệu có thể thay đổi tất cả thành quy ước mới hay không và tác động của các quy ước trộn sẽ là gì. Trong trường hợp này mặc dù tôi đồng ý với Paul Manta - chủ yếu là sở thích cá nhân, với phần mở rộng được ưa thích bởi hầu hết các lý do thực tế.

— Adam Bowen

1

@kotlinski Không có cách nào để cải thiện bất cứ điều gì, nhưng có nhiều cách để làm mọi thứ tồi tệ hơn. Cuộc thảo luận này là vô nghĩa như cuộc thảo luận về không gian-tab. Chỉ cần chọn một quy ước và đi làm một cái gì đó hữu ích.

— Paul

6

Không có quy tắc (trong tiêu chuẩn) rằng chỉ các tệp tiêu đề tiêu chuẩn có thể không có phần mở rộng; tên tệp có thể là bất cứ thứ gì bạn muốn. Tuy nhiên, thực hành tốt nói chung cho thấy rằng:

không có tập tin nào mà không có phần mở rộng và
Các loại tệp khác nhau có các phần mở rộng khác nhau Đặc biệt, các tiêu đề C ++ sử dụng một phần mở rộng ( .hpphoặc .hh) khác với các tiêu đề được trình biên dịch C chấp nhận.

(Rất tiếc, quy tắc thứ hai thường bị vi phạm và người ta thường thấy các tệp tiêu đề C ++ .h. Từ kinh nghiệm cá nhân, tôi có thể đảm bảo rằng điều này sẽ gây ra sự cố bảo trì, nhưng đó là thông lệ.)

Liên quan đến trường hợp, cần hết sức cẩn thận, vì tên tệp là trường hợp nhạy cảm trong một số hệ thống chứ không phải trong các hệ thống khác. Tôi đã thấy hai quy tắc khác nhau hoạt động: hoặc mọi thứ viết thường trong tên tệp hoặc tên tệp tuân theo chính xác các quy tắc liên quan đến trường hợp như đối với các ký hiệu trong C ++.

Trong cả hai trường hợp, bạn thiết lập các quy tắc cho dự án, bằng sự đồng thuận và mọi người tuân theo chúng.

1

Tôi hoàn toàn với James về điều này. Nó làm cho nó trở thành một cơn ác mộng khi các công cụ hoạt động phù hợp trên 2 loại tệp tiêu đề khác nhau nếu có cùng một phần mở rộng.

@TomTanner Và thậm chí còn tệ hơn nếu bạn có tệp không có tiện ích mở rộng. Tôi hầu như đã làm việc trong môi trường Unix và điều đó luôn làm tôi thất vọng (và gây ra sự cố) rằng các tệp thực thi không có phần mở rộng.

6

If Qt does it that way, then it can't be bad.

Đúng. Vâng, nó thực sự, thực sự có thể. Thiết kế thư viện của họ là "Chúng tôi rất muốn trở thành Java". Đó là một mớ hỗn độn. Thư viện tiêu chuẩn tốt hơn nhiều.

Ngoài ra, về cơ bản, đó là một ngụy biện logic. Thiết kế của Qt chỉ có giá trị mô phỏng nếu bạn có thể đưa ra lập luận hợp lý về lý do tại sao nó tốt, nó không tốt chỉ vì nó là Qt.

— DeadMG
nguồn

Đó là một lập luận theo kinh nghiệm. Nó là một sản phẩm phần mềm lớn được nhiều người sử dụng. Nếu sự lựa chọn quy ước đặt tên này gây ra nhiều vấn đề quan trọng, nó sẽ được biết đến và có thể thay đổi ngay bây giờ. Vì đây không phải là trường hợp, nó có thể là quá xấu. Điều đó không có nghĩa là nó là giải pháp tốt nhất.

— H. Rittich

0

Như tôi biết, kể từ năm 1998, chỉ có các tiêu đề thư viện tiêu chuẩn sẽ không có .h. Vì vậy, các tệp tiêu đề C ++ không chuẩn vẫn được ghi bằng .h. Nhưng hãy nhớ rằng đó là một quy ước, bạn không thể sử dụng tiện ích mở rộng hoặc thậm chí .txt, giống như bạn viết các lớp bắt đầu bằng chữ thường, nó vẫn hoạt động, nhưng đó không phải là quy ước.

— Mario Corchero
nguồn

3

Btw "Nếu Qt làm theo cách đó, thì nó không thể tệ được." đó là một cuộc tranh luận thực sự tồi tệ ...

2

Tiêu chuẩn không có gì để nói về cách các tiêu đề do người dùng xác định nên là tên. Nó chỉ xác định tên của các tiêu đề tiêu chuẩn.

— Mike Seymour

0

Đây là những quy ước không phải là quy tắc không có ràng buộc để tuân thủ các quy ước, nhưng các quy ước làm cho cuộc sống dễ dàng hơn khi bạn đến xung quanh để tham khảo.

theo các tiện ích mở rộng (.h, .hpp) những tệp được bao gồm trong c ++ không cần phải có tiện ích mở rộng, bạn cần sử dụng các tiện ích mở rộng nếu bạn đang sử dụng các tiêu đề từ ngoài c ++, như thư viện c hoặc thư viện boost.