Привет!

Сколько строчек кода создает среднестатистический кодер C/C++ за год работая полную рабочую неделю?

36.6

Здравствуйте, alseides, Вы писали:

A>36.6
ну это в високосный год, в обычный в среднем где-то так примерно получается около 36.5.

Здравствуйте, Igor Sukhov, Вы писали:

IS>Здравствуйте, alseides, Вы писали:

A>>36.6
IS>ну это в високосный год, в обычный в среднем где-то так примерно получается около 36.5.
это с каких пор программисты работают по воскресеньям и праздникам?

Здравствуйте, RadioShark, Вы писали:

RS>Привет!

RS>Сколько строчек кода создает среднестатистический кодер C/C++ за год работая полную рабочую неделю?

6200 LOC/year

Здравствуйте, StatujaLeha, Вы писали:

A>>>36.6
IS>>ну это в високосный год, в обычный в среднем где-то так примерно получается около 36.5.
SL>это с каких пор программисты работают по воскресеньям и праздникам?

при чем тут работа ? Мы разве не о ДЛИНЕ говорим ?

Здравствуйте, bkat, Вы писали:

B>6200 LOC/year

А откуда такая инфа, если не секрет?
По моим личным прикилкам выходит несколько другая цифра.

А если брать за основу 6200 LOC/year, то в среднем получается порядка 3 LOC/hour... Не маловато ли? То есть конечно это будет маловато, если человек занят исключительно кодингом... А если он плюс к этому ещё и дворник по совместительству, то это всё меняет.

Здравствуйте, Firstborn, Вы писали:

F>Здравствуйте, bkat, Вы писали:

B>>6200 LOC/year

F>А откуда такая инфа, если не секрет?
F>По моим личным прикилкам выходит несколько другая цифра.

F>А если брать за основу 6200 LOC/year, то в среднем получается порядка 3 LOC/hour... Не маловато ли? То есть конечно это будет маловато, если человек занят исключительно кодингом... А если он плюс к этому ещё и дворник по совместительству, то это всё меняет.

Да я это высчитал из 27-30 LOC/day.
Примерно такая средняя производительность мелькает в разных источниках
и вроде у Боема (Barry Boehm) была именно такое число (могу ошибаться, так как не проверял).

Впрочем это это не столь важно.
Просто вопрос вполне нормальный и в юморе ему делать нечего.

"Firstborn" <21897@users.rsdn.ru> wrote in message
news:1580593@news.rsdn.ru...
> 3 LOC/hour... Не маловато ли? То есть конечно это будет маловато, если
> человек занят

IMHO многовато даже.
Вот у меня за крайние полгода производительность... весьма странная вышла,
рефакторинг уменьшил количество кода на пару сотен килобайт. Итого — минус
несколько строк в час... -)

SkyDance wrote:
>
>> 3 LOC/hour... Не маловато ли? То есть конечно это будет маловато, если
>> человек занят
>
> IMHO многовато даже.
> Вот у меня за крайние полгода производительность... весьма странная вышла,
> рефакторинг уменьшил количество кода на пару сотен килобайт. Итого — минус
> несколько строк в час... -)

Если бы меня спросили, я бы за уменьшение количества строк (при
сохранении функциональности) премию давал бы.

Здравствуйте, Pzz, Вы писали:

Pzz>Если бы меня спросили, я бы за уменьшение количества строк (при
Pzz>сохранении функциональности) премию давал бы.

for(i=0;i<n;i++)ar[i]=*++prt;if(*++k<*--n) *f=-f*d*r;

Помимо функциональности есть еще и читаемость, и удобство сопровождения. И даже производительность.

Sash_xp wrote:
>
> Pzz>Если бы меня спросили, я бы за уменьшение количества строк (при
> Pzz>сохранении функциональности) премию давал бы.
>
> for(i=0;i<n;i++)ar[i]=*++prt;if(*++k<*--n) *f=-f*d*r;
>
> Помимо функциональности есть еще и читаемость, и удобство сопровождения.
> И даже производительность.

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

