Код метрики требуется. Соотношение LOCs в h-файлах к LOCs в cpp-файлах в оптимальном коде
Могу ли я оценить, каково будет число LOC C ++ в оптимальном коде (десктоп-приложение), учитывая количество LOC в h-файлах?
Фон:
Я делаю оценку усилий и план по портированию программного обеспечения C ++ на C #.
Моя первая идея состояла в том, чтобы создать приблизительную оценку на основе LOC и отслеживать процесс, используя LOC, перенесенные в оставшиеся LOC. Предполагая, что скорость портирования будет 200LOCs / сут, я пришел к 1,5 человеко-годам. Если я представлю эту цифру заказчику, я точно не получу контракт.
После более пристального взгляда на код я обнаружил, что код очень неэффективен, использует много-много C&P-код, реализует собственные контейнерные классы и т. Д.
Таким образом, LOC-номер C ++, похоже, не отражает усилий по реализации той же функциональности. Теперь я предполагаю, что заголовочный файл должен лучше отражать функциональность.
Решение
Не с той же целью, однако для любопытства я однажды проверил свои LOC с cloc для проекта в его промежуточной (до альфа) стадии. Это не было хорошо задокументировано, и некоторые из его мест были слегка грязными или плохо спланированы.
C++ 100 2545 3252 11680
C/C++ Header 108 2847 12721 9077
C 4 1080 971 6298
CMake 33 241 161 1037
Bourne Shell 4 16 0 709
Python 8 90 72 423
CSS 1 63 21 422
PHP 5 23 21 295
Javascript 5 42 23 265
JSON 4 0 0 183
XML 1 11 171 72
make 1 13 0 15
Bourne Again Shell 2 10 0 14
Как вы можете видеть, соотношение между заголовком LOC и источником LOC составляет 0.777, тем не мение average не является хорошим показателем для чего-либо. Но наряду с другими показателями, например строки комментария могут быть нарисованы нечеткие линии для обозначения различных параметров и этапов разработки. Требуются дополнительные исследования хорошо известных кодовых баз, чтобы придумать хорошие ураганы.
Но в конце концов, какие бы меры вы ни предприняли, он может заключить предположение, которое может быть неверным.
Другие решения
Нет. Размер заголовочного файла — это действительно плохой прокси для размера ассоциированного файла кода. Заголовок показывает только точки входа в API, и он может скрывать столько, сколько нужно API.
Другими словами, заголовок, который объявляет единственную функцию, говорит только о том, что в этом файле реализации есть одна общедоступная функция. Файл реализации может иметь только одну функцию или сотни. Ни один из них не лучше, нет ничего плохого в любом подходе к разработке. Это просто означает, что вы не можете использовать заголовки для оценки усилий.
С программой 100k SLOCs было бы очень сложно использовать SLOC в качестве меры, потому что вы потратите больше времени на тестирование, чем на разработку. Если у вас есть доступ к документации по функциям приложения, рассмотрите возможность использования функциональные точки вместо. Судя по тому, что я слышал, это одна из наименее нарушенных эвристик.
Что касается разработки, не забывайте, что вы можете вызывать код C ++ из C # и что C ++ / CX может интегрировать C #. Это может облегчить портирование, если вы можете просто постепенно переписывать более или менее независимые компоненты.
Заголовочный файл не может быть индикатором.
Заголовочные файлы обычно содержат объявления функций — интерфейс или инструкции по вызову функции.
Функции в исходных файлах могут быть нулевыми операторами или сотнями LOC. Невозможно определить количество операторов или строк в функции, посмотрев на объявление функции.
Многие счетчики LOC включают как заголовочные файлы, так и исходные файлы.