Czy posiadanie plików nagłówkowych C ++ bez rozszerzenia to dobra praktyka?

9

Mam kłótnię z kolegą dotyczącą wytycznych C ++, których należy przestrzegać.

Obecnie projektuje wszystkie swoje biblioteki w ten sposób:

W nazwach plików używa niekonsekwentnie wielkich i małych liter
Niektóre z jego nagłówków nie mają żadnego rozszerzenia

Uważam, że brak rozszerzenia jest czymś zarezerwowanym dla standardowych plików C ++ i że stosowanie wielkich liter jest podatne na błędy (szczególnie w przypadku kodu, który ma działać zarówno w systemie Windows, jak i Linux).

Chodzi mu o to, że przestrzega Qtkonwencji (nawet w przypadku kodu, który nie używa Qt) i ciągle mówi: „Jeśli Qt robi to w ten sposób, nie może być źle”.

Teraz staram się zachować otwarty umysł, ale naprawdę źle się czuję, gdy muszę pracować nad jego bibliotekami. Czy istnieje ustalony zbiór zasad dotyczących tego? Czy standard coś o tym mówi?

Dziękuję Ci bardzo.

c++ naming

— ereOn
źródło

3

#define signal……… („Jeśli Qt robi to w ten sposób, to nie może być źle.”) - Nie mogę powiedzieć, że osobiście zgadzam się ze wszystkimi ich wyborami projektowymi.

— justin

@Justin: Ja też nie. Nie mam nic przeciwko Qt. Myślę nawet, że to niesamowita biblioteka, ale niektóre z ich wyborów projektowych są dla mnie naprawdę złe.

— ereOn

1

@Justin Widziałem makra zaczynające się _w popularnym, szeroko używanym kodzie, ale jest to zdecydowanie niezgodne ze standardem.

— Luchian Grigore

1

ale oto jeden prawdziwy powód, aby unikać nagłówków bez rozszerzeń: moje podstawowe IDE i edytor tekstu nie rozpoznają ich automatycznie. używam tylko *.hppnagłówka c ++, a wszystkie moje narzędzia „rozumieją”.

— justin

5

Qt używa tej konwencji właśnie dlatego , że inteligentni programiści tego nie robią. Oznacza to, że nagłówki nie będą kolidować z nowymi nagłówkami Qt.

— MSalters

16

Rozszerzenie (lub jego brak) nie spowoduje, o ile wiem, problemów. Powiedziałbym, że całkowite upuszczenie rozszerzenia jest niewygodne, ponieważ utrudnia wyszukiwanie plików nagłówkowych (na przykład za pomocą symboli wieloznacznych * .h i * .hpp) oraz utrudnia identyfikację zawartości pliku (na przykład, jeśli Twój edytor korzysta z rozszerzenia, aby wybrać odpowiedni tryb podświetlania składni).

Z punktu widzenia kodu nie robi to dużej różnicy, nawet obudowa nie jest problematyczna, o ile wszędzie używasz spójnej skrzynki i nie różnicujesz plików tylko na podstawie różnic. Z wygodnego punktu widzenia łatwiej jest trzymać małe litery i mieć rozszerzenie (.h lub .hpp).

Ważniejsze jednak, aby którekolwiek z powyższych stwierdzeń było wybranie jednej konwencji dla całego zespołu programistów i trzymanie się jej . O wiele gorzej jest szukać nazwy pliku i jego nazwy oraz rozszerzenia, którego używa, gdy chcesz coś dołączyć - wszystko to powinno być „zgadywalne” przy znajomości rzeczy, której próbujesz użyć.

— Adam Bowen
źródło

Wybór jednej konwencji i trzymanie się jej nie jest złym pomysłem, ale co, jeśli istniejącą konwencję można ulepszyć? W takim przypadku może warto zmienić kurs.

— kotlinski

@ Kotlinski Jest to jeden z tych przypadków, w których nie można nic zrobić, aby poprawić sytuację, ponieważ wszystko, co wybierzesz, jest kwestią preferencji. Właściwie posiadanie jakiegoś rozszerzenia, powiedziałbym, jest lepsze niż żadne, ponieważ system operacyjny (czytaj, Windows) może określić, z jakim programem otworzyć plik na podstawie rozszerzenia.

— Paul

@PaulManta: Ale czy nie kłócisz się tutaj ze sobą? Po pierwsze, mówisz, że nie ma sposobu, aby coś poprawić. Następnie mówisz, że rozszerzenie jest lepsze niż nie. Jest to rodzaj defetyzmu, który mówi, że żadna zmiana nie jest możliwa.

— kotlinski