Здравствуйте, bkat, Вы писали:

B>Да я это высчитал из 27-30 LOC/day.
B>Примерно такая средняя производительность мелькает в разных источниках
B>и вроде у Боема (Barry Boehm) была именно такое число (могу ошибаться, так как не проверял).

Буду тупо настойчив... Всё же хотелось бы ссылку хоть на один источник, а?

Firstborn wrote:
>
> B>Да я это высчитал из 27-30 LOC/day.
> B>Примерно такая средняя производительность мелькает в разных источниках
> B>и вроде у Боема (Barry Boehm) была именно такое число (могу ошибаться,
> так как не проверял).
>
> Буду тупо настойчив... Всё же хотелось бы ссылку хоть на один источник, а?

А можно поинтересоваться, какая вообще может быть полезность в такой
информации?

Здравствуйте, Pzz, Вы писали:

Pzz>А можно поинтересоваться, какая вообще может быть полезность в такой
Pzz>информации?

Это совершенно другая тема.

Здравствуйте, Pzz, Вы писали:

Pzz>Ну, я имею ввиду, что некоторые разумные правила форматирования нарушать
Pzz>при этом нельзя. Например, нельзя писать более одного оператора в
Pzz>строке. Комментарии тоже должны быть.

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

double temp = 0.0;
//бежим по всем элементам массива arr
for(int i = 0; i < arr.Length; i++)
{
    //суммируем
    temp += arr[i].Amount;
}

или

double custonerAmount = 0.0;
for(int orderNum = 0; orderNum < orders.Length; orderNum++)
{
    customerAmount += orders[orderNum].Amount;
}

Все-таки количтество строк кода далеко не так важны как другие его характеристики.

Firstborn wrote:
>
> Pzz>А можно поинтересоваться, какая вообще может быть полезность в такой
> Pzz>информации?
>
> Это совершенно другая тема.

И все-таки?

Здравствуйте, Sash_xp, Вы писали:

S_>ну комменттарии как раз не всегда обязательны, иногда даже вредны. Какой из этих примеров вам более поняттен?

Вот такой:

/***** Calculate total amount of I don't know what *****/
double customerAmount = 0;
for( int i = 0; i < orders.Length; i ++ )
    customerAmount += orders[ i ].Amount;

Комментарии говорят, что мы делаем. Код говорит, как мы это делаем.

S_>Все-таки количтество строк кода далеко не так важны как другие его характеристики.

Я хочу сказать, что при прочих равных большее количество строк кода, это недостаток, а не достоинство. Не надо оценивать программистов по количеству строк кода. Оценивать надо добавленную функциональность.

Количество строк кода — плохое мерило функциональности. Программист, который систематически употреблает cut and paste будет производить больше кода, но качество и возможность поддержки будут хуже.

Здравствуйте, Pzz, Вы писали:

Pzz>Firstborn wrote:
>>
>> Pzz>А можно поинтересоваться, какая вообще может быть полезность в такой
>> Pzz>информации?
>>
>> Это совершенно другая тема.

Pzz>И все-таки?

Например, такая информация может быть полезна при развёртывании систем управления качеством вроде SEI SW-CMM/CMMI.Да мало ли ещё для чего это может быть полезно...

Здравствуйте, Pzz, Вы писали:

Pzz>Программист, который систематически употреблает cut and paste будет...

...отт***ан в процессе peer review, будет вынужден переделать свой код по уму, а потом уже с финального варианта будут сняты все необходимые метрики, вроде LOC. Такой вот например вариант может быть.

Firstborn wrote:
>
> Например, такая информация может быть полезна при развёртывании систем
> управления качеством вроде SEI SW-CMM/CMMI.Да мало ли ещё для чего это
> может быть полезно...

Мерилом чего является количество строк кода за единицу времени?

С таким же успехом можно измерять количество электроэнергии,
потребленное компутером разработчика...

