Неужели и вправду код функции должен поместится в экран?

← →
Miwa © (2004-03-16 11:17) [0]

Ну уж действительно "Общий вопросс" :о))
Дело в том, что "самообразовываясь самостоятельно", я раньше вообще не задумывался о такой, как я убедился, ВАЖНЕЙШЕЙ вещи, как проектирование программы. А тут пришлось - перед тем, как переписывать проект третий раз :о((.
Но дело сейчас в другом.
Пишу функцию для анализа текстовых данных и сохранения результатов оного в базу. В функции фигурирует десяток списков которые в процессе работы могут занимать мегабайт и более. Поэтому не хочется (как рекомендуют авторы статей) разбивать данную функцию (строчек 300-400 кода) на составляющие. Разве что передавать им адреса списков параметрами... Но есть ли смысл?

← →
MU (2004-03-16 11:27) [1]

можно экран побольше поставить или шрифт поменьше сделать

← →
TUser © (2004-03-16 11:29) [2]

300-400 строчек кода - это много. Я стараюсь писать прогу, чтобы в каждой процедуре бало строчек 20-50. Если больше, да еще там куча вложенных циклов и условий - это плохо читается. Но каюсь - еще не одной приги не написал без хотя бы одной большой проц-ры. Сначала все они маленькие, а потом вырастают строчек до 200-300-400- и т.д. Но так лучше не делать.

← →
Anatoly Podgoretsky © (2004-03-16 11:31) [3]

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

← →
Романов Р.В. © (2004-03-16 11:35) [4]

> Anatoly Podgoretsky

Неправда, ее можно переписать так что она поместится на экран даже при самом маленьком разрешении.

← →
Jack128 © (2004-03-16 11:46) [5]

зависит от стиля. если писать так
var i,j,k: integer;
begin
if i < 10 then begin
...
end else if j > 20 then begin
...
end else if k < 30 then begin
...
end;
end; то может и можно уместить на один экран, я придпочитаю такой стиль

var
i: integer;
j: integer;
k: integer;
begin
if i < 10 then
begin
...
end
else
if j > 20 then
begin
...
end
else
if k < 30 then begin
...
end;
end;
Сам понимаешь, это не способствует уменьшению размеров функций

← →
Игорь Шевченко © (2004-03-16 11:46) [6]

Anatoly Podgoretsky © (16.03.04 11:31)
Романов Р.В. © (16.03.04 11:35)

Марксизм не догма, а руководство к действию.

← →
Плохиш (2004-03-16 11:49) [7]

>Jack128 © (16.03.04 11:46) [5]

Компилятору глубоко на<bip> (пардон, плевать) на ваш стиль, пока текст не содержит ошибок ;-)

← →
miwa © (2004-03-16 11:49) [8]

> Романов Р.В. © (16.03.04 11:35) [4]
И что Вы посоветуете в приведенном случае? Например для 15"" монитора и разрешения 800 х 600? ;о))

← →
Плохиш (2004-03-16 11:52) [9]

> miwa © (16.03.04 11:49) [8]
> И что Вы посоветуете в приведенном случае? Например для
> 15"" монитора и разрешения 800 х 600? ;о))

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

← →
miwa © (2004-03-16 11:54) [10]

А текст, между прочем, такой как не понравился
>Jack128 © (16.03.04 11:46) [5].

>Плохиш (16.03.04 11:49) [7]
Компилятору пофиг. А вам через полгода?

← →
miwa © (2004-03-16 11:59) [11]

Плохиш (16.03.04 11:52) [9]
> А в чём проблема? Или скролингом пользоваться не умеете?

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

← →
Плохиш (2004-03-16 12:06) [12]

>miwa © (16.03.04 11:59) [11]

Изачальный вопрос вообще из серии "Что лучще вындовс или лыникс"
Но мы ешё не в "потрепаться"

← →
Романов Р.В. © (2004-03-16 12:08) [13]

> miwa © (16.03.04 11:49) [8]
> > Романов Р.В. © (16.03.04 11:35) [4]
> И что Вы посоветуете в приведенном случае? Например для
> 15"" монитора и разрешения 800 х 600? ;о))

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

← →
Романов Р.В. © (2004-03-16 12:12) [14]

В основном во вложенные функции уходять сложные конструкции проверки условий или обработка во вложенных циклах.

← →
Goida © (2004-03-16 12:13) [15]

Почему до сих пор не в ПОТРЕПАТЬСЯ???!!!

И еще, в обработчиках событый я стараюсь не писать код не связанный с данным контролом, а выностить его в отдельные процедуры и фунции.
Например:
procedure TfrmMain.acOpenBaseExecute(Sender: TObject); begin if odBase.Execute then OpenBase(odBase.FileName); end; // Установка соединения с базой procedure TfrmMain.OpenBase(FName: TFileName); const _CS1 = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source="; _CS2 = ";Persist Security Info=False"; begin if FileExists(FName) then begin dmBase.cnBase.ConnectionString := _CS1 + FName + _CS2; dmBase.cnBase.Connected := True; if not dmBase.cnBase.Connected then ShowMessage("Не удалось подключиться к базе") else SetLastFile(FName); end else ShowMessage("Файл не найден"); end;

> Miwa

См. [6]. А от себя добавлю - код функции должен умещаться в ГОЛОВЕ, а не на экране. Никакие экраны и разрешения здесь вообще ни при чем.

Короче, функция должна представлять из себя ЛОГИЧЕСКИ автономную часть алгоритма, которая по общей логике программы выполняется НЕОДНОКРАТНО. И сколько в ней при этом строк, 20 или 200 - неважно. Разбивать ее на какие-то ОДНАЖДЫ вызываемые куски ТОЛЬКО ради сокращения числа строк совершенно незачем (то же самое можно получить, отделив эти куски пустыми строками или комментариями). Более того, даже если какой-то кусок кода выполняется и несколько раз, но всегда внутри ОДНОЙ функции, то не надо выносить его из этой функции, а надо сделать ее ВНУТРЕННЕЙ функцией. И все будет понятно, и все будет структурно.

И если следовать эти РАЗУМНЫМ, а не ФОРМАЛЬНЫМ правилам, то объем подавляющего большинства функций (а также средний объем функции) как раз и получается примерно таким, который называется "хороший стиль".

← →
Algol (2004-03-16 13:13) [19]

Из личного опыта:

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

Всё, что здесь написано имеет смысл соблюдать. Это точно. Но главное, как бы ты ни писал, всегда все нужно коментировать. И чем полнее, тем лучше. При хорошем коментировании код даже в 1000 строк страшен не будет.

Я всегда стараюсь писать небольшие функции, а если они разбушают, то делю на несколько честей. Если у нас слишком больная процедура , то ее обязательно надо разбить для повышения читаемости и повторного использования кода! 200-300 строк это недопустимо! У меня сердний размер 10-30 сторок. Стараюсь его придерживатся, если сразу невыходит то после переписываю.

Неужели и вправду код функции должен поместится в экран? Найти похожие ветки