Полезно ли иметь заголовочные файлы C ++ без расширения?

9

У меня есть спор с моим коллегой относительно руководящих принципов C ++.

В настоящее время он проектирует все свои библиотеки таким образом:

Он использует непоследовательные прописные и строчные буквы в своих именах файлов
Некоторые из его заголовков не имеют расширения

Я считаю, что отсутствие расширения является чем-то зарезервированным для стандартных файлов C ++, и использование заглавных букв подвержено ошибкам (особенно, когда вы имеете дело с кодом, который предназначен для работы как в Windows, так и в Linux).

Он Qtсчитает, что он следует соглашениям (даже для кода, который не использует Qt) и продолжает говорить: «Если Qt делает это таким образом, то это не может быть плохо».

Сейчас я стараюсь сохранять открытость, но мне действительно плохо, когда мне приходится работать с / с его библиотеками. Существует ли общий установленный набор правил в отношении этого? Стандарт говорит что-то об этом?

Большое спасибо.

c++ naming

— ereOn
источник

3

#define signal……… («Если Qt делает это таким образом, то это не может быть плохо.») - я не могу сказать, что лично согласен со всеми их вариантами дизайна.

— Джастин

@Justin: я тоже. Я ничего не имею против Qt. Я даже думаю, что это удивительная библиотека, но некоторые из их вариантов дизайна действительно кажутся мне неправильными.

— ereOn

1

@Justin Я видел макросы, начинающиеся _в популярном, широко используемом коде, но он явно не соответствует стандарту.

— Лучиан Григоре

1

но есть одна реальная причина избегать заголовков без расширений: моя основная IDE и текстовый редактор не распознают их автоматически. я просто использую *.hppдля заголовка c ++, и все мои инструменты "получить его".

— Джастин

5

Qt использует это соглашение именно потому , что умные программисты этого не делают. Это означает, что ваши заголовки не будут конфликтовать с новыми заголовками Qt.

— MSalters

16

Насколько я знаю, расширение (или его отсутствие) не вызовет проблем. Я бы сказал, что удаление расширения вообще неудобно, так как затрудняет поиск файлов заголовков (например, с использованием подстановочных знаков * .h и * .hpp) и затрудняет идентификацию содержимого файла (например, если Ваш редактор использует расширение, чтобы выбрать правильный режим подсветки синтаксиса).

С точки зрения кода это не имеет большого значения, даже регистр не является проблематичным, если вы везде используете непротиворечивый регистр и не полагаетесь только на различия регистров для различения файлов. С точки зрения удобства проще придерживаться строчных букв и иметь расширение (.h или .hpp).

Однако более важно то, что любое из вышеперечисленного заключается в том, чтобы выбрать одно соглашение для всей команды разработчиков и придерживаться его . Гораздо хуже искать информацию о том, как файл назван и какое расширение он использует, когда вы хотите что-то включить - все это должно быть «угадано» со знанием того, что вы пытаетесь использовать.

— Адам Боуэн
источник

Выбор одной конвенции и ее соблюдение - неплохая идея, но что, если существующая конвенция может быть улучшена? В этом случае, возможно, это хорошая идея, чтобы изменить курс.

— Котлински

@kotlinski Это один из тех случаев, когда вы ничего не можете сделать, чтобы улучшить ситуацию, потому что все, что вы выбираете, является вопросом предпочтения. На самом деле, иметь какое-то расширение, я бы сказал, лучше, чем ничего, потому что ОС (читай, Windows) может определить, с какой программой открыть файл, основываясь на расширении.

— Пол

@PaulManta: Но ты не споришь против себя здесь? Во-первых, вы говорите, что нет способа улучшить что-либо. Затем вы говорите, что иметь расширение лучше, чем нет. Это своего рода пораженческое отношение, когда говорят, что изменения невозможны.

— Котлински

@kotlinski В общем, я думаю, это зависит от того, сколько старого кода вы будете работать, будет ли жизнеспособным изменить все это на новое соглашение и каковы будут последствия соглашений о смешивании. В этом случае, хотя я согласен с Полом Мантой - это в основном личные предпочтения, причем большинство предпочитают расширение по практическим соображениям.

— Адам Боуэн

1

@kotlinski Нет никакого способа улучшить что-либо, но есть способы сделать вещи хуже. Это обсуждение так же бессмысленно, как и обсуждение пробелов-вкладок. Просто выберите одно соглашение и сделайте что-нибудь полезное.

— Пол

6

Не существует правила (в стандарте), что только стандартные заголовочные файлы могут быть без расширения; имя файла может быть почти любым, что вы хотите. Общая хорошая практика, однако, предполагает, что:

никакие файлы никогда не будут без расширения, и
Разные типы файлов имеют разные расширения - в частности, заголовки C ++ используют другое расширение ( .hppили .hh), чем заголовки, приемлемые для компилятора C.

(К сожалению, второе правило часто нарушается, и часто можно увидеть заголовочные файлы C ++ .h. Из личного опыта я могу заверить, что это вызовет проблемы с техническим обслуживанием в будущем, но это обычная практика.)

Что касается регистра, требуется крайняя осторожность, поскольку имена файлов чувствительны к регистру в некоторых системах, а не в других. Я видел два разных правила, которые работают: либо все в нижнем регистре в имени файла, либо имя файла следует точно таким же правилам в отношении регистра, как и для символов в C ++.

В обоих случаях вы устанавливаете правила для проекта на основе консенсуса, и все следуют им.

1

Я полностью с Джеймсом в этом. Это делает кошмаром получение инструментов для правильной работы с 2 различными типами заголовочных файлов, если они имеют одинаковое расширение.

@TomTanner И еще хуже, если у вас есть файлы без расширений. Я в основном работал в среде Unix, и меня всегда раздражало (и вызывало проблемы), что исполняемые файлы не имеют расширения.

6

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

Да. Да, это действительно, действительно может. Их дизайн библиотеки - «Мы так сильно хотим быть Java». Это полный беспорядок. Стандартная библиотека намного лучше.

Кроме того, по сути, это логическая ошибка. Дизайн Qt стоит подражать только в том случае, если вы можете привести логические аргументы о том, почему это хорошо, а не хорошо только потому, что это Qt.

— DeadMG
источник

Это эмпирический аргумент. Это большой программный продукт, который используется многими людьми. Если бы этот выбор соглашения об именах вызвал значительные проблемы, он был бы известен и, вероятно, уже изменен. Поскольку это не так, это не может быть слишком плохо. Это не значит, что это лучшее решение.

— Х. Риттих,

0

Как я знаю, начиная со стандарта 1998 года, только заголовки стандартных библиотек будут без .h. Поэтому нестандартные заголовочные файлы C ++ обычно по-прежнему пишутся с использованием .h. Но имейте в виду, что это соглашение, вы не можете использовать расширение или даже расширение .txt, это похоже на то, что вы пишете свои классы, начиная с нижнего регистра, это все еще работает, но это не соглашение.

— Марио Корчеро
источник

3

Кстати, «если Qt делает это таким образом, то это не может быть плохо». это действительно плохой аргумент ...

2

Стандарт ничего не говорит о том, как пользовательские заголовки должны быть именами. Он указывает только имена стандартных заголовков.

— Майк Сеймур

0

Это соглашения, а не правила, нет никаких ограничений придерживаться соглашений, но соглашения действительно облегчают жизнь, когда вы приходите за справкой.

что касается расширений (.h, .hpp), то те файлы, которые были включены в c ++, не должны иметь расширений, вам нужно использовать расширения, если вы используете заголовки, отличные от c ++, такие как библиотеки c или библиотеки boost.