Rambler's Top100
"Knowledge itself is power"
F.Bacon
Поиск | Карта сайта | Помощь | О проекте | ТТХ  
 Hello, World!
  
 

Фильтр по датам

 
 К н и г и
 
Книжная полка
 
 
Библиотека
 
  
  
 


Поиск
 
Поиск по КС
Поиск в статьях
Яndex© + Google©
Поиск книг

 
  
Тематический каталог
Все манускрипты

 
  
Карта VCL
ОШИБКИ
Сообщения системы

 
Форумы
 
Круглый стол
Новые вопросы

 
  
Базарная площадь
Городская площадь

 
   
С Л С

 
Летопись
 
Королевские Хроники
Рыцарский Зал
Глас народа!

 
  
ТТХ
Конкурсы
Королевская клюква

 
Разделы
 
Hello, World!
Лицей

Квинтана

 
  
Сокровищница
Подземелье Магов
Подводные камни
Свитки

 
  
Школа ОБЕРОНА

 
  
Арсенальная башня
Фолианты
Полигон

 
  
Книга Песка
Дальние земли

 
  
АРХИВЫ

 
 

Сейчас на сайте присутствуют:
 
  
 
Во Флориде и в Королевстве сейчас  16:00[Войти] | [Зарегистрироваться]

Обсуждение материала
Выносим за скобки
Полный текст материала


Другие публикации автора: Сергей Дуплик

Цитата или краткий комментарий:

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


Важно:
  • Страница предназначена для обсуждения материала, его содержания, полезности, соответствия действительности и так далее. Смысл не в разборке, а в приближении к истине :о) и пользе для всех.
  • Любые другие сообщения или вопросы, а так же личные эмоции в адрес авторов и полемика, не относящаяся к теме обсуждаемого материала, будут удаляться без предупреждения авторов, дабы не мешать жителям нормально общаться.
  • При голосовании учитывайте уровень, на который расчитан материал. "Интересность и полезность" имеет смысл оценивать относительно того, кому именно предназначался материал.
  • Размер одного сообщений не должен превышать 5К. Если Вам нужно сказать больше, сделайте это за два раза. Или, что в данной ситуации правильнее, напишите свою статью.
Всегда легче осудить сделанное, нежели сделать самому. Поэтому, пожалуйста, соблюдайте правила Королевства и уважайте друг друга.



Добавить свое мнение.

Результаты голосования
Оценка содержания

  Содержит полезные и(или) интересные сведения
[1]1050%
 
  Ничего особенно нового и интересного
[2]1050%
 
  Написано неверно (обязательно укажите почему)
[3]00%
 
Всего проголосовали: 20

Оценка стиля изложения

  Все понятно, материал читается легко
[1]15100%
 
  Есть неясности в изложении
[2]00%
 
  Непонятно написано, трудно читается
[3]00%
 
Всего проголосовали: 15




Смотрите также материалы по темам:


Комментарии жителей
Отслеживать это обсуждение

Всего сообщений: 48

16-10-2009 19:09
>>> ИМХО, статья бесполезна, т.к. ничему не учит
По Вашему, и орфографический словарь -- штука бесполезная? Боюсь учителя русского языка с Вами не согласятся ;-) К тому же статья (в отличие от орфографического словаря) все же учит. Вы, наверное, этого просто не заметили.

>>> По сути, автор дает фиксированный шаблон действий
По сути, автор рассматривает типовые ошибочные ситуации (очень, кстати, распространенные), показывает, почему они ошибочные, и как надо этих ошибок избегать. Очень полезно для Hello, World!

>>> Гораздо полезнее человеку привить привычку (извините за тавтологию) ковырять чужие исходники
И это тоже. Но одними исходниками сыт не будешь. К тому же в исходниках не объясняется, почему написано так, а не иначе. Так что это уж точно получится "фиксированный шаблон действий".

>>> Достаточно тех, которые идут в поставке Делфи
Вы серьезно? А вот мне, знаете ли, недостаточно. Ограничиваться исходниками из одного источника -- это гарантированно потерять широту охвата.

P.S. Опять же, хочется повторить для профи: это статья для Hello, World! Делайте на это поправку. Этак Вы скажете, что детские книжки по арфметике не нужны (в которых к двум яблокм прибавляют три яблока). А надо сразу теорию чисел давать. Я, конечно, понимаю, что люди старой закалки прорвались своей головой (в том числе и через анализ источников), но на это ушло много времени. Если есть возможность что-то разжевать и объяснить, то это никак не помешает освоению предмета. Скорее, поможет. Поможет сэкономить время.
 Geo


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
 Geo


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! и ориентирована на начинающих программистов. Учит она не какой-то там хитрой и никому ненужной оптимизации, а азам программистской культуры. Начинающий должен читать, обдумывать, еще раз обдумывать, а потом применять на практике. Это должно быть доведено до автоматизма, чтобы не тратить лишнее время, а сразу писать правильно. И не говорите, что это невозможно, Вас здесь сразу опровергнут на личных примерах очень много людей, потому что приведенные в статье примеры того, как надо писать (и как не надо писать), для многих здесь очевидны. Собственно, люди так и пишут.

