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

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

Страницы: 19 10 11 12 13 14 Следующая »
#180
20:05, 1 мая 2012

igo
Не смешивать всё в кучу, а разбивать в древовидном виде.


#181
20:29, 1 мая 2012

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

#182
21:08, 1 мая 2012

igo
> или деревья щас изучаешь?.
канечна.. там осины, берёзы...

Я про то, что лучше разбивать решения на подрешения. Так понятнее ?    Если нет: например у тебя код на 100 000 строк. Разбивай его на подпроекты. Скажем будет 4 части, и каждая часть содержит 4 подчасти.  Каждая часть / подчасть отвечает за своё. То есть получится на каждой подчасти100000/(4*4)=6000 строк.

Намного легче :  ориентироваться/изменять/добавлять.

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


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

#183
22:49, 1 мая 2012

ksacvet777
> Я про то, что лучше разбивать решения на подрешения
я щас буду в стиле a la "Иров": ты че нам тут очевидность-то капитанишь?
еще скажи, что переменные надо называть не a, b, c, а fuck, my, mozg.

#184
12:23, 2 мая 2012

ksacvet777
функции, модули, объекты, библиотеки... короче - кирпичи)))...
боюсь ты не сможешь объяснить: при чем тут деревья?, которые по своей сути - иерархии... иерархии обычно выполняют управленческую роль, или предрасчитываются или строятся на лету для ускорения, рендера например...

----------------------------------

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

со стратегией - у мню у самого больше вопросов, чем ответов...

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

#185
13:11, 2 мая 2012

EvilSpirit
> я щас буду в стиле a la "Иров": ты че нам тут очевидность-то капитанишь?
> еще скажи, что переменные надо называть не a, b, c, а fuck, my, mozg.
  .. хз куда тебя понесло...  иаду выпей.

igo
> функции, модули, объекты, библиотеки... короче - кирпичи)))...
нуи    .. пошолты :)))


тогда тебе сюда:

+ Показать


Хотя наверняка это сцылко уже приводили.
, а эти памради.. памр..  тфу бл..ть !!  паарадигмы, во !  до тебя допрут только на практике. Удачи!

#186
13:33, 2 мая 2012

ksacvet777
а... ты типа - хамитель... в программеры - занесло, сочувствую...

как хамитель ты пока, правда, тоже - дальше транзистора одномерного не вымахал... попробуй второе измерение, метафоры, образы, аллегории...
#187
14:52, 2 мая 2012

igo
> сложность его начинает заметно ломать кайф от общения с ним...
работа - это "нередко" совсем не кайф.

#188
14:55, 2 мая 2012

igo
> хамитель
Изображение
да , балин, какой хомитель ???  я ж те помочь хачу

#189
15:33, 2 мая 2012

ksacvet777
тема - не вопрос, тема - обсуждение... см. самый первый пост: http://www.gamedev.ru/code/forum/?id=161540#m0
если банальное отсутствие вопроса в названии темы - не помогает помогателю)))...

#190
15:53, 10 мая 2012

ksacvet777
> Если нет: например у тебя код на 100 000 строк. Разбивай его на подпроекты.
> Скажем будет 4 части, и каждая часть содержит 4 подчасти. Каждая часть /
> подчасть отвечает за своё. То есть получится на каждой
> подчасти100000/(4*4)=6000 строк.
как нужно это делать хорошо описано в самой первой ссылке которой я давал, вот продублирую

http://www.rsdn.ru/article/testing/TestCriteria.xml

EvilSpirit
И действительно - капитанит, если бы расказал какие методологии нужно использовать что бы резать, а не просто

function main1_6000(){...}
function main6000_12000(){...}
function main12000_18000(){...}

#191
22:12, 12 мая 2012

bazhenovc
> kvakvs
> > Не пиши акцессор (get(), set()) там где можно обойтись простым мембером
> > (полем) класса.
> +1. Вот моё мнение по этому поводу :)

Не правильное мнение. Использование публичных членов нарушает инкапсуляцию.

bazhenovc
> Причём многие будут с пеной у рта доказывать, что ни в коем случае нельзя использовать просто public поле. И не могут толком обьяснить, почему.

Объясняю на примере:

// Пример 1.
class A
{
public:
    std::vector<int> m_Ids;
};
// Пример 2.
class A
{
private:
    std::vector<int> m_Ids;

public:
    const std::vector<int>& GetIds() const
    {
        return m_Ids;
    }
};
#192
23:39, 12 мая 2012

Dufrenite
> Не правильное мнение.
А если это класс вектора, тоже нельзя?

#193
1:18, 13 мая 2012

TauJIep
Хорошо, чем структура отличается от класса (в контексте цпп) ? У структуры не может быть методов?

#194
2:25, 13 мая 2012

Blew_zc
> А если это класс вектора, тоже нельзя?

А у класса вектора есть публичные поля? В чём вопрос то?

Страницы: 19 10 11 12 13 14 Следующая »
ПрограммированиеФорумОбщее

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