А сколько в день вы пишет строчек (программы)?

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

Но все же они есть. Особенно они проявляются при применении функционального программирования.

 

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

 

и зачем оно вам..считать..

 

+1

 

Для увеличения количества строчек в день следует
1. широко использовать метод copy-paste, в частности: избегать выделения общего кода в функции, наследования классов, использования шаблонов (templates, patterns) и т. п.
2. по возможности не использовать библиотек - писать свои варианты библиотечных функций, особенно общеизвестных и элементарных.
3. использовать короткие (в идеале односимвольные) идентификаторы - иначе будет расти главным образом длина строк, а не их количество.

 

Просто циклы надо развёртывать и процедуры заменить макросами - для ускорения выполнения.
Предлагаю ещё померятся тем, у кого какое отношение размера исходников к размеру исполняемых файлов

 

золотые слова!

 

green
При использовании коротких (в идеале односимвольных) идентификаторов будет расти длинна комментариев, иначе уже через неделю не вспомнишь что у тебя написано. По второму пункту согласен полностью.
Vov4ick
Если следовать Вашему совету по развертке циклов (использование макроса repeat)и замене процедур на макросы - тогда размер исполняемых файлов окажется больше размера исходников

 

Vov4ick

вместо развёртки циклов предлагаю использовать MMX/SSE,
макросы - отличное решение для ассемблера.

 

написать заново. тем более, по второму разу будет легче.

еще. если есть конструкция типа case - никакой таблицы, только последовательное сравнение..
например перевод числа в аски конструкцеей
cmp al,0
je .null
cmp al,1
je .one
..
null:
mov al,30h
...

 

Mikl__

4. Ни в коем случае не нужно лезть в уже написанный код - это негативно отразится на производительности (строк/день).
Если существующая функция не работает в новом контексте, следует написать новый её вариант с соблюдением пп. 1- 3.

 

green
Если Вы вторично столкнулись с какой-то проблемой и при этом из нужной Вам функции не соорудили библиотеку, то разбираться, даже со своим кодом, в котором идентификаторы имеют вид func1234, func1235, абсолютно нет комментариев и т.д. извините, но это маструбация.
"Ни в коем случае не лезть в уже написанный код" а если Вы поняли почему у вас появляются ошибки, если вы нашли более удачный или подходящий алгоритм...
"Если существующая функция не работает в новом контексте", а откуда вы должны были догадаться об универсальном характере какой-то конкретной функции
"Для увеличения количества строчек в день" - странная у вас цель какая-то
Пусть будет лучше строк меньше, зато код стабильнее!

 

оно верно.

Кстати, а почему многие кодеры изменяют стандартные дефиниции?

Увидел как-то

#define GetClassObject GetObjectClass

Какая разница? - А такая фигня часто встречается.

 

Mikl__
это типа ирония в устах green'a.

 

да, это была попытка шутки

 

пишу не более 100 строчек в день, порою в день вообще не пишу, однако каму какое дело? что за странные соцопросы?

 

ну дык при приеме на работу иногда такое спрашивают

 

Вот вчера поразмышлял немножко и понял что ето уже совсем тупо сравнивать количество строк и даже во многих случаях - количество кода. Я уже десятки раз убеждался на своём опыте что чем меньше код, тем лучше он работает (и быстрее тоже).

И вообще надо оценивать более существенные параметры например сложность задачи которую обычно ставит ( и реализирует!!! ) перед собой програмист. Кто за ?

 

да и наступит коммунизм

 

10000 в день
но такая фигня получается! (С)

А если объективно - от 500 до 1500 за день
и еще 4 дня, чтобы выловить все баги

Потом день на внешние тесты
и еще 2 дня, чтобы выловить баги, которых я не нашел

Потом все по новой