@ Kotlinski Ogólnie rzecz biorąc, myślę, że to zależy od tego, ile starego kodu będziesz pracował, czy opłacalne byłoby przejście do nowej konwencji i jaki byłby wpływ konwencji mieszania. W tym przypadku zgadzam się jednak z Paulem Mantą - jest to w większości preferencja osobista, przy czym większość jest preferowana z powodów praktycznych.

— Adam Bowen

1

@ Kotlinski Nie ma sposobu, aby coś poprawić, ale są sposoby na pogorszenie sytuacji. Ta dyskusja jest tak samo bezcelowa jak dyskusja między spacjami a tabulatorami. Wybierz jedną konwencję i zrób coś pożytecznego.

— Paul

6

Nie ma reguły (w standardzie), że tylko standardowe pliki nagłówkowe mogą być bez rozszerzenia; nazwa pliku może być dowolna. Ogólna dobra praktyka sugeruje jednak, że:

żadne pliki nigdy nie będą bez rozszerzenia oraz
różne typy plików mają różne rozszerzenia - w szczególności nagłówki C ++ używają innego rozszerzenia ( .hpplub .hh) niż nagłówki, które są akceptowane przez kompilator C.

(Niestety, druga zasada jest często naruszana i często widuje się pliki nagłówkowe C ++ .h. Z własnego doświadczenia mogę zapewnić, że spowoduje to problemy z konserwacją w dalszej części drogi, ale jest to powszechna praktyka.)

W odniesieniu do wielkości liter wymagana jest szczególna ostrożność, ponieważ w nazwach plików rozróżniana jest wielkość liter w niektórych systemach, a nie w innych. Widziałem dwie różne reguły, które działają: albo wszystko małymi literami w nazwie pliku, albo nazwa pliku działa dokładnie tak samo jak w przypadku symboli w C ++.

W obu przypadkach ustalasz zasady projektu w drodze konsensusu i wszyscy je przestrzegają.

1

jestem całkowicie z Jamesem w tej sprawie. To sprawia, że koszmar sprawia, że narzędzia działają poprawnie na 2 różnych rodzajach plików nagłówkowych, jeśli mają to samo rozszerzenie.

@TomTanner A nawet gorzej, jeśli masz pliki bez rozszerzeń. Przeważnie pracowałem w środowisku Unix i zawsze mnie frustrowało (i powodowało problemy), że pliki wykonywalne nie mają rozszerzenia.

6

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

Tak. Tak, naprawdę, naprawdę może. Projekt biblioteki brzmi: „Tak bardzo chcemy być Javą”. To totalny bałagan. Biblioteka standardowa jest znacznie lepsza.

Zasadniczo jest to logiczny błąd. Projekt Qt jest warty naśladowania tylko wtedy, gdy można podać logiczne argumenty na temat tego, dlaczego jest dobry, nie jest dobry tylko dlatego, że jest Qt.

— DeadMG
źródło

Jest to argument empiryczny. Jest to duży program, z którego korzysta wiele osób. Jeśli ten wybór konwencji nazewnictwa spowodowałby poważne problemy, byłby znany i prawdopodobnie do tej pory zmieniony. Ponieważ tak nie jest, nie może być tak źle. Nie oznacza to jednak, że jest to najlepsze rozwiązanie.

— H. Rittich,

0

Jak wiem, od standardu 1998, tylko standardowe nagłówki bibliotek byłyby bez .h. Tak więc niestandardowe pliki nagłówkowe C ++ są tradycyjnie nadal zapisywane w formacie .h. Ale pamiętaj, że jest to konwencja, nie możesz używać rozszerzenia, a nawet rozszerzenia .txt, to tak, jakbyś pisał swoje klasy zaczynając od małych liter, wciąż działa, ale to nie jest konwencja.

— Mario Corchero
źródło

3

Btw „Jeśli Qt robi to w ten sposób, to nie może być źle”. to naprawdę zły argument ...

2

Standard nie ma nic do powiedzenia na temat tego, jak nagłówki zdefiniowane przez użytkownika powinny być nazwami. Określa tylko nazwy standardowych nagłówków.

— Mike Seymour,

0

Są to konwencje, a nie reguły. Nie ma ograniczeń w przestrzeganiu konwencji, ale konwencje ułatwiają życie, gdy przychodzisz w celach informacyjnych.

zgodnie z rozszerzeniami (.h, .hpp) te pliki, które zostały uwzględnione w c ++ nie muszą mieć rozszerzeń, musisz użyć rozszerzeń, jeśli używasz nagłówków innych niż c ++, takich jak biblioteki c lub biblioteki rozszerzeń.