Расположение исходного кода проекта C++
Поставь ниже CSS. Он будет скрывать только значок, однако сортировка будет работать.
table.dataTable thead .sorting,
table.dataTable thead .sorting_asc,
table.dataTable thead .sorting_desc,
table.dataTable thead .sorting_asc_disabled,
table.dataTable thead .sorting_desc_disabled {
background-image: none!important;
}
3 ответа
Ну, все зависит от того, насколько велики эти проекты. Если у вас всего несколько файлов, скопируйте их все в одну папку.
Слишком много папок, когда у вас мало файлов для управления, на мой взгляд, излишнее. Копаться в папках и из них становится утомительно, когда в них всего несколько файлов.
Кроме того, это зависит от того, кто использует эти вещи. Если вы пишете библиотеку и собираетесь использовать ее другими программистами, то хорошо организовать заголовки, которые они хотят использовать, во включаемую папку. Если вы создаете несколько библиотек и публикуете их все, ваша структура может работать. Но, если это независимые библиотеки, и не все разработки ведутся вместе, и они получают версии и выпускаются в разное время, вы ' Мне лучше придерживаться того, чтобы все файлы для одного проекта располагались в одной папке.
Фактически, я бы сказал, храните все в одной папке, пока вы не дойдете до точки, когда вы не обнаружите, что это неуправляемо, а затем реорганизуйте в умную схему разделения источника на папки, как вы это сделали. Вы, вероятно, поймете, как это должно быть организовано, исходя из проблем, с которыми вы столкнетесь.
KISS обычно всегда является решением в программировании -> делайте все как можно проще.
Почему бы не сделать что-то вроде первого, использовать только каталог, в котором находится MyLib , как часть директивы include, что сокращает количество глупых префиксов:
#include <MyLib/ClassA.h>
That сообщает вам, откуда они. Что касается второго варианта, меня лично очень раздражает, когда у меня открыт заголовок или исходный файл, и мне приходится перемещаться по структуре каталогов, чтобы найти другой и открыть его. Во втором примере, если вы открыли src / mylib / class_a.cpp и хотите отредактировать заголовок, во многих редакторах вам придется вернуться на два уровня назад, а затем в include / ProjA до нахождения заголовка. И как нам узнать, что заголовок находится в подкаталоге ProjA без какой-либо другой внешней подсказки? Плюс, это Слишком легко переместить один или другой файл в другое место, которое «лучше» представляет, как он используется, без перемещения альтернативного файла. Это вызывает у меня головную боль, когда я сталкиваюсь с этим на работе (и у нас есть некоторые части нашей кодовой базы, где люди решали все потенциальные проблемы, о которых я только что упомянул).
Я пробовал оба метода. Лично мне первое нравится больше. Я понимаю желание поместить все в более конкретные каталоги, но это вызывает много чрезмерных сложностей.
Я обычно использую это правило: приложения и внутренние библиотеки используют первый метод. Публичные библиотеки с открытым исходным кодом используют второй метод. Когда вы выпускаете код, очень помогает, если включаемые файлы находятся в отдельном каталоге.