функции и процедуры

← →
Scot Storch (2010-06-16 18:50) [0]

функции и процедуры длиной 500-700 строк (без повторяющихся кусков кода) это нормально?

← →
Игорь Шевченко © (2010-06-16 18:52) [1]

Это омерзительно

← →
tesseract © (2010-06-16 18:58) [2]

Нормально, если дело идёт например о расчете производственных затрат через графы. Даже мало.

← →
Ega23 © (2010-06-16 19:14) [3]

Это ненормально. Хотя ситуации разные бывают. Но исключение только подтверждает правило.

← →
Правильный$Вася (2010-06-16 19:15) [4]

а в строке сколько операций?

← →
KilkennyCat © (2010-06-16 19:27) [5]

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

← →
_Юрий © (2010-06-16 19:28) [6]

Полагаю, что нормальный размер - один экран, если больше - надо думать над разделением на части

← →
Jeer © (2010-06-16 20:05) [7]

> это нормально?

Это диагноз.

Берете с десяток известных библиотек и напускаете на них Счетчик.
Вы увидите статистику.

P.S.
Математических приложений разных сфер деятельности мной создано немало, но все функции и процедуры ( в среднем ) укладывались в диапазон 50-150 значимых строк.

Все остальное - от лукавого.
ИМХО.

← →
DVM © (2010-06-16 20:13) [8]

Это неудобно, но вполне нормально. И уж ни в коем случае не омерзительно.
Стремиться все разбить на функции в 5-10 строчек как и все обернуть классами, суть которых класс ради класса - вот это ненормально, это паранойя.

Потом внутри функции на 500 строк вполне могут жить подфункции по 50 строк или меньше.

← →
MsGuns © (2010-06-16 20:17) [9]

В [1] все сказано

← →
Jeer © (2010-06-16 20:39) [10]

> Это неудобно, но вполне нормально.

Понимаю, что Вы хотели сказать, но, в данном случае, речь идет о процедурном программировании. ООП тут ни при чем.
Точно также, как и локальные функции/процедуры.

В старые времена был прием разворачивания цикла в линию ради ускорения счета ( устранение циклов и накладных расходов на них).
Сейчас тоже можно так, а нужно ли ?

Насчет "омерзительно" - это эмоции, не более.
Процедура из 700 строк говорит либо о неумении использования приема "разделяй и властвуй", либо о принципиальном желании сосредоточить весь функционал в одной процедуре.

Первое - лечится практикой, второе, к сожалению, не лечится - это особенность ( ограниченность связанности ) интеллектуальных возможностей программиста.

← →
AlexDan © (2010-06-16 20:47) [11]

> Scot Storch (16.06.10 18:50)
Да, видно уж очень надо было..

← →
Омлет © (2010-06-16 21:17) [12]

Это ригидность сознания или просто лень.

← →
DVM © (2010-06-16 21:25) [13]

У меня в одной программе есть функция на 600 строк. В принципе ее наверное можно разбить и я даже порывался как то это сделать и даже сделал (так что не лень и разбить я ее мог), но потом вернул как было. Она существует скорее как исключение, но тем не менее.

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

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

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

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

← →
Омлет © (2010-06-16 21:34) [14]

Хм. Сейчас посмотрел, самая длинная функция в текущем проекте - 1330 строк. Я же говорю - лень )))

← →
картман © (2010-06-16 21:44) [15]

> Удивительно, если разбить ее на части - от этого теряется
> ее читабельность,

хм...

> Омлет © (16.06.10 21:34) [14]
>
> Хм. Сейчас посмотрел, самая длинная функция в текущем проекте
> - 1330 строк. Я же говорю - лень )))

что же она такого делает?

← →
Омлет © (2010-06-16 22:09) [16]

> что же она такого делает?

Формирует большую и сложную конфигурацию для устройства..

← →
Демо © (2010-06-16 22:09) [17]

Процедура или функция в 200-500 строк - ничего особенного. Вполне среднее число.
Тем более, если используются структуры с большим количеством полей.
Например, у меня сейчас в рабочем проекте используется структура с количеством полей более 50. Каждое поле необходимо заполнить, обработка информации и преобразование занимает немалое количество строк.
Причём программа структурирована достаточно хорошо.

> функции и процедуры длиной 500-700 строк (без повторяющихся
> кусков кода) это нормально?

Абсолютно нормально, если это необходимо.

← →
Jeer © (2010-06-16 22:14) [18]

Проблема объективной оценки качества кода и ее освещение в работах Дейкстры и Иордана - известна. Это еще 60-е годы.

Сейчас же, инструментарий code metrics, встроен в некоторые системы программирования и можно вполне адекватно оценивать качество части ПО, хотя бы и в виде процедур.