В общем, сначала я написал развесистое сообщение, ответив Вам по пунктам, но решил это не публиковать, чтобы не уводить обсуждение в сторону.
 Geo


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
 Geo


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
 Geo


30-09-2009 12:54
Что касается непосредственно написания кода, то объем, который я разрабатываю для себя, на порядки больше того объяма, который я делаю для организации. Я же не программистом работаю, так что для меня неписание кода по работе -- это очень редкая ситуация. Следовательно, в большинстве случаев оформлением собственного кода распоряжаюсь я сам. А я сам применяю такой формат, который был бы удобен мне самому для работы с кодом. И не вижу смысла менять его только для того, чтобы соответствовать каким-то нововведениям в области оформления.

Geo, лично Вам переучиваться нужды скорее всего нет. Но если речь идет о том, как учить других, особенно начинающих, то поддержу Александра - форматировать код как в VCL/RTL. Не всем же со своим кодом работать в одиночестве
 Ins


30-09-2009 02:46
Понятно. У меня просто "14 лет" и "нововведения" в программировании не ассоциируются :)


30-09-2009 02:42
>>> Не понял, о каких нововведениях идёт речь
То, что Borland/CodeGear/Embarcadero при оформлении своих исходников:
1. При объявлении переменных двоеточие, разделяющее имя и тип, ставит вплотную к имени переменной;
2. В списках (например, параметров процедур) после запятой ставит пробел;
3. В внутренних блоках кода операторные скобки begin и end выравниваются по внешнему коду, а не по внутреннему;
4. И т.д. и т.п.

Все это для меня является нововведением. Нет, я допускаю, что Филипп Кан изначально оформлял свой код именно так. Но тогда мне его код не был доступен и я не мог учиться у гуру. Поэтому появление исходников VCL и (почему-то) и их отличия в оформлении кода -- все это для меня яавляется нововведением.
 Geo


30-09-2009 01:56
>>> Вы сказали, что исходники VCL все читают без проблем, значит тот формат наиболее удобен.
Эээ... я вовсе не это хотел сказать и специально это подчеркнул жирным.
Я хотел сказать, что если каждый программист будет придерживаться единого стандарта, то таких проблем в принципе не будет. Как только стандарт войдёт в привычку, он и будет наиболее удобным. И пока у нас есть только один стандарт оформления, который может претендовать на роль единого. Собственно, вот и вся мысля.

>>> И не вижу смысла менять его только для того, чтобы соответствовать каким-то нововведениям в области оформления.
Не понял, о каких нововведениях идёт речь.


30-09-2009 01:17
>>> Я имел ввиду ситуации, когда вы сами можете распоряжаться оформлением своего кода
Что касается непосредственно написания кода, то объем, который я разрабатываю для себя, на порядки больше того объяма, который я делаю для организации. Я же не программистом работаю, так что для меня неписание кода по работе -- это очень редкая ситуация. Следовательно, в большинстве случаев оформлением собственного кода распоряжаюсь я сам. А я сам применяю такой формат, который был бы удобен мне самому для работы с кодом. И не вижу смысла менять его только для того, чтобы соответствовать каким-то нововведениям в области оформления.

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

>>> Вот и пример в доказательство моей точки зрения :)  Каждый стремится переформатировать код, как ему удобно
Не понял? А я разве пытался доказывать, что каждый стремится использовать тот формат, который ему неудобен?! ;-)
Вы сказали, что исходники VCL все читают без проблем, значит тот формат наиболее удобен. Я возразил, что это зависит от сложности кода. Есть код, сложность которого такова, что у моих мохгов не остается лишних ресурсов на распознавание непривычного формата.

А так, конечно, стандарт VCL не так уж и плох. Я не спорю. И мне он тоже вполне понятен, так как собственный формат незначительно отличается от ихнего.
 Geo


30-09-2009 00:22
>>> Правыильно будет: это стандарт, принятый в той организации, где ты работаешь.
Ну это конечно.
Я имел ввиду ситуации, когда вы сами можете распоряжаться оформлением своего кода.

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


30-09-2009 00:14
>>> Насколько снизилась вы ваша производительность при таком C-like коде?
Наверное, снизилась бы немного. Но если стандарт хоть какой-то есть, то все не так плохо. Хуже, когда текст написан вообще без форматирования или не придерживаясь одного стандарта.

