Здравствуйте.
Выкладываю свою работу - статью с некоторыми советам программисту в среде Delphi.
Очень хотелось бы услышать замечания, предложения, отзывы, критику и похвалу (если есть за что).
А на идею написания этой статьи подтолкнули... ну, в общем, посмотрите вложенный файл.
Вкладываю пока что архив с *.DOC файлом, не поленитесь скачать и распоковать.
Жду отзывы.

4.10.2007 - новая версия. Исправил баг с Stream, ещё несколько корректировок

Это сообщение отредактировал(а) fse - 4.10.2007, 12:15

Присоединённый файл ( Кол-во скачиваний: 22 )
 Delphi_article.rar 26,33 Kb

При беглом взгляде:

•  в Doc файле выравняй текст по левому и правому краю одновременно; Так читать приятнее  
•  после // нужно делать отступ в один пробел
•  
  

  Код

  if FMyProp = 0 then       FEnumeration := meC else //можно ставить в строке, что и одиночное действие после if

  
  Очень не рекомендуется. Точнее категорически.
• Список сочетания клавиш далеко не полный (укажи, хотя бы, что он не полный)
• if not Elements[N].Active then Continue; // так не рекомендуется писать действия после then 
  должно быть на следующей строке (поверь так потом легче код читать)

Почитай Эта незнакомая IDE! Небольшой список приёмов,
Стандарт стилевого оформления исходного кода DELPHI
и дополни  

Статья нормальненькая, но можно сделать её великолепной. Дерзай  


Это сообщение отредактировал(а) ALeXandrK - 3.10.2007, 23:59

ALeXandrK, спасибо за первый по теме отзыв! 
Несколько моментов

Этого не понимаю, почему? Внутренний метод класса напрямую меняет личное поле, по-моему корректней некуда. Если можно, то поясни


Согласен! Не полный, в следующей версии это отмечу! Ещё, буду признателен, если дополнишь список горячих клавиш своими!;)



Не согласен Как писал в статье, за эталон оформления принимаю исходные коды разработчиков. then, на сколько знаю и привык сам - пишется в строке, что и условие. Возможно, ты говорил про Continue, что он пишется по правилам в новой строке. Не спорю, по логике оформления - да, но не по читабельности. Поэтому я залез в Classes.pas и нажал Ctrl+F со строкой Continue и Break:

if FSourcePtr^ = #0 then Exit;
if AClass = TPersistent then Break;
if I > L then Break;
if not (Text[0] in ['0'..'f']) or not (Text[1] in ['0'..'f']) then Break;
if Parser.NextToken = ']' then Break;


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

Я имел ввиду не корректность с точки зрения компилятора, а 
корректность с точки зрения пользователя. В большом проекте
это может просто свести с ума (поэтому и категорически  )! 

Про оформление условных операторов:
сам раньше так писал, но потом прочел две статейки, которые указаны в 
моем предыдущем посте, попробовал и понял (почувствовал на собственной
шкуре), что так удобнее и правильнее.

Полный список клавиш я указал (смотри ссылки).

Кстати, укажи в статье еще на такую прекрасную вещь, как
Help (особенно нажатие F1, когда стоишь на определенном
участке кода, например, неизвестной ф-ии).
Help - это мощнейшая вещь, если знать как её пользоваться  

Это сообщение отредактировал(а) ALeXandrK - 4.10.2007, 01:04

Всё же странно. Даже в большом проекте - это понятное действие... Да и по сути, если класс написан не отвратно - то сторонний программист не должен смотреть его реализацию, не за чем. А таким манером, что я написал, на самом деле написан весь VCL 
Что ж, заинтересовало, как-нибудь посмотрю в Debuger-е как это выглядит с точки зрения компилятора.

Про HELP - обязательно подумаю, вероятно будет не лишним справке посвятить раздельчик! Как-никак, без неё никуда! Тем более в API.

Не знаю как вам, а мне кажется что очень трудно писать на подобную тему. Здесь очень много философских вопросов и обороты типа "эталон", "всегда делай так, а не так", "никогда не используй", "всегда используй" я бы не рискнул употреблять. Частности:

• Вопрос о том брать ли в качестве эталона код, написанный разработчиками VCL философский. Разработчик языка не всегда лучший его пользователь, IMHO. К тому же не факт что писатель модуля classes вообще имел какое-то отношение к разработке языка или даже компилятора.
• В статье говорится "используй всегда with", а вот в третьем издании "Язык программирования C++" небезызвестный Бьерн не рекомендует использовать аналогичную инструкцию в C++.
• Стоит ли писать 

  Код

  if FSourcePtr^ = #0 then Exit;

  
  тоже вопрос спорный. Представьте себе процесс отладки и что после then не Exit, а что-то что не вызовет безусловного перехода. И не поймёшь выполнено условие или нет.

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

"Не сложно обратить внимание на появившийся Hint и просто удалить ненужную строковую переменную S1. Поверьте, среда не ошибётся, вы можете удалить S3 из списка переменных!" - ляп

"Инлайните вручную некоторые процедуры при их частом вызове" - не актуально, последние версии дельфи умеют инлайнить.

"Что я понял, в 99% случаев это просто не надо! Компилятор и без того очень адекватно переводит код в ассемблер, Вы сделаете это даже при весомом стаже, не на много лучше!" - очень спорно, у меня ассемблер даёт выигрыш от 200% до 1000%. тут скорее проблема в том, что без профайлера трудно найти узкие места в коде.

"Не гнушайтесь работать с памятью" - бред, для копирования массивов есть штатное средство - Copy.

"Однако, компилятор всего может и не учесть, вот пример напрасного Warning-сообщения:" - вовсе оно не напрасное, Stream действительно может быть не создан. решается такая проблема с помощью двух try и finally.

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

