Анализируем размер проекта
Среди метрик качества проекта теоретики выделяют число LOC == lines of code, измеряемое обычно в тысячах.
Для измерения размера проекта в строках кода есть интересный проект cloc, запускаемый в том числе в docker (зачем docker?).
Cloc для заданного каталога анализирует все файлики, по расширению и содержимому файлов определяет язык программирования, считает число пустых строк, строк с комментариями и строки кода. На мой взгляд, удобнее бы смотреть на итоговую сумму, но я заставить его выводить total не смог.
А теперь интересное. LOC является очень противоречивой метрикой для контроля. С одной стороны, чем меньше проект, тем лучше. С другой — сокращение размера кода может вредить его читаемости.
Пост из канала DevFM.

Ваш вывод в финальных строках связан с тем, что вы просто неправильно используете эту метрику )
Она не дает, и не может дать какого-то точного значения, используемого в расчетах - как какой-нибудь модуль прочности или предельное усилие разрыва.
Она дает только оценку размера проекта, его масштаба.
Лучше использовать не само количество строк кода, а его логарифм )
Ну, или оценивать цифру не по точному значению, а по "количеству нулей в конце".
Проект в 100 строк подходит для задач начинающим.
Проект в 2000 строк подходит для задач студентам - программистам. (Даже такого размера проекты преподавателю будет трудно проверить. Но на меньшем размере студенту вообще не понять, зачем нужно как-то структурировать код.)
Проект размером несколько десятков тысяч строк - скорей всего, потребует не одного программиста, а команды. До 10 000 строк можно и "в одну каску" писать.
P.S. Еще вспомнил. Для очень примерной оценки производительности на уровне "делал что-нибудь или нихера не делал". Если человек две недели работал, говорит, что писал код, а кода написано меньше тысячи строк - что-то тут не так. Или он не код писал, а придумывал алгоритм, структуру или т.п. Или он просто врет.