Здравствуйте, Pzz, Вы писали:


Pzz>Комментарии говорят, что мы делаем. Код говорит, как мы это делаем.

Точнее комментарии говорят, что мы хотим сделать.

S_>>Все-таки количтество строк кода далеко не так важны как другие его характеристики.

Pzz>Я хочу сказать, что при прочих равных большее количество строк кода, это недостаток, а не достоинство.
Скажем если это идет во вред читабельности, понятности кода, то это недостаток.
Тот же C++ позволяет создать крайне небольшой, но чертовски непонятный код. Уж лучше написать подлинее да читабельнее.

При прочих равнхы конечно же более краткий код предпочтительнее.

Pzz>Не надо оценивать программистов по количеству строк кода. Оценивать надо добавленную функциональность.

Pzz>Количество строк кода — плохое мерило функциональности. Программист, который систематически употреблает cut and paste будет производить больше кода, но качество и возможность поддержки будут хуже.

Это конечно так, тчолько с пример с копировать и вставить не совсем по количеству строк кода, скорее по повторному использованию.

Здравствуйте, Pzz, Вы писали:

Pzz>Мерилом чего является количество строк кода за единицу времени?

Мерилом того, к чему эту метрику захочет привязать тот, кто планирует metric system для конторы

Pzz>С таким же успехом можно измерять количество электроэнергии,
Pzz>потребленное компутером разработчика...

А что? Думаешь не измеряют? Вот в CMMI есть такая process area, SAM (Supplier Agreement Management), там как раз такими вещами занимаются.

Здравствуйте, RadioShark, Вы писали:

RS>Сколько строчек кода создает среднестатистический кодер C/C++ за год работая полную рабочую неделю?

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

Здравствуйте, Pzz, Вы писали:

Pzz>/***** Calculate total amount of I don't know what *****/
Pzz>double customerAmount = 0;
Pzz>for( int i = 0; i < orders.Length; i ++ )
Pzz>    customerAmount += orders[ i ].Amount;

Pzz>Комментарии говорят, что мы делаем. Код говорит, как мы это делаем.

А лучше так:

public double CalculateTotalAmountOf_I_dont_know_what(double[] orders)
{
    double customerAmount = 0;
    for( int i = 0; i < orders.Length; i ++ )
       customerAmount += orders[ i ].Amount;
    return customerAmount;

}

Здравствуйте, RadioShark, Вы писали:

RS>>Сколько строчек кода создает среднестатистический кодер C/C++ за год работая полную рабочую неделю?

В нашем небольшом концерне норма — 3000 строк оттестированного кода в год на разработчика.
Остальное — документация.

Здравствуйте, Igor Sukhov, Вы писали:

IS>при чем тут работа ? Мы разве не о ДЛИНЕ говорим ?
в своем первом посте вы сказали, что программист пишет в год 36.5 строчек кода, т.е. 0.1 в день, если год невисокосный. Но ведь не все же дни рабочие, имеются выходные, праздничные и т.д. Выходит, что в год не 36.5 строчек кода, а поменьше

Здравствуйте, Firstborn, Вы писали:

B>>Да я это высчитал из 27-30 LOC/day.
B>>Примерно такая средняя производительность мелькает в разных источниках
B>>и вроде у Боема (Barry Boehm) была именно такое число (могу ошибаться, так как не проверял).

F>Буду тупо настойчив... Всё же хотелось бы ссылку хоть на один источник, а?

Поищи по слову CoCoMo (и в частности CoCoMo calculator) как раз занимается рассчетом стоимости проекта из количества строк.

Здравствуйте, RadioShark, Вы писали:

RS>Сколько строчек кода создает среднестатистический кодер C/C++ за год работая полную рабочую неделю?

Фигасе?! Это что за зверь такой?

Здравствуйте, bkat, Вы писали:

B>Да я это высчитал из 27-30 LOC/day.
B>Примерно такая средняя производительность мелькает в разных источниках
B>и вроде у Боема (Barry Boehm) была именно такое число (могу ошибаться, так как не проверял).