в общем, рано вам ещё писать статьи. обилее восклицательных знаков наводит на размышления.

Melancholic, Про эталон, VCL разрабатывало много людей. Именно не "левых", а работники Borland. И везде идентичное оформление - естественно, это их эталон. Которого, по моему убеждению, можно придерживаться. По крайней мере не писать код так, как это делают некоторые...
Стоит ли писать if FSourcePtr^ = #0 then Exit; вопрос не спорный. Компилятор отлично это переведёт в asm. И при отладке проблем никаких, и наглядность кода возрастает, ведь нет кучи ветвлений.
Про with - напрасно ты так говоришь. Ничего страшного не произойдёт при его использовании, это служебное слово просто позволяет укоротить код, а компилятору-то какая разница?


stab, попрошу быть объективным, если Вам не понравилась статья, то это не значит, что другим она не нужна;)
В любом случае, спасибо за отзыв!

Действительно, опечатался! Не S1, а S3.



А не последнии?  По крайней мере эта мера лишней не будет.



Ну, в узких местах он конечно нужен. Но тогда придётся, вероятнее всего, переписывать не только узкие места, но и оптимизировать много другого кода. Это уже относится к, возможно, финальной стадии проекта. Я же даю просто рекомендации, а не учу как использовать asm в Delphi. Буду благодарен, если ты выложишь asm код, дающий 1000% выигрыша - обязательно включу в статью;)

И ещё, не согласен про то, что конструктор не создаст объект если будет ехертион. Советую, поэкспериментируй - убедишься. И ещё, исправь в проектах своих то, где ты не удаляешь объект после конструктора с ошибкой;)
Как-никак, за создание объекта в памяти отвечает TObject, а все классы производныеот него! Иначе как бы ты мог в конструкторе своего объекта обращаться к полям??? А если в конструкторе возник ехептион, то что, объект сам вызовет для себя деструктор, а если деструктор переписан? Самовольно объект себя не ведёт.

я и так предельно объективен. люди будут читать статью, а в ней вы даёте ложную информацию. понравится она тем, кто не в курсе что это лож.



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


ага, ложные рекомендации и не хотите принимать критику.


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



совет, почитайте хотя бы хелп:

"If an exception is raised during execution of a constructor that was invoked on a class reference, the Destroy destructor is automatically called to destroy the unfinished object."

относительно того примера со Stream, если вы приравнеяте Stream nil перед входом в try и будет исключение, то после выход из try в Stream будет nil, а если не прировняете его nil, то будет там мусор, вызов Free для которого приведёт к исключению с довольно большой вероятностью.

Вот это "мудрые слова". Можно придерживаться. Но считать это эталоном в последней стадии не стоит.
К слову о .
Представим себе такое
Если в режиме пошаговой отладки выполнение уходит от строчки с условием к строчке с диалогом, то не понятно выполнено ли условие. Если написать

то если условие выполнено, то выполнение пойдёт на a:=0;, а несли нет, то на диалог.
Про with говорил не я, а разработчик стандарта ANSI C++. Аргументировал это тем, что with может привести к конфликтам имён. По сути используя with мы включаем все имена из одного пространства имён в другое, что черевато последствиями.

Это сообщение отредактировал(а) Melancholic - 4.10.2007, 11:25

Melancholic, про a := 0; я не спорю Это выглядит плохо
Но про Exit всё же - частный случай. По логике оформления он попадает под a := 0, но не по читабельности. Ведь при пошаговой отладке после этой строки выполнение сразу переместится на end, тут сложности не возникнет.
Ну, это, действительно, только рекомендации по оформлению, я же не буду программистов заставлять писать "как я сказал" 
В документ обязательно добавлю акцентирование на "рекомендации", а по просьбе stab-а уберу смущающие знаки восклицания 

И пару слов про with.
Конфликт имён - да, такое есть. Но ещё есть такая вещь как приоритетность имени, например

Тут 2 Width: ширина кнопки или формы. Но всё же компилятор без вариаций выберет именно кнопку.
Конечно, такого желательно не допускать.
Но вот пример из проекта, в котором без with сложновато:


Если бы я писал
CoordinateSystem.DirectionOX.X
CoordinateSystem.DirectionOX.Y
CoordinateSystem.DirectionOX.Z
Вместо X, Y, Z - было бы сложнее разобраться

Это сообщение отредактировал(а) fse - 4.10.2007, 11:43

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

Где ложь-то? Про конструктор исправляю.
И ещё, просьба, обратите внимание на тему "отрезюмируйте+замечания+предложения".
Жду от Вас обоснование слов, для меня это важно. Пока что я вижу, что вы оклеймили ложью всю статью... Любопытно....

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

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

stab, ну это Ваше мнение. Как я понял, вы никогда не ошибаетесь! Ставится вопрос в этом когда вы утверждаете про 1000%. Тогда чем вообще компилятор занимается? Туфту ассемблерную гонит? Или, скорее всего, без ассемблера Вы сделали очень медленный код. Вот для этого у меня и есть раздел "оптимизация", почитайте.
И ещё, вы сами сказали, что не прочитали статью полностью. Теперь, когда столь вопиющая ошибка исправлена, прочитайте. Я жду от вас не обличение во лжи, а дельные советы или указания на другие ошибки.
Спасибо.

Не будем отклоняться от темы, я выложил статью не спорить с кем-то.
Жду от Вас сообщений.

вам известно что-нибудь про SSE? простейший пример: сложение 16-ти байт, выполняется с помощью одной инструкции - paddb, которая выполняется за 2-3 такта процессора, таким образом получается выигрыш 1600%. если к этому прибавить пристрастие славного компилятора дельфи к работе со всем на стеке, от которого можно избавиться только с помощью ассемблера, то эти 1600% могут запросто превратится в 2000%.