Войти
ПрограммированиеФорумОбщее

Парадигмы эффективно снижающие сложность кода... (4 стр)

Страницы: 13 4 5 614 Следующая »
#45
14:45, 25 апр. 2012

TarasB
> Ещё от меня: при отладке программы выключай оптимизацию и включай все проверки,
> доступные в компиляторе и библиотеке!
И ... подключи монитор к питанию!


#46
14:54, 25 апр. 2012

IROV..
> И ... подключи монитор к питанию!

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

#47
15:16, 25 апр. 2012

laMer007
> Также в каких-то случаях RVO\NRVO из-за const слышал не срабатывало.
из-за const оно чаще применяется, ибо чтоб сделать переменную const часто нужно переделать немного код, и соответственно подстроить его под (N)RVO

#48
15:16, 25 апр. 2012

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

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

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

#49
15:19, 25 апр. 2012

igo
для этого нужно применять TDD, которое не везде применимо. как проверять что что-то отрендерилось без ошибок? как проверить что бот сделал все что от него нужно и вел себя естественно? кое что может оценить только человек взглянув глазом.
а так да TDD рулит, жаль что не все это понимают

#50
15:28, 25 апр. 2012

Pushkoff
> а так да TDD рулит, жаль что не все это понимают

Что такое TDD?

#51
15:38, 25 апр. 2012

TarasB
> Что такое TDD?
Test drive development

#52
16:12, 25 апр. 2012

TDD это теже самые ассерты, только доведенные до монструозных масштабов. Я бы не стал использовать TDD в маленьких командах.

Кстати еще одно правило которое я выстрадал:
"делать по возможности функции, которые сами выполняют всю задачу, а не разбивать на сотню подзадач" - это тоже ускоряет разработку и уменьшает количество связанных однотипных функций и вообще общее количество функций. Разбивать на подзадачи можно уже потом, когда проект будет готов, или только если по другому никак.

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

#53
16:19, 25 апр. 2012

newbprofi2
> делать по возможности функции, которые сами выполняют всю задачу, а не
> разбивать на сотню подзадач
че за бред?
про читаемость кода слышал?

newbprofi2
> Я бы не стал использовать TDD в маленьких командах
а я бы стал, ибо можно попросту не допустить баги
ибо на написание тестов тратится вполне предсказуемое время, а на отлов багов время непредсказуемо, и чем старше баг тем он более непредсказуем

#54
16:31, 25 апр. 2012

Мне всегда было достаточно ассертов.

Да слышал я про читаемость, но также слышал про скорость разработки.

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

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

#55
16:33, 25 апр. 2012

посоветуйте хорощие книжки или статьи по написанию тестов)

#56
16:52, 25 апр. 2012

newbprofi2
> Да слышал я про читаемость, но также слышал про скорость разработки.
говорят что эти параметры сильно связаны

newbprofi2
> Разбить можно и потом когда проект будет готов.
зачем? сразу это будет в разы проще чем уделять этому время потом с непонятной целью

#57
17:27, 25 апр. 2012

Pushkoff
Я выделяю код в функцию только если код встречается где то 2 раза, ну и разумеется если функция должна принадлежать классу. В остальных случаях не трачу время. Лично на мой взгляд читаемость и понимаемость всей программы только увеличивается если функций меньше.

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

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

#58
17:43, 25 апр. 2012

Pushkoff
> > > Также в каких-то случаях RVO\NRVO из-за const слышал не срабатывало.
> > из-за const оно чаще применяется, ибо чтоб сделать переменную const часто нужно
> переделать немного код, и соответственно подстроить его под (N)RVO
Я не читал, но судя по всему по ссылке ниже демонстрировали именно не сработавший (N)RVO:
PVSector
> > > > http://tfpsly.free.fr/english/3d/code.html#Vector and matrix classes, math operators

#59
17:48, 25 апр. 2012

TarasB
> Тебе смешно, а я часто вижу тему "памагите где ашипка", которые сразу же
> решаются, стоит только включить в компиляторе проверки и пересобрать программу.
Я думал что это тема не для нубов, аля - "как запустить студию?", "почему не принтит Hello!"

Страницы: 13 4 5 614 Следующая »
ПрограммированиеФорумОбщее

Тема в архиве.