>>> Представляю, как бы вам было весело работать в одной команде.
>>> ...
>>> это стандарт от CodeGear
У Вас противоречие. Правыильно будет: это стандарт, принятый в той организации, где ты работаешь.

>>> Ни у кого не возникнет проблем с чтением его исходников (исходники RTL/VCL читают все). Этот стандарт легко принимается любым человеком.
При анализе особо сложных участков кода я иногда переформатирую текст по-своему, чтобы было удобнее читать. Даже если это священная корова от CodeGear ;-)

>>> Вот доведут до ума CodeFormatter в D2010 и наступит рай на Земле :D (шутка, конечно же)
Надеюсь, фича будет опциональной :D
Мне VBA с его строгим форматированием хватает выше крыши.
 Geo


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:15
to Shoor:
И опять, и снова... Мы говорим "оптимизация", подразумеваем "быстродействие". А читабельность кода Вас вообще не волнует? Или Вы считаете, что могучая система дилнных IF-ов улучшает читабельность кода?
 Geo


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, это такой же важный вопрос, как правильная организация условных операторов? Это в какой книге такое написано?
 Geo


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:53
to Сергей Хачатуров:

Все таки поддержу автора.

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

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


18-09-2009 00:35
imho, статья ни о чем.


17-09-2009 14:04
>>> Нет, тут я с Вами не могу согласиться :)
Да я и не нестаиваю. Просто пытаюсь отрефлексировать причины своей нелюбви к размещению текста в русурсах ;-) Ясно дело, что мое мнение является чисто субъективным.

>>> Вы же не меняете исходники VCL
А знаете почему? Исключительно для обеспечения совместимости. А вот другие библиотеки (не такие... э-э-э... фундаментальные) правлю очень даже часто.
 Geo


17-09-2009 11:44
Усли они все собраны в одном месте, допустим, в модуле с абстрактным названием ErrorMessages.pas, то не думаю, что у француза (или даже китайца) возникнут проблемы с поиском ;-)

А если я поставляю один единственный юнит, то в самом начале interface или implementation разместиь подряд все текстовые константы, сопроводив это дело комментариями.

Кстати, а зачем исходники отдавать? Пусть переведет на хранцузский и пришлет перевод мне, а я сам поменяю и вышлю ему готовый франкоговорящий DCU/DLL/EXE


Нет, тут я с Вами не могу согласиться :) Во-первых, библиотека - это вещь в себе, и править и копаться в ней никто не хотел бы. Вы же не меняете исходники VCL. Искать автора и ждать чего-то - нет гарантии что все будет сделано вовремя и в нужный срок. Да и автору больше делать нечего %-) resourcestring как раз для того, чтобы сами все смогли сделать.

'Братан, ты гонишь! Ты ваще фишку просек?'
И не по делу, и не враг сам себе. А если еще по знакомым модификацию раздаст... :D


Ну, то, что значения из RTLConsts.pas подправит Вас же не волнует :) Там ведь тоже в resourcestring-ах все ;-) В общем, очень простое правило, чтобы раздувать над ним проблему, к тому же, в новых версиях Delphi в меню Refactoring есть пункт Extract Resource String, позволяющий несколькими движениями пальцев превратить строковый литерал в resourcestring :)
 Ins


17-09-2009 09:46
>>> Иначе французу, использущему ваш компонент в своем проекте, не понравится копаться в его исходниках и менять значения строковых констант
Усли они все собраны в одном месте, допустим, в модуле с абстрактным названием ErrorMessages.pas, то не думаю, что у француза (или даже китайца) возникнут проблемы с поиском ;-)

А если я поставляю один единственный юнит, то в самом начале interface или implementation разместиь подряд все текстовые константы, сопроводив это дело комментариями.

Кстати, а зачем исходники отдавать? Пусть переведет на хранцузский и пришлет перевод мне, а я сам поменяю и вышлю ему готовый франкоговорящий DCU/DLL/EXE

>>> Если по делу изменит - замечательно, а нет - так сам себе враг
Хм... Напишу я что-то вроде
'Данная операция необратима. Вы уверены, что хотите продолжить ее выполннение?'
А какой-нибудь весельчак поправит
'Братан, ты гонишь! Ты ваще фишку просек?'
И не по делу, и не враг сам себе. А если еще по знакомым модификацию раздаст... :D
 Geo


17-09-2009 09:35
До такого уровня я еще не поднялся ;-)