Это сугубо индивидуальная метрика на самом деле. И кстати, довольно стабильная для отдельно взятого человека. То есть, применять некие "средние по больнице" показатели в контексте конкретной команды, а паче чаяния для конкретного разработчика, как минимум — не разумно.

Единственное, где могут помочь "средние по миру" показатели, так это в самооценке: мол, мы не хуже других.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Здравствуйте, bkat, Вы писали:

B>>Да я это высчитал из 27-30 LOC/day.
B>>Примерно такая средняя производительность мелькает в разных источниках
B>>и вроде у Боема (Barry Boehm) была именно такое число (могу ошибаться, так как не проверял).

ГВ>Это сугубо индивидуальная метрика на самом деле. И кстати, довольно стабильная для отдельно взятого человека. То есть, применять некие "средние по больнице" показатели в контексте конкретной команды, а паче чаяния для конкретного разработчика, как минимум — не разумно.

Тем не менее COCOMO исходит именно из этой метрики.

Здравствуйте, bkat, Вы писали:

ГВ>>Это сугубо индивидуальная метрика на самом деле. И кстати, довольно стабильная для отдельно взятого человека. То есть, применять некие "средние по больнице" показатели в контексте конкретной команды, а паче чаяния для конкретного разработчика, как минимум — не разумно.

B>Тем не менее COCOMO исходит именно из этой метрики.

И как из этого следует, что показатель LOC/день для конкретного человека можно копировать из среднебольничного?

Здравствуйте, Геннадий Васильев, Вы писали:

B>>Тем не менее COCOMO исходит именно из этой метрики.

ГВ>И как из этого следует, что показатель LOC/день для конкретного человека можно копировать из среднебольничного?

Я пожалуй просто отошлю к описанию COCOMO.
Оно доступно и с гуглом находится моментом.

Здравствуйте, bkat, Вы писали:

ГВ>>И как из этого следует, что показатель LOC/день для конкретного человека можно копировать из среднебольничного?

B>Я пожалуй просто отошлю к описанию COCOMO.
B>Оно доступно и с гуглом находится моментом.

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

Здравствуйте, Геннадий Васильев, Вы писали:

B>>Я пожалуй просто отошлю к описанию COCOMO.
B>>Оно доступно и с гуглом находится моментом.

ГВ>А что, там можно найти способы нарушения фундаментальных логических законов?

Каких законов? Тех что выведены Геннадием Васильевым?

Разговор в общем не очень конструктивен.
Если есть желание разобраться, а не только поехидничать,
то материал доступен. Если есть конкретные претензии к COCOMO,
то можно списаться с тем же Barry Boehm, к примеру.

Здравствуйте, bkat, Вы писали:

B>Если есть желание разобраться, а не только поехидничать,
B>то материал доступен. Если есть конкретные претензии к COCOMO,
B>то можно списаться с тем же Barry Boehm, к примеру.

COCOMO просто даёт некоторые методики для оценки ресурсоёмкости на основании эмпирически установленных коэффициентов. Наверное, в среднем по психб.., тьфу, промышленности это и работает. Я даже уверен, что это работает. Но post mortum, а не pre natal.

Попробую объяснить на пальцах.

Вот, к примеру, нужно написать программу ну, скажем, 1500 LOC, прогнозируемого объёма.

O'K, 1500, хотя уже здесь зарыт подвох — это может оказаться и 1800, и 980. Зависит от стабильности постановки задачи.

Теперь эти 1500 мы загоняем в какой-нить расчётный софт и получаем, ну... например... 9 месяцев. Но ошибаемся при этом, например, в том, что Application Experience на самом деле нужно поставить не 0.88, а 1.22. Вуаля! Вместо 9 получется 10 даже по простому расчёту. Ещё интереснее будет, если мы ошибёмся в Language & Tool Experience (LTEX).