Оценка ведется по показателям:
- индекс эксплуатационной надежности (Maintainability Index, MI
- циклическая сложность (Cyclomatic Complexity, CC)
( http://en.wikipedia.org/wiki/Cyclomatic_complexity )
- глубина наследования (Depth of Inheritance)
- сцепление классов (Class Coupling)
- число строк кода (в целом, а не в процедуре)

← →
Jeer © (2010-06-16 22:18) [19]

> Тем более, если используются структуры с большим количеством
> полей.

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

← →
В школу! (2010-06-16 22:26) [20]

> Процедура или функция в 200-500 строк - ничего особенного.
> Вполне среднее число.

Фортран уже давно не используется

← →
Демо © (2010-06-16 22:48) [21]

> В школу! (16.06.10 22:26) [20]
> > Процедура или функция в 200-500 строк - ничего особенного.
> > Вполне среднее число.Фортран уже давно не используется

Не перепутал форум?

← →
В школу! (2010-06-16 22:55) [22]

Демо © (16.06.10 22:48) [21]

Ну что ты, как можно! Где еще встретишь программистов, отстаивающих фортрановские принципы в объектно-ориентированных языках ?

← →
Jeer © (2010-06-16 22:58) [23]

> отстаивающих фортрановские принципы в объектно-ориентированных
> языках ?

Ну да, конечно - все тут такие объектные, аж штамп некуда поставить.

Вопрос возник о процедурах, а не о методах.

← →
Демо © (2010-06-16 23:10) [24]

> Где еще встретишь программистов, отстаивающих фортрановские
> принципы в объектно-ориентированных языках ?

А тут есть что отстаивать? Аксиомы не нужно отстаивать.
Догматизм ещё никому не смог помочь решать новые задачи и проблемы.

← →
В школу! (2010-06-16 23:16) [25]

Jeer © (16.06.10 22:58) [23]

Метод сильно отличается от процедуры ?

Демо © (16.06.10 23:10) [24]

> Догматизм ещё никому не смог помочь решать новые задачи
> и проблемы.

поэтому удивляет заявление в [17]

← →
Rouse_ © (2010-06-16 23:21) [26]

>
> Scot Storch (16.06.10 18:50)
>
> функции и процедуры длиной 500-700 строк (без повторяющихся
> кусков кода) это нормально?

Смотря в какой ситуации.
Я писал только на прологе функции инициализацию крипконтекста примерно в две тысячи строчек асм кода, а сама процедура вынесена несколькими инклудами в отдельные модули :)

← →
KilkennyCat © (2010-06-16 23:24) [27]

мне повезло - у меня не хватит терпения столько писать. поэтому у меня все коротко.

← →
Демо © (2010-06-16 23:29) [28]

> Демо © (16.06.10 23:10) [24] > Догматизм ещё никому не
> смог помочь решать новые задачи > и проблемы.поэтому удивляет
> заявление в [17]

И чем же удивляет? Тем, что отвергает догмы?

← →
Демо © (2010-06-16 23:31) [29]

> В школу! (16.06.10 22:55) [22]

Где написано и кем, что процедуры должны быть менее 500 (700, 1000 и т.д.) строк?

← →
Rouse_ © (2010-06-16 23:32) [30]

> KilkennyCat © (16.06.10 23:24) [27]
>
> мне повезло - у меня не хватит терпения столько писать

Ну когда ТЗ соответствующее выкатят еще и не столько нашуруешь :)

← →
В школу! (2010-06-16 23:35) [31]

Демо © (16.06.10 23:31) [29]

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

← →
Rouse_ © (2010-06-16 23:36) [32]

> В школу! (16.06.10 23:35) [31]

У меня маленькая просьба, ты не мог-бы изменить никнейм?

← →
Правильный$Вася (2010-06-16 23:43) [33]

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

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

← →
Демо © (2010-06-16 23:47) [34]

> В школу! (16.06.10 23:35) [31]
> Демо © (16.06.10 23:31) [29] Написано программистами для
> программистов.

Конкретнее - кто и где написал об этом?

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

Даже и не думал.

> есть код удобный в сопровождении и есть код неудобный.

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

> А дальше твой осознанный выбор.

Моё осознанный выбор - необходимость и достаточность.

← →
Rouse_ © (2010-06-16 23:52) [35]

> Демо © (16.06.10 23:47) [34]
> А с чего ты взял, что процедура в 500 строк неудобна для
> сопровождения?

Дим, ну что ты взьелся :) Процедура даже в две строки не удобна для сопровождения, будучи написана бездумно. Просто мало квалифицированных людей способных написать "нетленку в трех томах" из 500 и более строк, которую можно адекватно сопровождать.

← →
Rouse_ © (2010-06-16 23:56) [36]

Кстати, открою маленький секрет - достаточное количество NtАпи функций реализованы блобами в более чем 1000 строк. Ну это так... о птичках :)

← →
KilkennyCat © (2010-06-17 00:13) [37]

> Rouse_ © (16.06.10 23:56) [36]

я всегда знал, что там бездари работают! :)

← →
В школу! (2010-06-17 00:34) [38]

Rouse_ © (16.06.10 23:36) [32]

> У меня маленькая просьба, ты не мог-бы изменить никнейм?

Мне нравится

Демо © (16.06.10 23:47) [34]

> Конкретнее - кто и где написал об этом?

МакКоннелл

> А с чего ты взял, что процедура в 500 строк неудобна для
> сопровождения? Личные домыслы? Или это твои процедуры неудобны
> для сопровождения? Или неумение их писать? Или отсутствие
> необходимости реализации сложных линейных алгоритмов?

Это твои процедуры неудобны для сопровождения. Вряд ли ты за 7 лет научился их писать иначе.

← →
Демо © (2010-06-17 01:13) [39]

> В школу! (17.06.10 00:34) [38]

> МакКоннелл

Наверное умный мужик?
Думаешь он прав?
Слова его - догма?

> Это твои процедуры неудобны для сопровождения. Вряд ли ты
> за 7 лет научился их писать иначе.

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

Странная сентенция по поводу 7 лет.
К чему бы это?

← →
Сменил ник (2010-06-17 01:16) [40]

Демо © (17.06.10 01:13) [39]

> Меня-то как раз мои процедуры вполне устраивают.

Вот и славно

> Наверное умный мужик?

Не дурак. Почитай

> Странная сентенция по поводу 7 лет.
> К чему бы это?

А я видел твои творения

