Соглашение о присвоении имен для решений для Visual Studio и проекты
Включите оптимизацию компилятора, и они в основном одинаковы
проверили это на gcc 4.3.3.
int main (int argc, char** argv) {
char c = getchar();
int x = (c == 'x');
if(x == NULL)
putchar('y');
return 0;
}
и
int main (int argc, char** argv) {
char c = getchar();
int x = (c == 'x');
if(!x)
putchar('y');
return 0;
}
gcc -O -o test1 test1.c
gcc -O -o test2 test2.c
diff test1 test2
не дали результатов: )
5 ответов
Выглядит неплохо, если вы спросите меня. Особенно называйте ваши проекты их полным именем, включая часть пространства имен. Я считаю это полезным, когда существует множество проектов, особенно если в разных продуктах есть похожие проекты.
Как и разделяете ли вы продукт и проект (где я предполагаю, что проект больше похож на приложение, чем на проект решения ) очень сильно зависит от размера вашей организации, ее состава и ваших предпочтений.
Похоже, взято из школьной книги. Обычно мои решения настраиваются так, и я обнаружил, что с годами они работают достаточно хорошо.
Что касается имен файлов - я предпочитаю, чтобы имя файла моего проекта совпадало с именем выходной сборки, потому что это значительно упрощает определение того, что производит . Составление списка каталогов намного быстрее, чем поиск в файлах csproj в дереве того файла, который создает нужную мне сборку.
Я не делаю ' Я беспокоюсь о файлах решений, потому что они не влияют на нашу среду сборки, поэтому я в конечном итоге создаю свои собственные, чтобы иметь точную область действия, которую я хочу (и конкретные элементы для каждого решения, такие как метаданные тестирования, которые я хочу). ] Что касается структуры папок - я не слишком беспокоюсь, если папки, ведущие вниз по файлам проекта, совпадают с пространствами имен. Я хочу, чтобы мой код размещался на диске таким образом, чтобы это было наиболее целесообразно для проекта. Иногда это означает, что тестовый код и код продукта находятся в родственных каталогах - иногда это означает, что они намного дальше друг от друга. Иногда существует пространство имен, в которое вносят вклад несколько команд (не пропагандируя этот дизайн, а просто реальность) - но эти команды по какой-то причине хотят жить в своих собственных папках.
Дон ' Не забывайте о важности стратегий ветвления контроля версий в общем дизайне вашего проекта. Границы компании и продукта могут быть филиалами и поэтому не обязательно должны быть представлены в виде каталогов на диске.
Не позволяйте этому быть источником паралича анализа. Сделайте разумный выбор. Используйте контроль версий. Если ошибетесь, вы всегда сможете изменить его позже.
Мне нравится.
Стоит отметить, что по умолчанию пространство имен по умолчанию в проекте Visual Studio - это просто имя проекта. Несомненно, это указывает на то, что присвоение имен вашим проектам, подобным пространствам имен, - это «путь Visual Studio».
Решения наиболее естественно называются в честь продукта / проекта. Как вы указываете.
Альтернатива, которую я Используется, чтобы все мои файлы решений находились в одном каталоге.
\trunk
[CompanyName]
CompanyName.Product1.sln
CompanyName.Product2.sln
[Product1]
[Project1]
CompanyName.Product1.Project1.csproj
[Project2]
CompanyName.Product1.Project2.csproj
[Product2]
[Project3]
CompanyName.Product2.Project3.csproj