кто сколько пишет строк в день?

[Strannik-au]

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

[homo ludens]

наверное у нас разные представления о програмировании. возможно для простых кодеров все так как вы и описываете.

Имхо простым кодерам это все нафиг не надо. Вообще в небольших конторах такие вещи редко приживаются. Да и в средних не часто.

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

Да в общем-то согласен, только кроме обезьян и кодеров (в т.ч. и индийских) есть еще те, кто ими управляет и вынужден их контролировать.
И вот для них идея метрик очень ценна - они могут ставить рамки и цели в терминах этих метрик. Например - LOC не может превысить 100К. Или - отношение resolved bugs к new bugs на одну строку кода должно увеличиваться и выйти на 0.999999 к такому-то числу.
И т.п.
Это область менеджмента а не программизма, там своих заморочек хватает.

PS
Кстати об

а вот думать обезьяну не научишь

[офф-топ]
[боян]
http://www.newsru.com/world/06Aug2003/baboo.html
http://www.newtechusa.com/ppi/pressroom.asp
[/боян]
[/офф-топ]

[ZSunny]

Среднее количество багов на строку кода.
Среднее количество операторов goto на строку кода.
Среднее количество ветвлений на строку кода.
И т.п.
И везде требуется количество строк кода в единицу времени.

IMHO, такой подход ("количество строк кода в единицу времени"), да и вообще использование метрик как "чего-то, что вывешивается на стену" или "чего-то, что в первую очередь определяет зарплату" - подход, применимый только в весьма специфических условиях. Для "чистых кодеров", которые просто переносят уже детально разжеванные спецификации ("метод q класса w должен делать маленькое и понятное действие r") - пожалуй. Но если должность software engineer предусматривает и кодирование, и исследования по сторонним продуктам/библиотекам, и часть работы архитектора - метрики, о которых говорят вслух, вредны. Поскольку есть "20/80" - в данном случае, 20% функциональности пишется 80% времени: кто захочет писать эти 20% функциональности, понизить свои метрики и не получить премию? Кто захочет спокойно посидеть с чашкой чая и обсудить архитектуру? В конце концов, кто будет бороться с копипастом и следить за качеством кода?
А как средство "тихого" контроля за junior developer-ами (с большим числом оговорок, конечно), или же как средство построения приближенных estimate-ов (опять-таки, с оговорками) - пожалуй.

Подбрасываю в обсуждение еще две ссылки:
http://en.wikipedia.org/wiki/Source_lines_of_code#Disadvantages
http://local.joelonsoftware.com/mediawiki/index.php/Измерения_продуктивности

[homo ludens]

А я в общем-то почти тоже самое и говорил.
LOC в чистом виде - очень грубая и малополезная оценка, если пользоваться ей только для контроля.

Но есть и другие моменты использования.
Из личной практики.
1. Обсуждение заказа
Заказчик: А почему на этом этапе ты бюджет увеличил на 66 килобаксов?
Испольнитель: А потому что по твоим дополнительным требованиям объем кода по предварительным оценкам превысит ранее планировавшийся на 60 килострок.

В результате - грамотное обоснование придумано, деньги уплачены, все довольны. И это есть пример самого правильного использования LOC-метрики.

Пример других метрик.
2. Сливаю проект из субпроектов. Совещание с руководителями субпроектов.
Налицо завышенная связность модулей внутри каждой индивидуальной библиотеки. Результат совещания: в любом use case результирующей библиотеки вложенность инклюдов не должна превышать 3 уровней, не должно быть инклюдов, образующих циклов в графе вложенности.
И что это как не топологическая метрика?

[Andreas]

в момент отладки продукта, исправления ошибок, можно не то что не написать новых строк, а и удалить 50 старых (рефакторинг)
так может мне за это зарплату урезать??

[крыс]

конечно урезать чтоб неповадно было стоки удалять и рефакторинги устраивать
блин, даж не знаю, как-то никогда не считала

[homo ludens]

Вчера 601 строка - первые полдня думал как написать, вторые - писал.
Язык - С, не рефакторинг, хотя внешние интерфейсы были формализованы.
Без юнит-тестов, голый код+минимальные doxygen-комментарии.

[Илья Царюк]

Полностью согласен, глупый подход. Количеством строк мерить можно только когда надо порекламить свой продукт и сказать: Lines of core code: 100,000 lines. Number of classes: 500. Ну и бабосов если надо выбить, а в других случаях...