← →
Демо © (2010-06-17 01:35) [41]

> А я видел твои творения

Какие такие творения?

← →
Германн © (2010-06-17 01:38) [42]

> Это твои процедуры неудобны для сопровождения.

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

← →
Дмитрий Белькевич (2010-06-17 02:03) [43]

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

Согласен. Но с длинными методами тоже чего-то делать нужно. Поэтому поступаю по-другому: делаю несколько локальных процедур, называю их согласно тому, что они делают (вместо написания комментариев - так лучше) и вызываю внутри метода. Один раз. В результате классы не перегружены внутренними методами, код не перегружен длинными методами, вместо комментариев - вразумительные названия процедур.

← →
test © (2010-06-17 02:04) [44]

Сейчас про какой язык речь идет? Для SQL это в порядке вещей сплошь и рядом и ничего.

← →
Marser © (2010-06-17 02:08) [45]

> В школу! (16.06.10 23:16) [25]
>
> Jeer © (16.06.10 22:58) [23]
>
> Метод сильно отличается от процедуры ?

Бугага! Да всем он отличается от процедуры. Принадлежность к классу даёт ему доступ к остальной функциональности самого класса и его предков, не говоря уже о полях класса.
Если у человека в голове не опилки, если он умеет разбить крупную задачу на кванты подзадач, если он понимает значение и мощь трёх китов ООП (иногда выделяют разделение доступа как четвёртый), то он не пишет линейный процедурный код в классах, он создаёт гибкую расширяемую классовую иерархию (возможно, и с интерфейсами) и метод на 1000 строк у него не появится в принципе.

← →
Marser © (2010-06-17 02:10) [46]

> Rouse_ © (16.06.10 23:56) [36]
>
> Кстати, открою маленький секрет - достаточное количество
> NtАпи функций реализованы блобами в более чем 1000 строк.
> Ну это так... о птичках :)

Это если пишется один раз и навека. А если... Помилуй, Господи, нас, грешных...

← →
Думкин © (2010-06-17 05:52) [47]

> Но исключение только подтверждает правило.

Ежа и ты туда же. В такой постановке фраза сия глупость есть. Смысл в ней другой. И изначально также было. Но прижилось вот такое вот понимание. Как такое произносить то можно, тем более программисту? Не стыдно?

← →
Rouse_ © (2010-06-17 10:19) [48]

> Marser © (17.06.10 02:10) [46]
> Это если пишется один раз и навека

Ну судя по каментариям в этих функциям - переписывалось там все минимум несколько раз, так что ой :)

← →
Игорь Шевченко © (2010-06-17 10:51) [49]

Marser © (17.06.10 02:08) [45]

> Да всем он отличается от процедуры. Принадлежность к классу
> даёт ему доступ к остальной функциональности самого класса
> и его предков, не говоря уже о полях класса.

Не отличается...Вот такая фигня. Так что ты бугагу прикрой слегка, чтобы в луже не сидеть

← →
RWolf © (2010-06-17 11:02) [50]

> Игорь Шевченко © (17.06.10 10:51) [49]

Наследование и интерфейсы — всё же весьма значимое отличие, надо сказать.

← →
Игорь Шевченко © (2010-06-17 11:44) [51]

RWolf © (17.06.10 11:02) [50]

> Наследование и интерфейсы — всё же весьма значимое отличие,
> надо сказать.

В контексте размера в строках - офигительно значимое.

← →
Marser © (2010-06-17 11:59) [52]

> Игорь Шевченко © (17.06.10 10:51) [49]
>
> Marser © (17.06.10 02:08) [45]
>
>
> > Да всем он отличается от процедуры. Принадлежность к классу
> > даёт ему доступ к остальной функциональности самого класса
> > и его предков, не говоря уже о полях класса.
>
>
> Не отличается...Вот такая фигня. Так что ты бугагу прикрой
> слегка, чтобы в луже не сидеть

О, расскажите-ка мне о доступе к приватным полям и методам класса из не зависящей от него процедуры (RTTI и прочие рефлексии не предлагать)
Или сами бугагу прикройте, чтобы в луже не сидеть, или речи свои мудрые подфильтровуйте.

← →
Jeer © (2010-06-17 12:02) [53]

> офигительно значимое.
>

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

← →
Marser © (2010-06-17 12:02) [54]

> Игорь Шевченко © (17.06.10 11:44) [51]
>
> RWolf © (17.06.10 11:02) [50]
>
>
> > Наследование и интерфейсы — всё же весьма значимое отличие,
>
> > надо сказать.
>
>
> В контексте размера в строках - офигительно значимое.

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

← →
Ega23 © (2010-06-17 12:06) [55]

> О, расскажите-ка мне о доступе к приватным полям и методам
> класса из не зависящей от него процедуры

type TMyObj = class (TObject) private FBar: string; public procedure Foo; end; procedure TMyObj.Foo; begin ShowMessage(FBar); end; procedure MyProc; var obj: TMyObj; begin obj := TMyObject.Create; try obj.FBar := "Bar"; obj.Foo; finally obj.Free; end; end;

Ты эта... Аккуратнее... :)

← →
Jeer © (2010-06-17 12:11) [56]

А вообще я уже посоветовал выше провести стат.анализ над несколькими общеизвестными библиотеками - закономерности-то и проявятся :)

То, что какой-то конкретный гений "нарисует" процедуру на 5 тыщ строк - бог в помощь ему.

← →
Marser © (2010-06-17 12:15) [57]

> Ты эта... Аккуратнее... :)

