| | | | |
Полный текст материала
Другие публикации автора: Сергей Дуплик
Цитата или краткий комментарий: «... На некоторых конструкциях хотелось бы остановиться и показать, как можно повысить эффективность и быстродействие программы, уменьшить размер используемой памяти, улучшить читаемость кода и повысить удобство работы с исходными текстами программ. ...» |
Важно:- Страница предназначена для обсуждения материала, его содержания, полезности, соответствия действительности и так далее. Смысл не в разборке, а в приближении к истине :о) и пользе для всех.
- Любые другие сообщения или вопросы, а так же личные эмоции в адрес авторов и полемика, не относящаяся к теме обсуждаемого материала, будут удаляться без предупреждения авторов, дабы не мешать жителям нормально общаться.
- При голосовании учитывайте уровень, на который расчитан материал. "Интересность и полезность" имеет смысл оценивать относительно того, кому именно предназначался материал.
- Размер одного сообщений не должен превышать 5К. Если Вам нужно сказать больше, сделайте это за два раза. Или, что в данной ситуации правильнее, напишите свою статью.
Всегда легче осудить сделанное, нежели сделать самому. Поэтому, пожалуйста, соблюдайте правила Королевства и уважайте друг друга.
Добавить свое мнение.
| | Содержит полезные и(или) интересные сведения | [1] | 10 | 50% | | | | Ничего особенно нового и интересного | [2] | 10 | 50% | | | | Написано неверно (обязательно укажите почему) | [3] | 0 | 0% | | Всего проголосовали: 20 | | | Все понятно, материал читается легко | [1] | 15 | 100% | | | | Есть неясности в изложении | [2] | 0 | 0% | | | | Непонятно написано, трудно читается | [3] | 0 | 0% | | Всего проголосовали: 15 |
Отслеживать это обсуждение
Всего сообщений: 4816-10-2009 19:09>>> ИМХО, статья бесполезна, т.к. ничему не учит
По Вашему, и орфографический словарь -- штука бесполезная? Боюсь учителя русского языка с Вами не согласятся ;-) К тому же статья (в отличие от орфографического словаря) все же учит. Вы, наверное, этого просто не заметили.
>>> По сути, автор дает фиксированный шаблон действий
По сути, автор рассматривает типовые ошибочные ситуации (очень, кстати, распространенные), показывает, почему они ошибочные, и как надо этих ошибок избегать. Очень полезно для Hello, World!
>>> Гораздо полезнее человеку привить привычку (извините за тавтологию) ковырять чужие исходники
И это тоже. Но одними исходниками сыт не будешь. К тому же в исходниках не объясняется, почему написано так, а не иначе. Так что это уж точно получится "фиксированный шаблон действий".
>>> Достаточно тех, которые идут в поставке Делфи
Вы серьезно? А вот мне, знаете ли, недостаточно. Ограничиваться исходниками из одного источника -- это гарантированно потерять широту охвата.
P.S. Опять же, хочется повторить для профи: это статья для Hello, World! Делайте на это поправку. Этак Вы скажете, что детские книжки по арфметике не нужны (в которых к двум яблокм прибавляют три яблока). А надо сразу теорию чисел давать. Я, конечно, понимаю, что люди старой закалки прорвались своей головой (в том числе и через анализ источников), но на это ушло много времени. Если есть возможность что-то разжевать и объяснить, то это никак не помешает освоению предмета. Скорее, поможет. Поможет сэкономить время. |
|
16-10-2009 09:37ИМХО, статья бесполезна, т.к. ничему не учит. По сути, автор дает фиксированный шаблон действий. Если вам нужно "это" - сделайте это "так". Гораздо полезнее человеку привить привычку (извините за тавтологию) ковырять чужие исходники. Достаточно тех, которые идут в поставке Делфи. Именно благодаря им, я открыл для себя все то, о чем написал автор и даже больше. |
|
09-10-2009 07:46сообщение от автора материала хочешь сделать хорошо - сделай сам
Это верно. Но если проект большой (или становится со временем большой), то все сделать самому просто физически не под силу... К тому же, есть вещи, которые делать просто не очень хочется. Я, например, не люблю программировать отчеты. ;)
видел и правил базу ИС с десятками этих хранимых процедур
Не далее как два года назад я и сам с такой базой работал. Ну, тяжеловато, конечно, но у нас было четко расписано, кто за какие объекты БД несет ответственность. И никто в чужой огород не лазил. В общем-то все жили дружно, и система вполне работала. А руководства для разработчиков, кстати, тоже писать приходилось... |
|
08-10-2009 01:35Как ни крути, но если вы предполагаете транслировать свой проект в другие языки, то конструкция if ErrCode = 0 then ShowMessage('Выполнение завершено успешно')
else ShowMessage('Выполнение завершено неуспешно');
хотя и громоздкая и жрет память, но самая верная...
А так, в статье все верно, но банально. |
|
07-10-2009 11:33>>> новидел и правил базу ИС с десятками этих хранимых процедур. Поверьте, такого АДА не пожелал бы никому.
Тогда можете мне посочувствовать. У нас в Системе несколько тысяч хранимых процедур ;-)
>>> Прям хоть пиши документаци для программистов, вместо пользователей)
Именно этим я и занимаюсь. Кроме всего прочего :D
Но все эти обсуждения выходят за рамки темы. Если Вы хотите что-то такое пообсуждать, то для этого есть Базарная Площадь. Вот Вам навскидку пара тем, где Вы можете начать дискуссию, которыю Вы пытаетесь развернуть здесь:
http://delphikingdom.com/asp/talktopic.asp?ID=356
http://delphikingdom.com/asp/talktopic.asp?ID=383 |
|
07-10-2009 07:11Особый respect за статью "Увидеть за лесом деревья", очень понравилась.
Это должно быть доведено до автоматизма, чтобы не тратить лишнее время, а сразу писать правильно.
В легких конструкциях это очевидно, не заметил что статья была написана в "Hello World!". Хотя хочу вернуть ваш камень обратно, мое сообщение было направлено что-бы затронуть вопрос написания более сложных алгоритмов и систем. И влияние на конечный продукт красивого кода.
Но на практике часто выходит так, что ты сам и системщик, и программист, и тестировщик, и еще документацию пишешь, и еще и внедряешь и обучаешь пользователей.
Абсолютно согласен, хотя порой это бывает даже и лучше, по крайней мере сам знаешь где накосячил и где нужно править. Называется, хочешь сделать хорошо - сделай сам. С другой стороны, работа в команде позволяет разгрузить отдельного программиста и если команда сплоченная, если все кодяд примерно на одном уровне - можно горы свернуть. *серьезно задумался* - может поискать такую команду...)))
Вообще со временем, читая полезные советы и видя примеры их реализации сторонними разработчиками начинаешь задумываться, а действительно ли они полезны? Например: БД, хранимые процедуры. Их использование прибавляет такую скорость обработки и выдачи информации, которую ни на одной клиент/серверной структуре запросов не получишь, новидел и правил базу ИС с десятками этих хранимых процедур. Поверьте, такого АДА не пожелал бы никому. Прям хоть пиши документаци для программистов, вместо пользователей) |
|
07-10-2009 00:57сообщение от автора материала for i in a do
Видимо эта конструкция появилась в последних версиях Дельфи. Потому что в D7 я такой не встречал.
Дело в отсутствии системы и точного технического задания программистам. Всегда должен быть человек - системщик. Который строит общую систему взаимодействия разных участков кода в программе
Хорошо бы. Но на практике часто выходит так, что ты сам и системщик, и программист, и тестировщик, и еще документацию пишешь, и еще и внедряешь и обучаешь пользователей. Да и далеко не всегда получишь точного описания бизнес-процессов от того же начальника отдела. Когда я брался за автоматизацию отдела кадров, начальник мне говорила, что им надо вот это, вот это, вот это, хорошо бы еще вот это, да и это не помешает, вот еще кучу отчетов, а вообще чем больше - тем лучше (прямо так и сказала). И каждую отдельную операцию (прием, увольнение, отпуск и т.д.) приходилось по несколько раз уточнять. Зато когда все заработало кадровые сотрудники начали спрашивать меня, например, как правильно расчитать отпуск человеку. Не как сделать это в программе, а как должно быть в соответствии с кодексом, трудовым договором и т.д. А бывало, что натыкался на такой бардак, автоматизировать который было просто невозможно. Приходилось сперва наводить идеологический порядок, а потом программировать. Некоторые части приходилось переписывать из-за неточной начальной постановки (потому что бывает практикуется принцип: ты напиши, а мы посмотрим и скажем, что не так - хотя считаю, что это совершенно неправильно).
А еще бывает, что смотрю на то, что написал когда-то и думаю - как это все работает. Но работает же. А как - непонятно. :) |
|
06-10-2009 17:13Непрерывно размышляйте о своей профессии, о своих собственных действиях, о действиях выдающихся полководцев. Такие размышления — единственное средство для приобретения той быстроты соображения, которая помогает сразу же схватывать и обдумывать все, что можно предпринять в данной обстановке
Эти слова Евгений Савойский сказал про военное дело, но, по сути, это лозунг любого профессионала. Под словом "профессионал" я понимаю человека, хорошо владеющего своим делом, а вовсе не того, кто умеет срубить бабла в какой-то деятельности.
DeepBlack! Думаю, Вы уже догадались, что я намереваюсь швырнуть здоровенный булдыган в Ваш огород ;-)
Данная статья размещена в разделе Hello, World! и ориентирована на начинающих программистов. Учит она не какой-то там хитрой и никому ненужной оптимизации, а азам программистской культуры. Начинающий должен читать, обдумывать, еще раз обдумывать, а потом применять на практике. Это должно быть доведено до автоматизма, чтобы не тратить лишнее время, а сразу писать правильно. И не говорите, что это невозможно, Вас здесь сразу опровергнут на личных примерах очень много людей, потому что приведенные в статье примеры того, как надо писать (и как не надо писать), для многих здесь очевидны. Собственно, люди так и пишут.
В общем, сначала я написал развесистое сообщение, ответив Вам по пунктам, но решил это не публиковать, чтобы не уводить обсуждение в сторону. |
|
06-10-2009 07:58Можно ещё так:
type
TControlArray = array of TControl;
procedure EnableControls(aEnable: Boolean);
var
a: TControlArray;
i: TControl;
begin
a := TControlArray.Create(
Button1,
Edit1,
CheckBox1
);
for i in a do
i.Enabled := aEnable;
end;
|
|
06-10-2009 01:05А многое из этого можно было избежать, если писать не "хоть как-то", а с самого начала затратить больше времени на правильное разбиение кода по процедурам и оптимизацию.
Тут даже больше не в разбиение на процедуры дело. Дело в отсутствии системы и точного технического задания программистам. Всегда должен быть человек - системщик. Который строит общую систему взаимодействия разных участков кода в программе (не путать со стилем написания кода). По собственному опыту знаю, года полтора назад писал информационную систему управленческого учета (заявки/счета+логистика+дебюторка и много чего еще). Пытал директора этой фирмы каждый вечер до 12 ч. выясняя что нужно, как нужно и как это будет работать. После собрал все знания воедино и построил систему, а дальше писал уже опираясь на нее. Порой не хватало времени, или засиживался до такого состояния, что мозг начинал давать неверные команды))) Некоторые участки кода этой ИС я бы с огромным удовольствием переписал. НО: оно работает без сбоев уже полтора года. Заказчик пару раз обращался для "нововведений", все они были внесены без последующих глюков. Вывод напрашивается сам собой, в больших проектах нужна четко поставленная система, а нюансы кода не столь критичны. Единственное, если у программиста руки конечно хоть немного прямые. Испортить то можно все что угодно *) А насчет циклов, месяцев 6-7 назад написал цикл, который автоматически строит список страниц для javascript меню (в нем жесткая структура записи). Понадобилось внести в него изменения. Потратил несколько часов, но так и не понял как, чтобы все меню не рушилось))) Зато цикл по уму сделан))) Могу привести код, если интересно. |
|
06-10-2009 00:03сообщение от автора материала Если никто ни на что смотреть не будет, то никакое, даже самое современное железо, не поможет при работе с такими программами. Да, многие сейчас упирают на то, что заказчику надо быстро получить готовый продукт, чтобы он хоть как-то работал. Но правильно ли это? Да, мы сделали быстро и быстро получили кучу денег. Программа хоть как-то работает. А потом ее требуется доработать (а это бывает довольно часто, заказчик захотел что-то еще). И вот тут начинается мучение, когда на существующие "хоть как-то" написанные программы мы начинаем натягивать или дописывать что-то еще. Опять же методом "хоть как-то", потому что сроки, деньги и что-нибудь еще. А потом надо доделать что-то еще. И еще. И т.д. В итоге получается нечто такое, в чем разобраться уже не может никто, в том числе и разработчик. Количество глюков прогрессирует. На отладку уходит времени на порядок больше, чем на само программирование. И в итоге сроки все равно не выдержаны, программа глючит при любом "нестандартном" ее использовании пользователями (а пользователи - это люди, которые способны сделать такое, что ни один программист не придумает), заказчик недоволен. А многое из этого можно было избежать, если писать не "хоть как-то", а с самого начала затратить больше времени на правильное разбиение кода по процедурам и оптимизацию.
(все вышеизложенное написано, увы, по собственному горькому опыту) |
|
05-10-2009 16:38Абсолютно негативно отнесся к этой статье. Все просто до невозможности. Есть время, анализирую повторения кода, вычленяю общую структуру, строю на ней процедуру и потом просто передаю переменные в нее. Есть время, строю циклы которые собой заменяют многие строчки кода. Причем анализировать цикл можно дня два прежде чем воплотить, а потом через пол года вернувшись к нему убить еще больше времени на его понимание, точно как и в процедурах. Сжатие кода позволяет программе работать быстрее, делает ее красивее, но отнюдь не упрощает понимание, тем более другим программистам. Нет времени, брутфорс, не задумываясь, не красиво, громоздко, но понятно для всех и быстро, ресурсоемко, да кто на это сейчас смотрит? Лишние даже сотня строк кода сейчас мало чего значат(без утечек памяти, конечно). Нужно экономить ресурсы, программите на асме. А придираться к коду могут все, особенно если у них много времени на это. Ой, оформлено не так как у всех! Я не могу это читать, это нововведение! Поставь себе jedi, не ущемляй себя))) |
|
05-10-2009 06:26Извините, Сергей, это я виноват :) |
|
05-10-2009 00:30сообщение от автора материала Вот что хочу заметить.
В статье не идет речь о том, как оформлять код. Где и какие делать отступы. Как писать блоки (типа end - else - begin: в одну строчку или в три). Как писать названия процедур и фукнций при вызове (IntToStr или inttostr). Вставлять или нет пробелы до и после математических операций, знаков присвоения, запятых. Как писать ключевые слови (у нас работал один программист, который все ключевые слова языка: begin, end, if, then, else, for, do и т.д. писал с большой буквы - потому что его так научили в свое время, и он к этому привык). Не об этом сейчас речь. Об этом есть немало книг, в том числе и хороших. А сейчас речь о других приемах. |
|
02-10-2009 08:25>>> Вот мой пример
А в булевских операциях между знаокм операции и опреандами лучше оставлять пробел: читается легче :D |
|
02-10-2009 07:07Статья безусловно полезная. Доходил до этого сам, со временем. Сейчас, конечно, смешно находить в старом своём коде строки вида if (a>b) then c:=true ...
PS:
Ух, ну и дискуссия тут :)
В качестве дополнительной темы для флей... э-э-э... для дискуссии, могу предложить цветовую палитру для Syntax Highlighting.
Да, интересный момент. Вот мой пример: http://savepic.ru/872676.gif
Обратите внимание на цвет фона - не утомляет глаза. Я и системный цвет окон настраиваю серым. С ярко-белым не могу работать. |
|
30-09-2009 13:43>>> Но если речь идет о том, как учить других, особенно начинающих, то поддержу Александра - форматировать код как в VCL/RTL
Сейчас попытался восстановить, с чего началось такое бурное обсуждение формата исходников. Вспомнить не смог, пришлось читать историю. Оказалось, что все началось вот с этой фразы:
"у Borland-а был совершенно иной стиль оформления исходных кодов, уверен, что к нему многие привыкли (в том числе и я), анализировать представленные исходники "очень неудобно". Зачем изобретать велосипед?"
Неявно подразумевая, что все, у кого стиль форматирования отличается от борландовского, сознательно сидели и думали, а как бы так отформатировать текст, чтобы было не как у Борланда :D Пришлось объяснить человеку, что он заблуждается. Ну, а дальше уже слово за слово...
Кстати, после бурных дебатов с Александром отрефлексировал, почему я держусь за свой формат текста и не могу перейти на борландовский. Пока еще очень расплывчато, но прослеживается связь с разным пониманием отдельных идеологических моментов языка Паскаль. Так что иногда другой формат -- это не только блажь и сила привычки.
Впрочем, с выводом согласен: новичкам, у которых еще не сложился строгий стиль оформления, лучше пользоваться борландовским (или очень близко к нему). Потом будет проще, если будете работать в софтверных фирмах, так как корпоративные стандарты основываются именно на этом стиле оформления.
А вот с замечанием "полемиста", с которого все началось, не согласен ;-)
P.S. В качестве дополнительной темы для флей... э-э-э... для дискуссии, могу предложить цветовую палитру для Syntax Highlighting. Ну, непорядок это... смотришь на скриншот с кодом и ни фига непонятно, где строка, а где комментарий. А все потому, что цвета отличаются от тех, которые по умолчанию выставлены в IDE и поэтому являются наиболее правильными ;-)
И начать революцию с Королевства :D
P.P.S. Решил прогнать этот текст в спеллере, а то что-то в последнее время у меня очень много опечаток. Понравилось, как спеллер предложил заменить слово "исходники": исподники. Что-то в этом есть :D |
|
30-09-2009 12:54Что касается непосредственно написания кода, то объем, который я разрабатываю для себя, на порядки больше того объяма, который я делаю для организации. Я же не программистом работаю, так что для меня неписание кода по работе -- это очень редкая ситуация. Следовательно, в большинстве случаев оформлением собственного кода распоряжаюсь я сам. А я сам применяю такой формат, который был бы удобен мне самому для работы с кодом. И не вижу смысла менять его только для того, чтобы соответствовать каким-то нововведениям в области оформления.
Geo, лично Вам переучиваться нужды скорее всего нет. Но если речь идет о том, как учить других, особенно начинающих, то поддержу Александра - форматировать код как в VCL/RTL. Не всем же со своим кодом работать в одиночестве |
|
30-09-2009 02:46Понятно. У меня просто "14 лет" и "нововведения" в программировании не ассоциируются :) |
|
30-09-2009 02:42>>> Не понял, о каких нововведениях идёт речь
То, что Borland/CodeGear/Embarcadero при оформлении своих исходников:
1. При объявлении переменных двоеточие, разделяющее имя и тип, ставит вплотную к имени переменной;
2. В списках (например, параметров процедур) после запятой ставит пробел;
3. В внутренних блоках кода операторные скобки begin и end выравниваются по внешнему коду, а не по внутреннему;
4. И т.д. и т.п.
Все это для меня является нововведением. Нет, я допускаю, что Филипп Кан изначально оформлял свой код именно так. Но тогда мне его код не был доступен и я не мог учиться у гуру. Поэтому появление исходников VCL и (почему-то) и их отличия в оформлении кода -- все это для меня яавляется нововведением. |
|
30-09-2009 01:56>>> Вы сказали, что исходники VCL все читают без проблем, значит тот формат наиболее удобен.
Эээ... я вовсе не это хотел сказать и специально это подчеркнул жирным.
Я хотел сказать, что если каждый программист будет придерживаться единого стандарта, то таких проблем в принципе не будет. Как только стандарт войдёт в привычку, он и будет наиболее удобным. И пока у нас есть только один стандарт оформления, который может претендовать на роль единого. Собственно, вот и вся мысля.
>>> И не вижу смысла менять его только для того, чтобы соответствовать каким-то нововведениям в области оформления.
Не понял, о каких нововведениях идёт речь. |
|
30-09-2009 01:17>>> Я имел ввиду ситуации, когда вы сами можете распоряжаться оформлением своего кода
Что касается непосредственно написания кода, то объем, который я разрабатываю для себя, на порядки больше того объяма, который я делаю для организации. Я же не программистом работаю, так что для меня неписание кода по работе -- это очень редкая ситуация. Следовательно, в большинстве случаев оформлением собственного кода распоряжаюсь я сам. А я сам применяю такой формат, который был бы удобен мне самому для работы с кодом. И не вижу смысла менять его только для того, чтобы соответствовать каким-то нововведениям в области оформления.
Елси же мне придется когда-то много окдить и оформлять свой код в сооитветствии с непривычными форматами, то, скорее всего, первое, что я сделаю, напишу себе форматтер, который будет автоматически форматироать паскаль-текст в том или ином формате. Работать буду со своим форматом, а сдавать -- с казенным.
>>> Вот и пример в доказательство моей точки зрения :) Каждый стремится переформатировать код, как ему удобно
Не понял? А я разве пытался доказывать, что каждый стремится использовать тот формат, который ему неудобен?! ;-)
Вы сказали, что исходники VCL все читают без проблем, значит тот формат наиболее удобен. Я возразил, что это зависит от сложности кода. Есть код, сложность которого такова, что у моих мохгов не остается лишних ресурсов на распознавание непривычного формата.
А так, конечно, стандарт VCL не так уж и плох. Я не спорю. И мне он тоже вполне понятен, так как собственный формат незначительно отличается от ихнего. |
|
30-09-2009 00:22>>> Правыильно будет: это стандарт, принятый в той организации, где ты работаешь.
Ну это конечно.
Я имел ввиду ситуации, когда вы сами можете распоряжаться оформлением своего кода.
>>> При анализе особо сложных участков кода я иногда переформатирую текст по-своему, чтобы было удобнее читать.
Вот и пример в доказательство моей точки зрения :) Каждый стремится переформатировать код, как ему удобно. Проблема в том, что всем удобно "по-разному". |
|
30-09-2009 00:14>>> Насколько снизилась вы ваша производительность при таком C-like коде?
Наверное, снизилась бы немного. Но если стандарт хоть какой-то есть, то все не так плохо. Хуже, когда текст написан вообще без форматирования или не придерживаясь одного стандарта.
>>> Представляю, как бы вам было весело работать в одной команде.
>>> ...
>>> это стандарт от CodeGear
У Вас противоречие. Правыильно будет: это стандарт, принятый в той организации, где ты работаешь.
>>> Ни у кого не возникнет проблем с чтением его исходников (исходники RTL/VCL читают все). Этот стандарт легко принимается любым человеком.
При анализе особо сложных участков кода я иногда переформатирую текст по-своему, чтобы было удобнее читать. Даже если это священная корова от CodeGear ;-)
>>> Вот доведут до ума CodeFormatter в D2010 и наступит рай на Земле :D (шутка, конечно же)
Надеюсь, фича будет опциональной :D
Мне VBA с его строгим форматированием хватает выше крыши. |
|
30-09-2009 00:06Почему-то съелся пробел :(((
Блок с "begin More; MoreMore; end;" (включительно) в первом примере кода должен был быть сдвинут вправо на один пробел.
P.S. Видимо, Королевство тоже не любит самопальных не-CodeGear стандартов оформления :D |
|
30-09-2009 00:03>>> И что мне теперь делать? Срочно переучиваться на стиль оформления текстов, прнятый у программистов Борланда? А оно мне надо?
Эммм... наверное, в меня сейчас полетят камни, но я скажу, что было бы неплохо :)
Вот у вас свой стандарт. У кого-то - совершенно иной. У третьего - тоже другой, отличный от ваших. Код, оформленный по-иному читать тяжело. В некоторых случаях читабельность может снижаться в разы. Например, вы привыкли проверять согласованность расстановок begin/end пробеганием по коду, выискивая begin/end на одной позиции:
if ... then
begin
...
end
else
begin
...
end;
Насколько снизилась вы ваша производительность при таком C-like коде?
if ... then begin
...
end else begin
...
end;
Может быть, это не самый удачный пример, но идею вы поняли, так что примеры можете придумать и сами.
Представляю, как бы вам было весело работать в одной команде. А если немного подумать, то отсюда напрямую следует, что есть один-единственный правильный стандарт, а все остальные - "неверны".
И этот стандарт - это стандарт от CodeGear.
Да, может быть, он не идеален. Может быть, где-то можно было сделать по-лучше. Может быть, вы лично его не используете. Но это - единственный де-факто стандарт. Всё остальное - это мелочь, которая используется только вами. И никем более.
Если человек пишет, соблюдая стандарт CG:
1). Ни у кого не возникнет проблем с чтением его исходников (исходники RTL/VCL читают все). Этот стандарт легко принимается любым человеком.
2). Нет проблем с взаимодействием с другими людьми - они тоже пишут или могут писать так же. В отличие от ваших самопридуманных стандартов, которые никому не известны, кроме вас.
3). Человек может уйти, вместо него придёт другой. Он не станет переписывать код из-за того, что непривычно написано - ведь оформление хорошо известное - "как у Delphi".
4). И т.д.
Знаете, мне кажется, что это стоит того, чтобы изменить свои привычки и писать "как следует".
Я когда-то писал по-другому, ещё с Паскаля. Отступ у меня был в пробел и begin я сдвигал в блок, вот так:
procedure P;
var
F: Integer;
begin
DoSomething;
DoSomethingElse;
if F <> 0 then
begin
More;
MoreMore;
end;
InvokeAppocalypse;
end;
Тогда мне казалось это удобным и "правильным". Потом были Delphi, обмен исходниками, работа с другими программистами.
После того, как я понатыкался ещё на кучу подобных же "доморощенных" стандартов и обнаружил, что меня бесит смешение стилей ("блин, ну как они могут писать ТАК?!"), я сказал себе: "всё, стоп, хватит". И насильно заставил себя писать вот так:
procedure P;
var
F: Integer;
begin
DoSomething;
DoSomethingElse;
if F <> 0 then
begin
More;
MoreMore;
end;
InvokeAppocalypse;
end;
А потом это вошло в привычку (право же, это не заняло много времени и усилий, как вам кажется).
Разумеется, если вы работаете исключительно в одиночку, не в команде, и вообще ваш код никто не читает (кроме вас) и никогда не будет читать, и вы не выкладываете его в Интернете, то - смело используйте любое оформление!
P.S. Вот доведут до ума CodeFormatter в D2010 и наступит рай на Земле :D (шутка, конечно же)
P.P.S. Я не имел ввиду идеальное соответствие стандарту, думаю, что в мелких огрехах нет ничего страшного. |
|
29-09-2009 13:15to Shoor:
И опять, и снова... Мы говорим "оптимизация", подразумеваем "быстродействие". А читабельность кода Вас вообще не волнует? Или Вы считаете, что могучая система дилнных IF-ов улучшает читабельность кода? |
|
29-09-2009 11:36Натыкаясь на свои исходники более чем десятилетней давности прихожу в ужас: как я так мог?! |
|
29-09-2009 11:01В первую очередь нужно оптимизировать алгоритмику. Оценивать со всех точек зрения. Оптимизация например:
if IsAbove then
begin
Button1.Enabled := true;
Button2.Enabled := true;
Edit1.Enabled := true;
end
else
begin
Button1.Enabled := false;
Button2.Enabled := false;
Edit1.Enabled := false;
end;
Даст ничтожный прирост производительности, если данный код исполняется редко (редко - это имеется ввиду что не чаще раза хотябы в секунду).
В большинстве же случаев надо пересматривать алгоритм чтобы повысить производительность. Иначе в большом проекте можно будет вечно перелапачивать такие куски никапли не сдвинувшись в сторону развития проекта.
Если алгоритмика поднята до уровня, и все таки есть желание выжать еще несколько миллисекунд свободного времени, то оптимизировать стоит не подобные операций (во-первых потому как оптимизация одной проверки в приемере выше - это ничто по сравнению с одним единственным Button1.Enabled := false;), а с поиска узких мест, которыми как правило являются циклы. Опять же на математические операции в циклах обращаем внимаение в последнюю очередь, а в первую очередь смотрим на выделение памяти в циклах + вызов потенциально медленных функций внутри цикла. Стараемся вынести все это за цикл. Извиняюсь за жесткую критику, но полезного в этой статье ничего нет. |
|
29-09-2009 08:36>>> у Borland-а был совершенно иной стиль оформления исходных кодов, уверен, что к нему многие привыкли
Извините, но мой стил оформления кода складывался задолго до того, как Borland стал распространять исходники VCL. И что мне теперь делать? Срочно переучиваться на стиль оформления текстов, прнятый у программистов Борланда? А оно мне надо?
>>> Я бы посоветовал прочитать Макконела "Совершенный код", а потом Фаулера
Страна Советов приказала долго жить. Теперь у на демократия и права человека. Попробуйте их нарушить и заставить молодого амбициозного неуча сесть и прочитать не то, чтоюы Макконела с Фаулером, а хотя бы букварь. А я посмотрю как у Вас это получится.
Здесь же статья маленькая, так что может быть и почитает, когда делать нечего будет. На фундаментальный труд данная статья не претендует и конкурентом Фаулеру ни в коей мере не является. Это популярная статья, которая призвана в легкой неутомительной форме доносить до слабо подготовленнгого читателя важные вещи (пусть и в упрощенном виде).
>>> Такое ощущение, что у здесь читают <...>
Извините, а что читаете Вы? В обсуждении статьи по правильной организации кода Вы наравне с этим поднимаете такой важный вопрос, как вопрос оформления текста. Вы действительно считаете, что соответствие количества пробелов в отсутпах стандарту, принятому в Borland, это такой же важный вопрос, как правильная организация условных операторов? Это в какой книге такое написано? |
|
29-09-2009 06:58сообщение от автора материала Память - последнее дело
Ну... не сказал бы. Могу даже привести вот такой пример.
Ставилась задача: загрузить в динамический массив список всех файлов в указанном каталоге. Есть два варианта решения.
Вариант 1
type
TFileList=array of TSearchRec;
var
SearchRec:TSearchRec;
FileList:TFileList;
err,cnt:integer;
begin
setlength(FileList,0);
cnt:=0;
err:=FindFirst('*.*',faAnyFile,SearchRec);
while err=0 do
begin
inc(cnt);
setlength(FileList,cnt);
FileList[cnt-1]:=SearchRec;
err:=FindNext(SearchRec);
end;
FindClose(SearchRec);
end;
Вариант 2
type
TFileRec=record
FileName:string;
DateTime:Integer;
Size:Integer;
Attr:Integer;
end;
TFileList=array of TFileRec;
var
SearchRec:TSearchRec;
FileList:TFileList;
err,cnt:integer;
begin
setlength(FileList,0);
cnt:=0;
err:=FindFirst('*.*',faAnyFile,SearchRec);
while err=0 do
begin
inc(cnt);
setlength(FileList,cnt);
with FileList[cnt-1] do
begin
FileName:=SearchRec.Name;
DateTime:=SearchRec.Time;
Size:=SearchRec.Size;
Attr:=SearchRec.Attr;
end;
err:=FindNext(SearchRec);
end;
FindClose(SearchRec);
end;
Вариант 2 позволяет сократить размер используемой памяти более чем в 20 раз за счет того, что ис-пользуются только те поля TSearchRec, которые нам действительно необходимы.
>>> а еще лучше - в resourcestring
До такого уровня я еще не поднялся ;-)
Да и не нравится мне, что любая обезьяна может подправить текст сообщения :D
Подправить можно и без ресурсов. Все текстовые строки лежат где-то в теле екзешника. Ищем... и меняем. Сам таким образом когда-то программы русифицировал. :)
Братан, ты гонишь! Ты ваще фишку просек
Сразу вспоминается программа, меняющая надписи на кнопках на "Нефиг", "Нафиг", "Пофиг" и т.д. |
|
29-09-2009 06:42Не вижу ничего полезного и совершенно не понятно чему все так радуются...
1) Не знаю как у Embarcodero, но у Borland-а был совершенно иной стиль оформления исходных кодов, уверен, что к нему многие привыкли (в том числе и я), анализировать представленные исходники "очень неудобно". Зачем изобретать велосипед? У Тейксеры с Паченко в книге про 5-ю Дельфи (если я не ошибаюсь) в главе 6 этот стандарт описан.
2) Относительно смысловой нагрузки статьи: тут советовали прочитать Фаулера. Я бы посоветовал прочитать Макконела "Совершенный код", а потом Фаулера. Больше никаких вопросов на поднятую тему возникать не будет...
ps: Такое ощущение, что у здесь читают только Фаронова, Фленова, Архангельского и др. Подобные "достижения" я только у них встречал... И такое пишут ВЕДУЩИЕ ПРОГРАММИСТЫ... |
|
28-09-2009 13:12Что-то слишком мало примеров.
Лично я программирую относительно недавно и все эти "фичи" уже давно знаю, хотя программирую относительно недавно. ;)
P. S. Не нужно забывать, что статья для раздела "Hello, World!". |
|
21-09-2009 06:40Ещё хочу добавить, что выбор неправильного алгоритмического подхода может полностью уничтожить всю экономию от оптимизации кода. |
|
21-09-2009 06:29Статья интересная и полезная, но я более склоняюсь к мнению предыдущеего автора. Кстати, в очень старой книжке, когда оптимизаторы не были столь умными читал: если стоит выбор между скоростью, требовательностью к ресурсам и читабельностью программы, то в большинстве случаев следует выбирать читабельность. Хотя автор к этому тоже призывает (процедуры упрощают понимание).
Про вывод сообщения тут уже говорили. Мне даже кажется, что все эти дополнительные инструкции и переменные при маленьком размере строк могут даже увеличить потребление памяти.
Но в любом случае, такой подход необходим,как минимум, чтобы дисциплинировать программиста. |
|
18-09-2009 12:46Да, статья хорошая, только производительность программы и расходы памяти тут как бы совсем не при чём :) Экономия нескольких байт и инструкций (если она вообще будет, при оптимизирующем-то компиляторе) не сделает тут погоды.
Код пишут в первую очередь для того, чтобы его читали, а вовсе не для того, чтобы его выполнял компилятор (как бы это ни казалось странным). Вот на это и надо упирать. |
|
18-09-2009 03:53to Сергей Хачатуров:
Все таки поддержу автора.
Когда это все давно пройдено, и превращать код в спагетти копипастов не двигаются и рука и подсознание, то кажется, что и говорить не о чем. А вот как столкнешься с этим в чужом коде, а хуже того - поправишь в одном месте, а оказывается, что надо еще в N таких же мест - вот тут и тянет написать серию таких статей, да буквами покрупнее :-)
Конечно, как уже говорили, по хорошему статья должна иметь продолжение в виде завершенного стандарта кодирования, к которому она смотрится просто как введение. |
|
18-09-2009 00:35
17-09-2009 14:04>>> Нет, тут я с Вами не могу согласиться :)
Да я и не нестаиваю. Просто пытаюсь отрефлексировать причины своей нелюбви к размещению текста в русурсах ;-) Ясно дело, что мое мнение является чисто субъективным.
>>> Вы же не меняете исходники VCL
А знаете почему? Исключительно для обеспечения совместимости. А вот другие библиотеки (не такие... э-э-э... фундаментальные) правлю очень даже часто. |
|
17-09-2009 11:44Усли они все собраны в одном месте, допустим, в модуле с абстрактным названием ErrorMessages.pas, то не думаю, что у француза (или даже китайца) возникнут проблемы с поиском ;-)
А если я поставляю один единственный юнит, то в самом начале interface или implementation разместиь подряд все текстовые константы, сопроводив это дело комментариями.
Кстати, а зачем исходники отдавать? Пусть переведет на хранцузский и пришлет перевод мне, а я сам поменяю и вышлю ему готовый франкоговорящий DCU/DLL/EXE
Нет, тут я с Вами не могу согласиться :) Во-первых, библиотека - это вещь в себе, и править и копаться в ней никто не хотел бы. Вы же не меняете исходники VCL. Искать автора и ждать чего-то - нет гарантии что все будет сделано вовремя и в нужный срок. Да и автору больше делать нечего %-) resourcestring как раз для того, чтобы сами все смогли сделать.
'Братан, ты гонишь! Ты ваще фишку просек?'
И не по делу, и не враг сам себе. А если еще по знакомым модификацию раздаст... :D
Ну, то, что значения из RTLConsts.pas подправит Вас же не волнует :) Там ведь тоже в resourcestring-ах все ;-) В общем, очень простое правило, чтобы раздувать над ним проблему, к тому же, в новых версиях Delphi в меню Refactoring есть пункт Extract Resource String, позволяющий несколькими движениями пальцев превратить строковый литерал в resourcestring :) |
|
17-09-2009 09:46>>> Иначе французу, использущему ваш компонент в своем проекте, не понравится копаться в его исходниках и менять значения строковых констант
Усли они все собраны в одном месте, допустим, в модуле с абстрактным названием ErrorMessages.pas, то не думаю, что у француза (или даже китайца) возникнут проблемы с поиском ;-)
А если я поставляю один единственный юнит, то в самом начале interface или implementation разместиь подряд все текстовые константы, сопроводив это дело комментариями.
Кстати, а зачем исходники отдавать? Пусть переведет на хранцузский и пришлет перевод мне, а я сам поменяю и вышлю ему готовый франкоговорящий DCU/DLL/EXE
>>> Если по делу изменит - замечательно, а нет - так сам себе враг
Хм... Напишу я что-то вроде
'Данная операция необратима. Вы уверены, что хотите продолжить ее выполннение?'
А какой-нибудь весельчак поправит
'Братан, ты гонишь! Ты ваще фишку просек?'
И не по делу, и не враг сам себе. А если еще по знакомым модификацию раздаст... :D |
|
17-09-2009 09:35До такого уровня я еще не поднялся ;-)
Скажем так, если эти сообщения в коде приложения, которое ТОЧНО никогда не понадобится переводить на другие языки - то необязательно, а в коде библиотек/компонент общего назначения - это ОБЯЗАТЕЛЬНО. Иначе французу, использущему ваш компонент в своем проекте, не понравится копаться в его исходниках и менять значения строковых констант. Проще не гадать, понадобится или нет, а сразу написать resourcestring вместо const :)
Да и не нравится мне, что любая обезьяна может подправить текст сообщения :D
Ну и пусть :-) Если по делу изменит - замечательно, а нет - так сам себе враг. Вас же не смущает, что любая обезьяна может удалить exe-файл ;-) |
|
17-09-2009 09:18>>> а еще лучше - в resourcestring
До такого уровня я еще не поднялся ;-)
Да и не нравится мне, что любая обезьяна может подправить текст сообщения :D |
|
17-09-2009 09:13to Geo:
Текстовые выражения нужно вынсить в именованные константы в одно общее место. Например, в начало юнита или даже в отдельный юнит.
Угу, а еще лучше - в resourcestring, если конечно это текст сообщения пользователю, а не какие-то строки, использующиеся сугубо внутри программного кода. :)
Автору:
Однако примеры эти вполне реально экономят память и упрощают процесс внесения изменений в текст программы, что неоднократно проверено автором.
Память - последнее дело :) А вот то, что код становится легче для восприятия и модификации - это самое главное. Вообще, для тех кто хочет двигаться в этом направлении дальше, почитайте "Рефакторинг - улучшение существующего кода" Фаулера. Ну и еще нужно иметь в виду, что читабельность кода - понятие индивидуальное, так что увлекаться не нужно. Одним понятнее:
if a < 0 then
b := 0
else
if a > 255 then
b := 255
else
b := a;
Другим же:
b := Max(0, Min(255, a));
|
|
17-09-2009 03:251. Абсолютно полезная статья. Конечно, на разном уровне развития программист по-разному может оценить полезность конкретных рекомендаций.
Но методическая важность статьи очевидна (особенно для начинающих): она освещает проблему. Программирование - не наука, а технология. Поэтому одну и ту же задачу можно решить по-разному. И начинающий программист не должен "тупо" хвататься за первый попавшийся прием, а должен уметь анализировать эффективность самим же изобретенных конструкций.
2. Дожить бы до того момента, когда появится "программирование в стиле Королевства Дельфи".
|
|
16-09-2009 16:56Очень правильный и полезный материал. Но как и Aleg Azarousky не соглашусь с выводом сообщения об ошибке. И дело тут не обязательно в "интернационализации". В процессе развития программы может потребоваться изменить текст сообщения. И что Вы будете делать, если этот текст составлен сложным образом из кусочков строк? Есть в моем несогласии и еще одна причина. Текстовые сообщения (особенно на русском языке), как правило, достаточно длинные. Соответственно, в коде они плохо читаются. Неважно, будем ли мы их вставлять непосредственно в вызов подпрограммы или сначала присвоим переменной. Текстовые выражения нужно вынсить в именованные константы в одно общее место. Например, в начало юнита или даже в отдельный юнит.
const
msgNormal = 'Выполнение завершено успешно.';
msgError = 'Выполнение завершено неуспешно.';
if ErrCode = 0 then ShowMessage(msgNormal) else ShowMessage(msgError);
Если нам требуется в текст сообщения вставить какую-то дополнительную информацию, то используем шаблоны и замечательную функцию Format
const
msgNormal = 'Загрузка файла %s успешно завершена.';
msgError = 'Ошибка при чтении файла %s. Загрузка прекращена.';
if MyFileLoading(FileName)
then
ShowMessage(Format(msgNormal,[FileName]))
else
ShowMessage(Format(msgError,[FileName]));
Если у нас могут возникать разные ошибки, информация о которых передается соответствующим кодом ошибки, то имеет смысл создавать структурированные конструкции для сообщений, а не писать многочисленные IF-ы или CASE:
type
ErrorCodes = (ecNoError,ecFileNotFound,ecAccessDenied);
const
ErrorMessages : array[ErrCodes] of String = (
'Файл %s успешно загружен.',
'Файл %s не найден.',
'Отказано в доступе к файлу %s.'
);
ErrorCode:=MyFileLoading(FileName);
ShowMessage(Format(ErrorMessages[ErrorCode],[FileName]));
Скажуц даже больше: в именованные константы лучше выносить не только текст, но и вообще все константы кроме самоочевидных, которые никогда не могут измениться. То есть, если у нас есть функция, вычисляющая периметр прямоугольника, то мы не будем никуда выносить двойку, а запишем так:
function Perimeter(const ARect : TRect) : Integer;
begin
with ARect do
Result:=2*((Right-Left)+(Bottom-Top));
end;
А, например, даже вот так лучше не писать:
if Value < 0
then
SetTextColoor(DC,clRed)
else
SetTextColoor(DC,clBlue);
Это я уже не говорю про $0000FF и $FF0000. Это Вы сейчас уверены, что отрицательные значения надо выводить красным, а положительные -- синим. Но, честное пионерское, в будущем цветовое решение може измениться. Поэтому:
const
clPosiyiveNum = clBlue;
clNegativeNum = clRed;
if Value < 0
then
SetTextColoor(DC,clNegativeNum)
else
SetTextColoor(DC,clPositiveNum);
Уф! Хотел еще про константные массивы рассказать, про прелести перечислимых типов, про... Но это еще на одну статью потянет ;-) |
|
16-09-2009 15:02Пожалуй не соглашусь с п.3 "Печатаем сообщение об ошибке".
Если впоследствии придется делать интернационализацию программы, лучше иметь каждое сообщение об ошибке ввиде отдельной строки.
К тому же не уверен, что лучше заводить дополнительную локальную переменную s только для формирования сообщения. Это не есть упрощение. ;)
|
|
16-09-2009 14:23Абсолютно согласен с автором, давно к этим выводам пришёл самостоятельно.
Спасибо за статью - распечатаю и дам каждому из сотрудников (а то устные замечания, похоже, хуже усваиваются и не приводят к желаемому результату).
|
|
|
|