Почему возникла ошибка? Потому что, например, значение коэффициента LTEX мы взяли опираясь на "среднебольничные" методики — например, посмотрев в резюме (сколько-сколько? 3 года! Супер — very high!). А на самом деле эти 3 года были э... тремя годами поверхностного знакомства. А кто ж скажет-то правду? Правда косвенно выясняется на этапе post mortum анализа — когда сроки уехали, бюджеты прощёлканы и руководство бушует.

Т.е., взяли цифры без учёта прецедентов (нету их ещё) — т.е., с потолка, и получили такой же отбалдовый результат.

Я понимаю, что в действительности всё существенно сложнее, но суть моего замечания от этого не меняется: нельзя брать и применять "среднепромышленные" показатели на конкретную команду без учёта особеностей последней. Мне льстит, что ты приписываешь мне авторство этого постулата. Спасибо.

---

Вообще, надо сказать, что оценка трудоёмкости разработки ПО — не то шарлатанство, не то чёрная магия. Да, формулы интересные и производят впечатление правдоподобных. Но вот методы определения численных коэффициентов для этих формул... это да, это песня.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Я понимаю, что в действительности всё существенно сложнее, но суть моего замечания от этого не меняется: нельзя брать и применять "среднепромышленные" показатели на конкретную команду без учёта особеностей последней.

С этим согласен.
Любую универсальную методику надо настраивать под конкретную команду.

Здравствуйте, bkat, Вы писали:

ГВ>>[...] нельзя брать и применять "среднепромышленные" показатели на конкретную команду без учёта особеностей последней.

B>С этим согласен.



B>Любую универсальную методику надо настраивать под конкретную команду.

Ну да. А в случае COCOMO индивидуальность показателя LOC/day маскируется использованием кучи не менее индивидуальных масштабных коэффициентов. Только и всего.

Здравствуйте, Firstborn, Вы писали:

Pzz>>Мерилом чего является количество строк кода за единицу времени?

F>Мерилом того, к чему эту метрику захочет привязать тот, кто планирует metric system для конторы

Теперь я понимаю почему индусский код копипэстами изобилует

Да кому интерестно сколько строк кода пишет программист. Важно не количество строк — а содержимое, а так же сколько денег принес тот или иной проект, в котором программист участвовал.

Здравствуйте, Тануки, Вы писали:

Т>Да кому интерестно сколько строк кода пишет программист. Важно не количество строк — а содержимое, а так же сколько денег принес тот или иной проект, в котором программист участвовал.

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

P.S. Все же стоит разобраться зачем меряют строчки кода.
Это не такая уж и глупая вещь, как может показаться на первый взгляд.

Здравствуйте, Firstborn, Вы писали:

F>Здравствуйте, bkat, Вы писали:

B>>6200 LOC/year

F>А откуда такая инфа, если не секрет?
F>По моим личным прикилкам выходит несколько другая цифра.

Если имеется в виду эффективных строчек, то все в порядке.

Здравствуйте, olen33, Вы писали:

O>А лучше так:

O>

O>public double CalculateTotalAmountOf_I_dont_know_what(double[] orders)
O>{
O>    double customerAmount = 0;
O>    for( int i = 0; i < orders.Length; i ++ )
O>       customerAmount += orders[ i ].Amount;
O>    return customerAmount;

O>}

O>

А ещё лучше так:

double customerAmount = std::accumulate(arr.begin(), arr.end(), 0.0);

Здравствуйте, What, Вы писали:

W>А ещё лучше так:
W>

W>double customerAmount = std::accumulate(arr.begin(), arr.end(), 0.0);
W>

Ну, тогда уж лучше так

let customerAmount = List.fold_left (+) 0 orders;;

Простите, не удержался.

B>P.S. Все же стоит разобраться зачем меряют строчки кода.
B>Это не такая уж и глупая вещь, как может показаться на первый взгляд.

Есть одна гипотеза, коллега Их — проще всего измерить.