Олег, я понимаю это как приглашение к флуду, но костыль внутри класса обратно не в счёт.
А ИШ мало того, что обгадил меня походя, так ещё и вызвал у меня разрыв шаблона... Вроде Гуру и Учитель (мой в т.ч.), а связи между правильным применением ООП и компактностью и читабельностью кода не видит...

← →
Правильный$Вася (2010-06-17 12:16) [58]

> Ты эта... Аккуратнее... :)

некошерный пример, скорее исключение

← →
Ega23 © (2010-06-17 12:18) [59]

> некошерный пример, скорее исключение

читай DB.pas, там этих "исключений" есть и много.

← →
Игорь Шевченко © (2010-06-17 12:25) [60]

Marser © (17.06.10 12:15) [57]

> О, расскажите-ка мне о доступе к приватным полям и методам
> класса из не зависящей от него процедуры

А скажи мне, на кой хрен процедуре доступаться к приватным полям ?

← →
Игорь Шевченко © (2010-06-17 12:25) [61]

Marser © (17.06.10 12:15) [57]

> А ИШ мало того, что обгадил меня походя

обтекай

← →
Jeer © (2010-06-17 12:27) [62]

Ну вот, сам предложил, сам и сделал ( это я о себе )

Анализ 5 модулей (cDataStruct, cFileUtils, cStreams, cStrings, cUtils) из немаленькой библиотеки Давида Батлера ( Delphi Fundamentals ) дает такие предельные числа строк кода (LOC), соответственно по модулям:39,80,73,124,59.
Это и процедуры и методы.
В основном же, число строк на P или PM значительно меньше.

P.S.
Анализ выполнен с помощью Peganza Pascal Analyzer v.4.6.0

← →
Jeer © (2010-06-17 12:33) [63]

Берем SynEdit.pas
Таки нашелся основной метод ExecuteCommand на 691 LOC :)
Это, скорее исключение, т.к. все остальные не превосходят 140 LOC

← →
Marser © (2010-06-17 12:37) [64]

>
> Игорь Шевченко © (17.06.10 12:25) [60]
>
> Marser © (17.06.10 12:15) [57]
>
>
> > О, расскажите-ка мне о доступе к приватным полям и методам
> > класса из не зависящей от него процедуры
>
>
> А скажи мне, на кой хрен процедуре доступаться к приватным
> полям ?

Хе :)
Вот вы и сами подошли к ответу :)
Неудобно из лука пулями стрелять, да? ;-)
Метод и процедура отличаются тем, что применяются в принципиально разных концепциях программирования.

> обтекай

Да пофик, на самом деле. Меня, было дело, в инете обкладывали так, как вы, арбатский интеллигент, просто не умеете ;-)

← →
Jeer © (2010-06-17 12:40) [65]

Берем исходник от DBISAM ( Elevate Software СУБД )
Наибольший LOC = 429 в методе RestructureTable
Остальные в диапазоне 10..200

← →
Игорь Шевченко © (2010-06-17 12:44) [66]

Marser © (17.06.10 12:37) [64]

> Метод и процедура отличаются тем, что применяются в принципиально
> разных концепциях программирования.

И как это связано с размером ? Никто (совсем никто) не мешает сделать много мелких процедур и немного крупных методов вне зависимости от используемых концепций. Кстати, ничего принципиального в разнице между процедурным подходом и ООП нету. И там и там алгоритм реализуется путем написания функций (методов) обращающихся к данным (полям).

Любую концепцию ООП можно реализовать процедурно (и наоборот).

← →
Jeer © (2010-06-17 12:46) [67]

Берем громадный модуль FastGeo и имеем LOC=92 для метода InterSectionPoint, все остальное значительно меньше.

Ну вот, собственно примерно и понятно, как обстоит дело с размерами P и PM.

← →
Ega23 © (2010-06-17 12:46) [68]

Драма зачот

← →
Думкин © (2010-06-17 12:52) [69]

> потому что в рамках ООП есть очевидные и удобные средства
> для разведения отдельных фрагментов функциональности на
> разные уровни абстракции.

Мне вот нужно решить систему линейных уравнений. Где будет принципиальное различие с выходом на длину процедур-методов при реализации?

← →
Jeer © (2010-06-17 12:56) [70]

Достаточно посмотреть на реализацию таких дел у вышеупомянутого Батлера.
У него объектный подход и число строк в PM ( не общее, а частное ) меньше, чем выполнить эту реализацию чисто на процедурном подходе.
Полагаю, что так.

← →
test © (2010-06-17 12:58) [71]

Есть процедуры(*методы, функции*) которые требуют определенного размера, например обработка очереди сообщений если обрабатывать все сообщения или приличную часть то в там один case может и на 700 вылезти и на тысячу, другая крайность когда все до одной двух операций разнесено по методам, функциям, процедурам тоже не сильно нормальный вариант. Может как то золотой середины держаться? Если нужна длинная функция то она пишется, размер сам по себе ни о чем не говорит.

← →
Думкин © (2010-06-17 12:59) [72]

> меньше, чем выполнить эту реализацию чисто на процедурном
> подходе.
> Полагаю, что так.

Почему? В чем разница, чтобы не уложиться в те же строки при процедурном подходе?

← →
Jeer © (2010-06-17 13:06) [73]

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

← →
Marser © (2010-06-17 13:09) [74]

>
>
> И как это связано с размером ? Никто (совсем никто) не мешает
> сделать много мелких процедур и немного крупных методов
> вне зависимости от используемых концепций. Кстати, ничего
> принципиального в разнице между процедурным подходом и ООП
> нету. И там и там алгоритм реализуется путем написания функций
> (методов) обращающихся к данным (полям).
>
> Любую концепцию ООП можно реализовать процедурно (и наоборот).
>
>