Скажем так, если эти сообщения в коде приложения, которое ТОЧНО никогда не понадобится переводить на другие языки - то необязательно, а в коде библиотек/компонент общего назначения - это ОБЯЗАТЕЛЬНО. Иначе французу, использущему ваш компонент в своем проекте, не понравится копаться в его исходниках и менять значения строковых констант. Проще не гадать, понадобится или нет, а сразу написать resourcestring вместо const :)

Да и не нравится мне, что любая обезьяна может подправить текст сообщения :D

Ну и пусть :-) Если по делу изменит - замечательно, а нет - так сам себе враг. Вас же не смущает, что любая обезьяна может удалить exe-файл ;-)
 Ins


17-09-2009 09:18
>>> а еще лучше - в resourcestring
До такого уровня я еще не поднялся ;-)
Да и не нравится мне, что любая обезьяна может подправить текст сообщения :D
 Geo


17-09-2009 09:13
to Geo:
Текстовые выражения нужно вынсить в именованные константы в одно общее место. Например, в начало юнита или даже в отдельный юнит.

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

Автору:
Однако примеры эти вполне реально экономят память и упрощают процесс внесения изменений в текст программы, что неоднократно проверено автором.

Память - последнее дело :) А вот то, что код становится легче для восприятия и модификации - это самое главное. Вообще, для тех кто хочет двигаться в этом направлении дальше, почитайте "Рефакторинг - улучшение существующего кода" Фаулера. Ну и еще нужно иметь в виду, что читабельность кода - понятие индивидуальное, так что увлекаться не нужно. Одним понятнее:

if a < 0 then
  b := 0
else
  if a > 255 then
    b := 255
  else
    b := a;


Другим же:

b := Max(0, Min(255, a));


 Ins


17-09-2009 03:25
1. Абсолютно полезная статья. Конечно, на разном уровне развития программист по-разному может оценить полезность конкретных рекомендаций.
Но методическая важность статьи очевидна (особенно для начинающих): она освещает проблему. Программирование - не наука, а технология. Поэтому одну и ту же задачу можно решить по-разному. И начинающий программист не должен "тупо" хвататься за первый попавшийся прием, а должен уметь анализировать эффективность самим же изобретенных конструкций.
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);


Уф! Хотел еще про константные массивы рассказать, про прелести перечислимых типов, про... Но это еще на одну статью потянет ;-)
 Geo


16-09-2009 15:02
Пожалуй не соглашусь с п.3 "Печатаем сообщение об ошибке".
Если впоследствии придется делать интернационализацию программы, лучше иметь каждое сообщение об ошибке ввиде отдельной строки.
К тому же не уверен, что лучше заводить дополнительную локальную переменную s только для формирования сообщения. Это не есть упрощение. ;)


16-09-2009 14:23
Абсолютно согласен с автором, давно к этим выводам пришёл самостоятельно.
Спасибо за статью - распечатаю и дам каждому из сотрудников (а то устные замечания, похоже, хуже усваиваются и не приводят к желаемому результату).


Добавьте свое cообщение

Вашe имя:  [Войти]
Ваш адрес (e-mail):На Королевстве все адреса защищаются от спам-роботов
контрольный вопрос:
Вода мокрая или сухая?
в качестве ответа на вопрос или загадку следует давать только одно слово в именительном падеже и именно в такой форме, как оно используется в оригинале.
Надоело отвечать на странные вопросы? Зарегистрируйтесь на сайте.

Оценка содержания
 
Содержит полезные и(или) интересные сведения
 
Ничего особенно нового и интересного
 
Написано неверно (обязательно укажите почему)


Оценка стиля изложения
 
Все понятно, материал читается легко
 
Есть неясности в изложении
 
Непонятно написано, трудно читается

Текст:
Жирный шрифт  Наклонный шрифт  Подчеркнутый шрифт  Выравнивание по центру  Список  Заголовок  Разделительная линия  Код  Маленький шрифт  Крупный шрифт  Цитирование блока текста  Строчное цитирование
  • вопрос Круглого стола № XXX

  • вопрос № YYY в тесте № XXX Рыцарской Квинтаны

  • сообщение № YYY в теме № XXX Базарной площади
  • обсуждение темы № YYY Базарной площади
  •  
     Правила оформления сообщений на Королевстве
      
    Время на сайте: GMT минус 5 часов

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

    Web hosting for this web site provided by DotNetPark (ASP.NET, SharePoint, MS SQL hosting)  
    Software for IIS, Hyper-V, MS SQL. Tools for Windows server administrators. Server migration utilities  

     
    © При использовании любых материалов «Королевства Delphi» необходимо указывать источник информации. Перепечатка авторских статей возможна только при согласии всех авторов и администрации сайта.
    Все используемые на сайте торговые марки являются собственностью их производителей.

    Яндекс цитирования