Вот допустим сбацали вы с командой или в одиночку некий абстрактный (не не класс проект, и принес он вам, скажем, N баксов в год. Кто и как это проверит? Ну ситуация про увеличение производительности и снижение нагрузки на, допустим, каналы связи — то же хозяйство, вид сбоку. Не поймешь как заявленные параметры проверить.

А со строчками кода всё просто:
— Скока?
— тыща!
— маловато будет
— ну и хрен бы с вами

Здравствуйте, Programmierer AG, Вы писали:

PA>Ну, тогда уж лучше так
PA>

PA>let customerAmount = List.fold_left (+) 0 orders;;
PA>

PA>
PA>Простите, не удержался.

this expression has type 'float list' but is here used with type 'int list'

Тогда уж

let total_amount = Array.fold_left (+.) 0.

Здравствуйте, bkat, Вы писали:

B>P.S. Все же стоит разобраться зачем меряют строчки кода.

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

B>Это не такая уж и глупая вещь, как может показаться на первый взгляд.

Правильно, это ИДИОТСКАЯ ВЕЩЬ!

Здравствуйте, Геннадий Васильев, Вы писали:

B>>Это не такая уж и глупая вещь, как может показаться на первый взгляд.

ГВ>Правильно, это ИДИОТСКАЯ ВЕЩЬ!

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

А вот я, к сожалению, не пойму.

Зато, когда мне скажут, что система А — 100K строк, а система Б — 2M строк, и обе из одной области, то я, имея даже небольшой опыт, все равно смогу представить себе размеры и трудоемкость.

LOC — это единственный универсальный способ хоть как-то оценить объем системы. Причем способом, доступным даже неспециалистам.


Более того, судя по умным книгам, на самых разных больших проектах скорость написания кода обычно не различается в разы при одинаковом уровне требований к правильности и надежности, и уж тем более в рамках одной компании.
Т.е. для больших систем такая метрика как LOC вполне полезна даже для оценки будущих проектов. А более сложные метрики на основе LOC, например code churn, еще полезнее.


С каждым годом я еще больше убеждаюсь, что не бывают ничего идеально черного и идеально белого. И раз индустрия оперирует именно LOC как основным показателем, не могут же они быть все идиоты?

Здравствуйте, Xentrax, Вы писали:

ГВ>>Правильно, это ИДИОТСКАЯ ВЕЩЬ!

X>Ну как бы вам сказать, вот когда вам скажут, что система А — большая, а система Б — сильно больше, то это будет конечно сразу понятно, о чем идет речь, ведь любой опытный программист точно знает, что такое большая система, а что значит очень большая система.

X>А вот я, к сожалению, не пойму.

Я — тоже.

X>Зато, когда мне скажут, что система А — 100K строк, а система Б — 2M строк, и обе из одной области, то я, имея даже небольшой опыт, все равно смогу представить себе размеры и трудоемкость.

А я задамся вагоном разных вопросов. Одним из них будет — сколько же здесь копипаста?

X>LOC — это единственный универсальный способ хоть как-то оценить объем системы. Причем способом, доступным даже неспециалистам.

Это отменяет присущий ей идиотизм? Давай разговаривать на языке из "уа", "угу", "вава" — и нас поймут даже двухмесячные дети!

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

Это всё вторично. Можно очень быстро бежать по длинной дороге и очень медлено идти по короткой. В итоге второй вариант может получится шустрее.

X>Т.е. для больших систем такая метрика как LOC вполне полезна даже для оценки будущих проектов. А более сложные метрики на основе LOC, например code churn, еще полезнее.

Для будущих проектов эта метрика может существовать только как допущение. Для прошедших она имеет значение только в качестве весопридавателя хвастоства.

X>С каждым годом я еще больше убеждаюсь, что не бывают ничего идеально черного и идеально белого. И раз индустрия оперирует именно LOC как основным показателем, не могут же они быть все идиоты?

Ты не догадываешься, что вводя термин "индустрия" ты выпускаешь на волю монстра? С тезисом о многоцветности мира — не спорю.