Слуга покорный. Читабельность линейного кода такого плана можно, конечно, повысить, с умом применив модульность, например, но всё равно это плосковато. Проверено на примере исходников и плагинов WireShark, писаных на ANSI C.

← →
Marser © (2010-06-17 13:10) [75]

> Думкин © (17.06.10 12:52) [69]
>
>
> > потому что в рамках ООП есть очевидные и удобные средства
> > для разведения отдельных фрагментов функциональности на
> > разные уровни абстракции.
>
> Мне вот нужно решить систему линейных уравнений. Где будет
> принципиальное различие с выходом на длину процедур-методов
> при реализации?

Речь кагбэ о задачах, требующих тысячу строк кода.

← →
Думкин © (2010-06-17 13:11) [76]

> Jeer © (17.06.10 13:06) [73]

Ну грубо так переход можно таким образом:

1. Данные класса в record.
2. Методы класса в процедуры с передачей дополнительно параметром "хозяина".

Какие процедуры при этом могут вырасти? Видимо, я чего-то упускаю.

← →
Думкин © (2010-06-17 13:12) [77]

> Речь кагбэ о задачах, требующих тысячу строк кода.

и че? Где та разница в реализации по строкам кода?

← →
Вариант (2010-06-17 13:16) [78]

> Думкин © (17.06.10 13:11) [76]

> 1. Данные класса в record.
> 2. Методы класса в процедуры с передачей дополнительно параметром
> "хозяина".

Это ООП в стиле ADA95, там именно так - "хозяин" передается явным параметром:-)

← →
Marser © (2010-06-17 13:28) [79]

> Думкин © (17.06.10 13:12) [77]
>
>
> > Речь кагбэ о задачах, требующих тысячу строк кода.
>
> и че? Где та разница в реализации по строкам кода?

Речь шла о сложных и объёмных задачах, это ты затронул тему отстрела зябликов из зенитных орудий.

← →
Думкин © (2010-06-17 13:32) [80]

> Marser © (17.06.10 13:28) [79]

Видимо, явсе-таки тупой. Но разница то где? Зяблики, незяблики, гомадрилы, вараны - разница то где в числе строк? Именно про то, что в сабже, а не про трудности сопровождения.

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

← →
Демо © (2010-06-17 13:36) [81]

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

Желание разбить неразделимую процедуру на мелкие подпрограммы - это такой же догматизм, как твёрдолобое отрицание использования GOTO.

← →
Игорь Шевченко © (2010-06-17 13:47) [82]

Marser © (17.06.10 13:09) [74]

Медитируй над словами: "Любую ООП-концепцию можно выразить процедурно без особенных усилий и без особого раздувания кода".

← →
Игорь Шевченко © (2010-06-17 13:48) [83]

Демо © (17.06.10 13:36) [81]

Ну ты ниспровегатель

← →
Демо © (2010-06-17 14:05) [84]

> Игорь Шевченко © (17.06.10 13:48) [83]
> Демо © (17.06.10 13:36) [81] Ну ты ниспровегатель

Да просто принцип такой - всегда думать при следовании советам, оценивать критически, и задавать себе вопросы:
1. Насколько код будет эффективен?
2. Насколько код будет прозрачен и читабелен?

А догматические ограничения - от лукавого.

← →
Kerk © (2010-06-17 14:12) [85]

> Демо © (17.06.10 14:05) [84]
> 2. Насколько код будет прозрачен и читабелен?

Это точно. Какой код более читабелен:
1) Простыня из 10 000 строк
2) Те же 10 000 строк, разбитые на процедуры с описательными именами и параметрами?

← →
Демо © (2010-06-17 14:13) [86]

> 2) Те же 10 000 строк, разбитые на процедуры с описательными
> именами и параметрами?

Я выше привёл пример необходимости такой портянки при необходимости case-ветвления.

← →
Kerk © (2010-06-17 14:14) [87]

> Демо © (17.06.10 14:13) [86]
>
> > 2) Те же 10 000 строк, разбитые на процедуры с описательными
> > именами и параметрами?
>
> Я выше привёл пример необходимости такой портянки при необходимости
> case-ветвления.

Говнокодерский какой-то пример. Кто ж делает 10 тыс ветвлений? Сопровождать ты это как будешь?

← →
BiN © (2010-06-17 14:18) [88]

> Демо © (17.06.10 14:13) [86]
>Я выше привёл пример необходимости
> такой портянки при необходимости case-ветвления.

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

не проще ли и не изящнее ли трансформировать такого монстра в итерацию?

← →
Демо © (2010-06-17 14:18) [89]

> Говнокодерский какой-то пример. Кто ж делает 10 тыс ветвлений?
> Сопровождать ты это как будешь?

Почему 10000?
достаточно 300. В каждом ветвлении по 30 строк кода. Вот уже и 10000 строк в процедуре.

← →
Демо © (2010-06-17 14:20) [90]

> > Демо © (17.06.10 14:13) [86]>Я выше привёл пример необходимости
> > такой портянки при необходимости case-ветвления.раздутие
> кода чаще всего - и в твоем примере, в частности - имеет
> место при нарушении одного из старинных правил - разделяй
> код и данные.не проще ли и не изящнее ли трансформировать
> такого монстра в итерацию?

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

"Итерация" - имеется ввиду Delphi выше v7?

Я, например в D6 пишу.

← →
Игорь Шевченко © (2010-06-17 14:25) [91]

Демо © (17.06.10 14:05) [84]

