Тема открыта по просьбе жителей Королевства и посвящена обсуждению вопросов оптимизации кода. Выставляйте свои лучшие и худшие тексты и не стесняйтесь их обсуждать. В споре рождается истина. Или, по крайней мере, оптимизация.
Всего в теме 737 сообщений
Добавить свое сообщение
Отслеживать это обсуждение
- Тестирование проекта. Отладка.
- Подводные камни
- Централизованная обработка ошибок
- Бета-тестирование
- Давайте учиться на ошибках.
- Почему программисты допускают ошибки?
- Автоматизированные тесты для GUI
- О системах контроля ошибок
№ 397 20-02-2007 06:51 | |
Ответ на »сообщение 396« (Cepгей Poщин)
___________________________
Там был пример конструировании списков с фильтрацией.
Задача: получить все четные числа.
Решение, например, на Python:
def getEvenNumbers(l):
return [x for x in l if x % 2 == 0]
Конструировать список объектов и фильтровать его по значению свойства Enabled (или еще какого) ничуть не сложнее.
Но это уже проблема Delphi Language, а не подхода к решению.
№ 396 20-02-2007 05:54 | |
Ответ на »сообщение 395« (panda)
___________________________
Там ссылка на статью, а у меня нет доступа. Может своими словами как-то...
№ 395 20-02-2007 05:42 | |
Ответ на »сообщение 394« (Cepгей Poщин)
___________________________
В результате тревиальная конструкция
For i := 0 to ControlCount - 1 do
... на написание которой уходит секунд 15 превратится в сложную задачу.
Честно говоря, плохая конструкция ;-)
См., например, »сообщение 1878 в теме №366 на БП«
№ 394 20-02-2007 04:39 | |
Ответ на »сообщение 393« (Geo)
___________________________
В-четвертых: допустим некто в будущем захочет перебрать все контролы на форме, после DisableCtrl это будет сделать гораздо сложнее. В большом проекте неделя будет затрачена только на поиски и определение смысла этой самой процедуры. В результате тревиальная конструкция
For i := 0 to ControlCount - 1 do
... на написание которой уходит секунд 15 превратится в сложную задачу.
Потом, что будет если DisableCtrl вызвать несколько раз (по ошибке)? А если это происходит где-то в цыкле? А как это повлияет на последовательность перехода по tab?
№ 393 20-02-2007 02:38 | |
Ответ на »сообщение 391« (Бел Амор)
___________________________
>>> Часть участников обсуждения считает, что при недостатке функционала стандартного компонента следует строго писать наследника, в котором этот самый функционал и добавляется.
Не знаю, кто так считает. Но только не я ;-)
Я восстал против другого. Типа, у CheckBox'а убираем Caption, рядом кладем TStaticText и т.д. По-моему, создавать видимость компонента с нестандартными свойствами путем слепления в кучу нескольких стандартных компонент -- это не есть гут. Во-первых, обработка такого "составного компонента" ухудшается (скорость проприсовки, реакция на события и т.п.), во-вторых, зачастую остаеются мелкие "косячки", которые лично мне сильно режут глаз, в-третьих, проблемы могут возникнуть при переходе на другую тему (компьютер, версию ОС).
Так что такой прием я признаю только для одного случая: когда нужно срочно заткнуть дыру, обнаруженную за 5 минут до демонстрации программы Заказчику ;-)
№ 392 19-02-2007 23:11 | |
Ответ на »сообщение 391« (Бел Амор)
___________________________
1. Писать наследника.
2. Делать дополнительную обработку в форме "по месту".
3. Писать отдельнолежащую процедуру.
4. Писать class helper.
Только ради одной этой фичи можно переходить на D2006 (TD). ИМХО, разумеется.
№ 391 19-02-2007 15:58 | |
Поддержу усилиия уважаемого Geo по "поднятию темы".
При обсуждении вопроса »вопрос КС №49421« дикуссия плавно перетекла на обсуждение темы, более подходящей для этой ветки.
Попробую кратко сформулировать суть вопроса.
Часть участников обсуждения считает, что при недостатке функционала стандартного компонента следует строго писать наследника, в котором этот самый функционал и добавляется. Мол, "на то оно и ООП". Я считаю, что к решению этой задачи следует подходить более сбалансированно и кроме вышеуказанного метода вполне допустимы еще два. Итак, с одной стороны: жестко писать наследника, с другой - сбалансированное применение трех методов:
1. Писать наследника.
2. Делать дополнительную обработку в форме "по месту".
3. Писать отдельнолежащую процедуру.
Когда применять:
1. Нормальный универсальный вариант. Общий случай.
2. Если нужно добавить что-то, что требеутся только в одном единственном месте на весь проект и все сводится к паре обработчиков по паре строк. В качестве примера можно привести »вопрос КС №49421«
3. Если эта процедура позволяет реализовать что-то очень просто и очень универсально.
В качестве примера для пункта 3 приведу реальный кусок из моего модуля FormUtil
(сразу оговорюсь, что работаю с D6 и, возможно, в D2006 процедура HideScroll неактуальна):
procedure HideScroll(CtrlGrid: TDBCtrlGrid);
var
Panel: TPanel;
begin
Panel := TPanel.Create(CtrlGrid.Owner);
Panel.Parent := CtrlGrid.Parent;
Panel.Top := CtrlGrid.Top;
Panel.Left := CtrlGrid.Left;
Panel.Height := CtrlGrid.RowCount * CtrlGrid.PanelHeight;
Panel.Width := CtrlGrid.ColCount * CtrlGrid.PanelWidth;
Panel.TabOrder := CtrlGrid.TabOrder;
CtrlGrid.Parent := Panel;
CtrlGrid.Top := 0;
CtrlGrid.Left := 0;
Panel.TabStop := False;
end;
procedure DisableCtrl(Ctrl: TWinControl);
var
Panel: TPanel;
begin
Panel := TPanel.Create(Ctrl.Owner);
Panel.Parent := Ctrl.Parent;
Panel.Top := Ctrl.Top;
Panel.Left := Ctrl.Left;
Panel.Height := Ctrl.Height;
Panel.Width := Ctrl.Width;
Panel.TabOrder := Ctrl.TabOrder;
Ctrl.Parent := Panel;
Ctrl.Top := 0;
Ctrl.Left := 0;
Panel.Enabled := False;
end;
Если для HideScroll вполне применим и способ 1, т.е. создать наследника TDBCtrlGrid, то процедура DisableCtrl - гораздо более универсальный подход, т.к. сразу охватывает всех наследников TWinControl.
P.S. (задумчиво...) Переписать чтоли через with... (зевая...) можно будет убрать var...
P.P.S. ;)
№ 390 23-01-2007 03:20 | |
Ответ на »сообщение 389« (Cepгей Poщин)
___________________________
Если отстреливать всех, кто игнорирует все предупреждения компилятора, то рикуешь остаться один со всем их немалым программным наследием, except end; и {$WARNINGS OFF}.
Ну... можно, например, найти работу, где разработанные программы в принципе не тестируются (чтобы не огорчаться). Но оно Вам надо? Если развитие культуры программирования не поддерживается (а даже наоборот) - это не повод снижать и свою культуру.
P. S. Будь на то моя воля, я бы предупреждение Return value of function ... might be undefined сделал бы ошибкой.
Ну так а я о чем толкую? ;-)
Если приходится рецезировать код, в котором стоит {$WARNINGS OFF} (или при компиляции выдаются предупреждения), я просто сразу отпинываю его обратно. Разумеется, автор кода может пойти к своему начальнику, моему начальнику и т.д. (вплоть до директора). Но почему-то так не делает :-)
№ 389 23-01-2007 01:34 | |
Ответ на »сообщение 388« (panda)
___________________________
У меня выработалась привычка по меньшей мере с подозрением относиться к предупреждениям и подсказкам компилятора А у меня выработалась привычка дуть на холодную воду... Думаю не самя вредная.
Если отстреливать всех, кто игнорирует все предупреждения компилятора, то рикуешь остаться один со всем их немалым программным наследием, except end; и {$WARNINGS OFF}.
Кстати по быстродействию разница близка к ошибке измерения.
P. S. Будь на то моя воля, я бы предупреждение Return value of function ... might be undefined сделал бы ошибкой.
№ 388 23-01-2007 00:11 | |
Ответ на »сообщение 384« (Max Belugin) и »сообщение 385« (Cepгей Poщин)
___________________________
Понимаете ли в чем дело. У меня выработалась привычка по меньшей мере с подозрением относиться к предупреждениям и подсказкам компилятора (и отстреливать - на работе - всех, кто пытается их игнорировать) ;-)
Исключения конечно, есть, но они могут распространяться на 1-2 строки и учитывать не все предупреждения, а только некоторые (например, Unsafe code).
Поэтому возможностей Delphi в этом плане мне хватает за глаза и за уши.
Добавить свое сообщение
Отслеживать это обсуждение
Дополнительная навигация: |
|