Ну ниспровергай дальше

← →
Alx2 © (2010-06-17 14:27) [92]

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

← →
BiN © (2010-06-17 14:29) [93]

> Демо © (17.06.10 14:20) [90]
> "Итерация" - имеется
> ввиду Delphi выше v7?Я, например в D6 пишу.

да хоть турбопаскаль.

имелось в виду Alx2 © (17.06.10 14:27) [92]
или подключаемые библиотеки

← →
RWolf © (2010-06-17 14:36) [94]

> Alx2 © (17.06.10 14:27) [92]
> В случае протокола, решаемом кабанским case, я бы завел
> ассоциативный массив методов - всяк метод для своего варианта.
> Вызов через ассоциацию. Имхо, обозримей и сопровождабельней.
>

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

← →
Демо © (2010-06-17 14:43) [95]

> Игорь Шевченко © (17.06.10 14:25) [91]
> Демо © (17.06.10 14:05) [84] Ну ниспровергай дальше

А зачем ниспровергать? Я просто высказываю своё мнение. Каждый ведь сам за себя решает.

> RWolf © (17.06.10 14:36) [94]
> > Alx2 © (17.06.10 14:27) [92]> В случае протокола, решаемом
> кабанским case, я бы завел > ассоциативный массив методов
> - всяк метод для своего варианта.> Вызов через ассоциацию.
> Имхо, обозримей и сопровождабельней.> Я бы даже предложил
> все варианты сделать классами, производными от абстрактного
> ответа SMS-центра (или кто там поставляет данные) с переопределёнными
> методами обработки, а вместо case оставить фабрику классов.
> Таким образом, разделяем и данные, и код их обработки (и
> то, и другое заведомо различается для разных ответов).

А разве в этом случае код будет более понятен и прост?

← →
Демо © (2010-06-17 14:45) [96]

> Alx2 © (17.06.10 14:27) [92]
> В случае протокола, решаемом кабанским case, я бы завел
> ассоциативный массив методов - всяк метод для своего варианта.
> Вызов через ассоциацию. Имхо, обозримей и сопровождабельней.
>

Вопрос спорный на самом деле.

Что будет проще сопровождать - линейную процедуру или несколько сотен методов.

← →
Kerk © (2010-06-17 14:46) [97]

> Демо © (17.06.10 14:43) [95]
> А разве в этом случае код будет более понятен и прост?

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

← →
Alx2 © (2010-06-17 14:52) [98]

>Демо © (17.06.10 14:45) [96]

>Что будет проще сопровождать - линейную процедуру или несколько сотен методов.

Тут у меня отсыл к авторитетам промышленного программинга. Тот же Макконнелл, Буч и прочая компания. Паттерн, приведенный RWolf [92], родился не от "чтобы этакого написать, чего еще не было?".

← →
Игорь Шевченко © (2010-06-17 14:52) [99]

Alx2 © (17.06.10 14:27) [92]

> В случае протокола, решаемом кабанским case, я бы завел
> ассоциативный массив методов - всяк метод для своего варианта

Поздравляю с изобретением полиморфизма :)

← →
Alx2 © (2010-06-17 14:53) [100]

>Игорь Шевченко © (17.06.10 14:52) [99]

Спасибо :)

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

← →
Демо © (2010-06-17 14:59) [101]

> Alx2 © (17.06.10 14:53) [100]
> >Игорь Шевченко © (17.06.10 14:52) [99]Спасибо :)В кач-
> ве отмазки: речь больше именно об участке, где принимается
> решение "куды бечь".

А как насчёт заполнения кучи параметров для каждого метода?

← →
Демо © (2010-06-17 15:00) [102]

> Kerk © (17.06.10 14:46) [97]
> > Демо © (17.06.10 14:43) [95]> А разве в этом случае
> код будет более понятен и прост?Конечно.И еще не забудь,
> что с пачкой классов может одновременно работать несколько
> человек, а с твоей гигантской процедурой - только ты один.
>

Не надо плодить сущности сверх необходимого.

← →
Alx2 © (2010-06-17 15:02) [103]

>Демо © (17.06.10 14:59) [101]

Куча параметров в методе тоже плохо :) Как вариант - классы-контейнеры в кач-ве параметров.

← →
Игорь Шевченко © (2010-06-17 15:04) [104]

Демо © (17.06.10 15:00) [102]

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

← →
Демо © (2010-06-17 15:06) [105]

> Игорь Шевченко © (17.06.10 15:04) [104]
> Демо © (17.06.10 15:00) [102] Ты путаешь наколенные разработки
> и работу в команде. В наколенных допустимо абсолютно все,
> в команде (обычно) существует набор ограничений для повышения
> совокупной производительности команды в течение жизненного
> цикла приложения.

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

← →
test © (2010-06-17 15:12) [106]

Демо © (17.06.10 15:00) [102]
Бритву Акаму таки опровергли для части случаев.

> Для команды должны быть определены общие требования.

И не членами команды :)

> А как насчёт заполнения кучи параметров для каждого метода?

ТАбстрактныйОбработчик=class private общие поля protected proc Parse(данные);virtual;abstract; //разобрать данные, заполнить поля public constr Create(данные); end; ТОбработчикПакета1=class(ТАбстрактныйОбработчик) private специфичные поля protected proc Parse(данные);override; public constr Create(данные); end; ТОбработчикПакета2=class(ТАбстрактныйОбработчик) ... constr ТАбстрактныйОбработчик.Create(данные); begin Parse(данные); end; proc РазобратьПакет(пакет); var обработчик:TАбстрактныйОбработчик; begin тип:=ВытащитьТипПакета(пакет); данные:=ВытащитьДанные(пакет); case тип of тип1: обработчик:=ТОбработчикПакета1.Create(данные); тип2: обработчик:=ТОбработчикПакета2.Create(данные); ... тип300: обработчик:=ТОбработчикПакета300.Create(данные);

> RWolf © (17.06.10 15:20) [108]

Почему нельзя засунуть тип обработчика в массив из TОбработчикПакетаClass и оттуда доставать по индексу типа? Строк станет в 150 раз меньше.

Ну вот, нашел метод на 4380 строк, правка комментарий перед методов занимает 3724. Так что остается 656 строк + комментарии внутри... Но это все не выглядит очень уж страшным и нечитаемым:
http://mu.webest.net/prog/crafty/main.php

> Фортран уже давно не используется
Еще как используется. Там численные алгоритмы давно и качественно вылизаны

>Mystic © (17.06.10 15:40) [110]

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

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

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

> Поздравляю с изобретением полиморфизма :)

Ровно так, кейсы метня иногда бесят.

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

А это как раз к теме ближе. А не "увидит ли процедура приватные данные".

> Alx2 © (17.06.10 15:02) [103]
> >Демо © (17.06.10 14:59) [101]
>
> Куча параметров в методе тоже плохо :) Как вариант - классы-
> контейнеры в кач-ве параметров.

Приходим к понятию ссылка.

> Mystic © (17.06.10 15:53) [114]
> Но выдираются большей частью идеи :)

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

> test © (17.06.10 15:12) [106]
> Демо © (17.06.10 15:00) [102]
> Бритву Акаму таки опровергли для части случаев.

Тут решает конкретика. А не факт ОПРВЕРЖЕНИЯ. nfrbt ltkf/

>Думкин © (17.06.10 16:36) [116]

>Приходим к понятию ссылка.

Оно вроде слишком низкоуровневое, чтобы таким путем к нему идти :)

>Думкин © (17.06.10 16:36) [116]

>А не "увидит ли процедура приватные данные".

Объекты тогда. Вообще, беспредметно пока получается. Теоретическая всеобъемлющая общность, сводящаяся после усушки над задачкой к конкретной реализации.

Думкин © (17.06.10 16:43) [118]
Спор то теоретический, код самой функции в 700 строк автор не привел, только пожаловался.

Обсуждение на Потрепаловке:

Автор ветки (пост №1)
Я посрал в лесу, потом вытерся лопухом.

Бывалый (пост №2)
Надо было не лениться взять лопату и закопать.

Несогласный (пост №3)
Гадить в местах общественного пользования аморально!

...

Несогласный 15 (пост №32)
Требования зеленых не просто так, а вдруг медведь наступит!

Оппонент 7 (пост №33)
Вот медведю точно до одного места, он сам так поступает.

...

Бывалый 4 (пост №56)
Ты ГОСТ к верх ногами держишь? Сказано же, хозяйственная постройка должна выступать
в качестве укрытия в случае внезапного артелерийского обстрела. Так что никакого
кафеля, только армированный бетон и стальные балки.

Оппонент 10 (пост №57)
Речь идет про сугубо гражданский объект.

← →
0x00FF00 (2010-06-17 18:36) [123]

> код самой функции в 700 строк автор не привел

А может быть, оно и слава богу?..

> Обсуждение на Потрепаловке:

+1 =)

> Mystic © (17.06.10 15:40) [110]
>
> Ну вот, нашел метод на 4380 строк, правка комментарий перед
> методов занимает 3724.

Черд, а я то думал что мои метровые описалова в начале юнита со схемой работы оного сликом обьемны...
ЗЫ: Зотыч - ты был прав :)

> Alx2 © (17.06.10 17:02) [120]
> >Думкин © (17.06.10 16:36) [116]
>
> >А не "увидит ли процедура приватные данные".
>
> Объекты тогда. Вообще, беспредметно пока получается.

Это давно понятно. Битва с моей стороны и шла за уточнение. Но как и все форумное - беспощадно и бесмысленно. Как итог.

-----------

Так как там с функциями и процедурами то!!? :) На 900 строк. И как их сводят к 5 лаконичным строкам методы ООП.

И тишина. :) Все-таки если есть алоритм, то его либо пишут, либо нет. Вот и все. А то абстактности инкапсулированные в голоморфность полимофизма над паттернами обобщенности. А король то голый.

> Думкин © (17.06.10 19:23) [125]

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

> ООП поощряет

Поощряет не в том смысле, что «как Буч в умной книжке написал — так и делай»,
а в том, что «хм, а ведь удобно получается, понятно и красиво, и без костылей, и раскидать работу на несколько человек легко».

> RWolf © (17.06.10 20:15) [126]
>
>
> > Думкин © (17.06.10 19:23) [125]
>
> Вообще говоря, речь шла о том, что ООП поощряет использовать
> короткие методы вместо длинных процедур, а не об общем сокращении
> объёма кода.

+1

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

RWolf © (17.06.10 20:23) [127]

При хорошей модульности и без ООП можно писать мелкими процедурами и распределяя работу на несколько человек.

Еще раз повторю - почти все концепции ООП можно реализовать процедурно (почти - это, например, разная видимость данных). В ООП-языке они более изящно выглядят, но серебряных пуль там нету.

> RWolf © (17.06.10 20:15) [126]
>
>
> > Думкин © (17.06.10 19:23) [125]
>
> Вообще говоря, речь шла о том, что ООП поощряет использовать
> короткие методы вместо длинных процедур,

Вот именно. Почему же это так, так показано и не было.

>Думкин © (18.06.10 05:26) [130]

>Вот именно. Почему же это так, так показано и не было.

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

> DVM © (16.06.10 21:25) [13]
> Разбивать ее (например по тем же шагам)
> - это означает делать методы класса, нужды в которых абсолютно
> нет. Никто не будет их вызывать сами по себе (это бессмысленно),
> более того их надо будет вызывать в определенной последовательности,
> что тоже не есть гут, все локальные переменные большой
> функции придется сделать либо полями класса, либо передавать
> в эти методы через параметры (которых будет слишком много),
> что в целом только запутывает того, кто будет читать код.

В паскале есть локальные функции.

> Alx2 © (18.06.10 09:18) [131]
> Дает возможность иерархического "естественного" упорядочивания,
> делает ближе к "естественному" восприятию.

С чего это вдруг иерархическое упорядочивание - естественное?

>euru © (18.06.10 13:47) [133]

А с чего неестественное-то? :) Естественно все воспринимать на уровне детализации микробов?

← →
Суслик__ (2010-06-18 14:00) [135]

2автор
от ситуации зависит.
у меня есть такие - не стыжусь.

Суслик__ (18.06.10 14:00) [135]

> у меня есть такие - не стыжусь.

У тебя и больше есть, для тестирования компилятора

> Alx2 © (18.06.10 13:58) [134]
> А с чего неестественное-то? :)

Потому что вводится разработчиком, а не следует из поставленной задачи.

>euru © (18.06.10 14:50) [137]

Но ведь как раз после анализа предметной области определяется. Т.е. следует из поставленной задачи. Может, я просто недопонял замечания?

> Но ведь как раз после анализа предметной области определяется.

Не все начинают с этого - кому-то дается задание на кодирование и о предметной он ни в зуб ногой.
Считать ли его программистом и считать ли его мнение значимым ?
А таких тут немало. Это не плохо, это просто иной, нижележащий уровень.
Gastarbeiter :)

> Alx2 © (18.06.10 14:53) [138]
> Но ведь как раз после анализа предметной области определяется.

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

>euru © (18.06.10 15:46) [140]

Понял. Даже не знаю что ответить. Вот, например, естественный корм дает кошке возможность не сдохнуть с голоду. Подобно тебе я задаю вопрос: "с чего я взял, что корм - естественный? Что если кошек в некотором месте нет вообще?"

На нет - суда нет :)

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

Буквоед ?

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

>euru © (18.06.10 15:46) [140]

То есть я вот к чему:
Конечно, не каждое конкретное "иерархическое упорядочивание" имеет свойство "быть естественным". Но если таковое есть, то его можно заюзать в ООП. Т.е. ООП дает возможность естественного иерархического упорядочивания, о чем я писал в [130].
Но полное отсуствие возможности "иерархического упорядочивания" (для какой-то задачи) автоматом снимает вопрос и о его свойствах. Вот, получилась еще одна банальность.

>Jeer © (18.06.10 15:55) [142]

Кажется, просто идет фикс ощущения, типа: "тут что-то не так - сейчас найду что именно". :)

"ОО-языки упрощают абстракцию, возможно, даже слишком ее упрощают. Они поддерживают
создание структур с большим количеством связующего кода и сложными уровнями.
Это может оказаться полезным в случае, если предметная область является
действительно сложной и требует множества абстракций, и вместе с тем такой
подход может обернуться неприятностями, если программисты реализуют простые
вещи сложными способами, просто потому что им известны эти способы и они умеют
ими пользоваться.
Все ОО-языки несколько сколнны "втягивать" программистов в ловушку избыточной
иерархии. Чрезмерное количество уровней разрушает прозрачность: крайне
затрудняется их просмотр и анализ ментальной модели, которую по существу
реализует код. Всецело нарушаются правила простоты, ясности и прозрачности,
а в результате код наполняется скрытыми ошибкми и создает постоянные проблемы
при сопровождении.
Данная тенденция, вероятно, усугубляется тем, что множество курсов по
программированию преподают громоздкую иерархию как способ удовлетворения
правила представления. С этой точки зрения множество классов приравнивается
к внедрению знаний в данные. Проблема данного подхода заключается в том, что
слишком часто "развитые данные" в связующих уровнях фактически не относятся
у какому-либо естественному объекту в области действия программы -
они предназначены только для связующего уровня.
Одной из причин того, что ОО-языки преуспели в большинстве характерных для них
предметных областей (GUI-интерфейсы, моделирование, графические средства),
возможно, является то, что в этих областях относительно трудно неправильно
определить онтологию типов. Например, в GUI-интерфейсах и графических средствах
присутствует довольно естественное соотвествие между манипулируемыми
визуальными объектами и классами. Если выясняется, что создается большое
количество классов, которые не имеют очевидного соответствия с тем, что
происходит на экране, то, соотвественно, легко заметить, что связующий уровень
стал слишком большим."

к слову пришлось

> Игорь Шевченко © (18.06.10 17:08) [145]

К слову покапайтесь в коде например УПП от 1С. Враз полюбите ООП. Там есть пространство имён, там есть изоляция. Но когда видишь 30-40 идентификаторов в 100 знаков начинается легкий шок. ООП это меньшее зло.

OS/360 без ООП написана.
И никакого зла, только радость :)

Если б у нас столько программеров в кучу собрали было б еще радостнее :)

Наверно, их проблема как раз в том, что с этим у них не было проблем ))

"Проблемы начинаются с мелочей" (С)

функции и процедуры Найти похожие ветки