 | | | | |
| Стандарт стилевого оформления исходного кода DELPHI |
Полный текст материала
Цитата или краткий комментарий: | «... Этот стандарт документирует стилевое оформление для форматирования исходного кода Delphi. Оригинал статьи создан Чарльзом Калвертом и расположен на "Borland Community site". В стандарте использованы материалы команды разработчиков Delphi, сообщества разработчиков библиотеки JEDI. Стандарт так же дополнен некоторыми правилами, созданными на основе собственного опыта разработки. ...» |
Важно:- Страница предназначена для обсуждения материала, его содержания, полезности, соответствия действительности и так далее. Смысл не в разборке, а в приближении к истине :о) и пользе для всех.
- Любые другие сообщения или вопросы, а так же личные эмоции в адрес авторов и полемика, не относящаяся к теме обсуждаемого материала, будут удаляться без предупреждения авторов, дабы не мешать жителям нормально общаться.
- При голосовании учитывайте уровень, на который расчитан материал. "Интересность и полезность" имеет смысл оценивать относительно того, кому именно предназначался материал.
- Размер одного сообщений не должен превышать 5К. Если Вам нужно сказать больше, сделайте это за два раза. Или, что в данной ситуации правильнее, напишите свою статью.
Всегда легче осудить сделанное, нежели сделать самому. Поэтому, пожалуйста, соблюдайте правила Королевства и уважайте друг друга.
Добавить свое мнение.
| | | Содержит полезные и(или) интересные сведения | | [1] | 18 | 85.7% | | | | | Ничего особенно нового и интересного | | [2] | 3 | 14.3% | | | | | Написано неверно (обязательно укажите почему) | | [3] | 0 | 0% | |
Всего проголосовали: 21 | | | | Все понятно, материал читается легко | | [1] | 19 | 95% | | | | | Есть неясности в изложении | | [2] | 1 | 5% | | | | | Непонятно написано, трудно читается | | [3] | 0 | 0% | |
Всего проголосовали: 20 |
[Object Pascal , стандартные процедуры и функции]
Отслеживать это обсуждение 
Всего сообщений: 3130-03-2009 03:49>>> А какие обоснованные гипотезы будут насчёт того, почему редактор C++ из Visual Studio тоже делает это? ;)
Про него не скажу, так как не знаю ;-)
>>> И ещё вопрос из серии тупых: а что, в VB нельзя вставлять в программу комментарии? :-P
Можно. Скажу больше, есть возможности и на формат немного повлиять (например, есть признак продолжения строки). Но это не значит, что весь код хранится именно в виде текста. Это означает только то, что есть некая часть, которая хранится в том виде, как она введена пользователем.
А фраза про гипотезу была введена потому, что, с моей точки зрения, тот функционал, который реализован в VBA (в частности, при вводе построчная прекомпиляция или просто проверка с последующим автоформатированием) мне бы удобнее было бы реализовать именно так.
Вот если бы в VBA была возможность отключения автоформатирования (с сохранением возможности работы), тогда бы гипотеза явно оказалась неверна. |
|
30-03-2009 02:43Geo:
А какие обоснованные гипотезы будут насчёт того, почему редактор C++ из Visual Studio тоже делает это? ;)
И ещё вопрос из серии тупых: а что, в VB нельзя вставлять в программу комментарии? :-P |
|
30-03-2009 02:00>>> Даже MS VBA это делает...
Для VBA это жизненная необходимость. Это же интерпретатор. Для ускорения работы, судя по внешним признакам, введенный текст сразу компилируется в некий промежуточный "байт-код", который и хранится. А текст на ЯП, сйдя по всему, восстанавливается из этого байт-кода. Естественно, при этом идет форматирование по стандартному шаблону, так как оформление, введенное пользователем, в полной мере не сохраняется.
P.S. Из разряда обоснованных гипотез. |
|
28-03-2009 10:52Даже MS VBA это делает...
Лучше бы он этого не делал.
Мне вот неудобно читать код оформленный в стиле Borland (слишком много пробелов) и если бы оно было впаяно в IDE, то пришлось бы искать способ его отключать и всё равно ставить какую-то надстройку. |
|
28-03-2009 10:21Странно, что IDE Delphi само не форматирует код как надо.
Даже MS VBA это делает... |
|
12-08-2008 06:09>>> удручает тем что не всегда ясно, а чей собственно end.
Вообще-то, допускается при необходимости использование вот такого оформления (я, естественно, не про пробелы; пробелы расставляю так, как привык):
while CycleCondition do
begin
if Condition
then
begin
end;
end;
Хотя, конечно же, лучше, когда "парные скобки, как блочные, так и арифметические" находятся "в поле зрения". |
|
12-08-2008 05:59Однозначно согласен, стандарты нужны. Но вот конструкции типа
begin
if выражение_символов_на_50-60 then begin
.....
end;
удручает тем что не всегда ясно, а чей собственно end. Толи отступы сбились, толи я что-то пропустил,толи кто-то код правил. Парные скобки, как блочные, так и арифметические всегда должны быть в поле зрения. |
|
11-02-2008 23:53Geo:
Не надо вразумлять таких, как Sasvi, надо молча удалять подобные сообщения и всё. Русским языком написано, что здесь обсуждается содержание конкретной статьи, а не тема стилевого оформления вообще. Если кто-то до сих пор не умеет читать, то и писать ему тем более рано ещё. |
|
11-02-2008 12:42to Sasvi:
Патетику опустим, а в остальном...
Если Вы действительно хотите заявить о своем продукте, то зачем это делать такими спамерскими способами (вклиниваясь в обсуждение, публикуя мейл)? Вы можете сделать это более нормальными способами. Для этого на Королевстве имеется раздел Полигон. Свяжитесь с Еленой Филипповой и скажите, что имете желание выложить на Полигон свои наработки. Пишите небольшое описание и выкладывайте. Вы же все равно собираетесь распространять свой продукт как FreeWare. А публикация на Королевстве Delphi выглядит все же серьезнее, чем просто упомянуть о своих достижениях в обсуждении.
P.S. Услуга размещения материалов на Полигоне тоже FreeWare ;-) |
|
17-01-2008 10:33| В тексте упущена важная, на мой взгляд мелочь - использование единственного и множественного числа. Например, у Borland модули компонентов всегда имеют множественное число: Controls, Dialogs, Menus, а модули форм - единственное: MainForm, AboutForm. Аналогично для индексированных свойств, списков и коллекций. |
|
15-02-2007 00:37Профессионально программирую много лет, с самого выхода Delphi, написал почти 1 000 000 строк кода.
За это время стиль менялся много раз, но в конце пришел к тому же, что пишет Чарльз Карлверт.
На мой взгляд записи типа
if a > b then begin
a := 0 end
else if b > a then begin
a := 1
end;
нормальными людми воспринимаются с большим трудом.
Хотя автор всегда считает это самым клевым стилем.
Убедить молодые горячие головы тяжело, но может кто-нибудь умный и согласится.
Те кто программирует меньше меня, не извращайтесь!!!
Лет эдак через 10 меня обязательно поймете!!!
А пока послушайте старика Калверта, он совсем не дурак.
|
|
14-02-2007 09:40Выдернули же из небытия полемикообразующую статью. Ну, здесь сейчас такое начнется... ;-)
Можно долго спорить о достоинствах и недостатках того или иного стиля, но правильная мысль была сказана еще три с лишним года назад
Стандарт нужен, но только в основном только в своей конторе.
Человек -- это такое существо, которое привыкнет к любому стилю. Но вот только у всех программистов одного коллектива должен быть один единственный стиль (пусть безобразно, но однообразно). |
|
14-02-2007 08:40Мы в конторе утвердили
begin
if _condition_
then begin
_operator1_;
_operator2_;
end
else begin
_operator3_;
_operator4_;
end;
if _condition_
then _operator1_
else _operator2_;
case _swith_ of
_value1_: begin
_operator1_;
_operator2_;
end;
_value2_: begin
_operator3_;
_operator4_;
end;
else begin
_operator5_;
_operator6_;
end;
end;
end;
Условие, переходы, конец видно, а операторные скобки - побоку.
Но сначала новички знакомятся с этой статьей. |
|
14-02-2007 04:55А мне за
if a < b then begin
просто хочется убить того, кто написал. Окажись в одном месте куча коротких операторных блоков и разобрать там уже ничего нельзя. Целесообразно только в коротких функциях вида:
procedure Proc(c:Boolean);
begin
if b then begin
DoThis;
DoThat;
end;
DoSomthingBeforeExit;
end
вообще жаль что Borland не перенял у оберона такую полезную штуку, как полный отказ от begin - сделали бы любой оператор комбинированым:
По-моему Оберон это полная ахинея и за отсутствие операторных блоков (пары begin end читаются лучше) и за регистрозависимость, которая убивает любой язык. Pascal вершина Pascal-подобных языков.
А вот ключевое слово endcase, для case жизнь бы упростило сильно.
Вот с этим совершенно не согласен:
procedure SomeProcedure;
type
TMyType = Integer;
const
ArraySize = 100;
var
MyArray: array [1..ArraySize] of TMyType;
begin
...
end;
Где гарантия, что мне не нужен тип на базе ArraySize? |
|
09-11-2003 06:22А мне нравится такой вариант :
if a > b then begin
c := a;
end else begin
c := b;
end;
В этом случае сточка end else begin воспринимается как единое целое. Как разделить условия на две части. Первая часть - если условие выполняется, вторая если нет.
Какой смысл переносить бегин на отдельную стрчоку я не понимаю.
|
|
14-09-2003 14:54В основном правильно. Но до полной правильности необходимо придерживаться следующих правил:
1. Имена локальных переменных и параметров должны начинаться с неопределенного артикля a(an).
Это позволит избежать кучи ошибок, связанных с совпадением имен локальных переменных и членов класса. Так было в TP, и непонятно, почему Борланды отошли от этого правила в Delphi.
Пример:
procedure TMyClass.Proc1(aP1: Integer);
2. Если тело операторов if, while является составным оператором, слово begin следует писать на той же строке, что и if, while.
Пример:
if a < b then begin
...
end
else begin
...
end;
Такой код ближе к языку Modula2, который, с точки зрения структурирования, предпочтительнее паскаля.
3. В случае, когда условное выражение операторов if,while слишком длинное, следует форматировать его следующим образом:
if ... длинное условие ...
... продолжение длинного условия ...
then
...;
То есть then пишется на том же уровне, что и if.
4. Не допускается использование пробелов для отступов. Только TAB.
Кто-то любит большие отступы, кто-то короткие.
Единственный способ примирить всех - это использовать TAB.
5. Что касается вопросов отбивки знаков препинания пробелами,
то вместо того, чтобы приводить кучу примеров, можно было
просто обозначить несколько простых правил:
5.1. Перед скобками "(", "[" пробел ставится всегда, после - никогда.
5.2. Перед скобками ")", "]" пробел не ставится никогда, после - всегда.
5.3. Перед и после "." пробелы не ставятся.
5.4. Все операторы "=", ":=", "+", "-", "or" и т.п. отбиваются пробелами и слева и справа.
5.5. Все остальные знаки препинания (":", ";", ...) оформляются следующим образом:
Перед ними пробела нет, после них - пробел ставится.
---
В остальном - все правильно.
---
С уважением,
Михаил Власов,
http://mv.rb.ru
|
|
10-06-2003 15:02В принципе я согласен с Чарльзом Калвертом. Вот только уж слишком категорично "...это нельзя... ...это ни в коем случае нельзя...".
Я например очень люблю именовать переменные цикла символами в нижнем регистре, например:
SomeArray[i]
смотрится куда как приятнее чем
SomeArray[I]
к тому же в последнем случае приходится тянуться к клавише Shift, а это иногда просто достает!
Считаю вполне допустимыми небольшие отступления, направленные на компактификацию кода, что-то вроде:
if ... then begin
end else begin
end;
while ... do begin
end;
и еще несколько незначительных отличий,
касающихся именования констант.
А в общем и целом нахожу рекомендации, приведенные в статье, полезными и нужными.Сообщение не подписано |
|
06-06-2003 18:01На мой взгляд, все таки, при построении структур типа if, for, while и т.п. более наглядно если begin разполагается на одной строке со структурным выражением, т.е.:
if (условие) then begin
...
...
while (условие) do begin
...
...
end
if () then begin
...
...
end
else if () then begin
...
...
end
else begin
...
...
end;
end;
|
|
06-06-2003 15:52мне не нравятся такие if...then. пользуюсь более читабельной (по-моему) консткрукцией. где-то такой.
if (условие)
or
(условие)
or
(условие)
then
begin
end
else
begin
end;
примерно, конечно. оно длинее выходит, но структурнее и главное, что одинаково во всех случаяхи (и в сложных, и в простейших). взгляд цепляется намного бырее.
|
|
06-06-2003 14:20Хорошо стилизованый код ... очень помогает. Я долго маялся пока не нашел эксперт для Делфи, который за меня форматирует :о)
Правильно говорять: Програмисты народ ленивый :о) |
|
06-06-2003 14:20придерживаться стандартов полезно и нужно. Затраты времени на придержание оформления около стандарта, несравнимо меньше чем экономия времени при последующем чтении кода.
Вопрос конечно остается относительно конкретного стандарта, что
есть стандарт. Но то что описано в данной статье, я принимаю
довольно легко потому как сам долго шел к такому стилю. В любом случае, я не думаю что, то что там описано не имеет под собой
исследований в области психологического восприятия и технических приемов и особенностей кодирования.
Если вы хоть когда нибудь в команде или даже самостоятельно писали серьезный проект с сотнями модулей и несколькими миллионами строк исходного кода и который находился в постоянном развитии то недооценивать полезность стандартов вы не станете. Стандартный подход в оформлении кода очень сильно упрошает разработку, отладку, работу над ошибками и т.д.
Я например очень часто натравливаю JediCodeFormat на исходные коды некоторых писателей, в которых без 100 грамм не разберешся... И сразу все станивится на свои места...
Я посмотрел бы как бы свободный программист "Viktor" читал бы MSDN или любой технический справочник если бы в нем была написана каша понятная только писателю MSDN.
Порядок во внутреннем коде программы, это как порядок на рабочем столе, порядок в голове и т д. Для меня внутренний порядок стоит на первом месте, за которым идет внешний. И без разницы это телевизор
скрытая в стенах проводка, канализация, вентиляция и т д. Внутренняя инженерия также важна, как и внешняя.
2 Victor - утилита для форматирования кода в дельфи это JediCodeFormat поставляется в исходных кодах.
|
|
06-06-2003 13:27| Похоже что автор ввел эти правила для конкретной группы разработчиков, но потом зачем то решил выложить в сеть. Маловато к тому же. Например если уж он собирается с ходу понимать чужой код, то он должен был подробно расписать как обзывать комоненты, да и процедуры. Вообще методы именования. А то кто в лес кто по дрова и сиди разбирайся. Да вообще материал слабоват, очевидные вещи расписываются как открытие в программировании. |
|
06-06-2003 12:37>>>>>>При разработке ПО написании кода внимание направлено на решение задачи а не на художественное оформление.
>>>Только в том случае, если Ваш код никто кроме Вас никогда читать не будет
Dobavlu - i v sluchae esli Vi sami chitat etot kod ne sobiraetes.
Vot mne seychas prixoditsa razbiratsa s chujim kodom - kak vam nazvaniya funkciy vrode AL1 ili RRL
|
|
06-06-2003 11:45| Кстати Пачеко и Тейксейра в своем талмуде описывают вариант, о котором говорил Magic. |
|
06-06-2003 11:18>>>При разработке ПО написании кода внимание направлено на решение задачи а не на художественное оформление.
Только в том случае, если Ваш код никто кроме Вас никогда читать не будет. |
|
06-06-2003 11:17>При разработке ПО написании кода внимание направлено на решение задачи а не на художественное оформление.
Одно другому не мешает. Уметь разводить костёр руками и пользоваться спичками - это разные вещи. |
|
06-06-2003 10:05Программисты существа ленивые иначе они не были бы программистами.
Никто не заставит программиста придерживатся стандартов !!!!
МЫ СВОБОДНЫЕ ЛЮДИ !!!! ПРОГРАММИСТЫ !!!!!
При разработке ПО написании кода внимание направлено на решение задачи а не на художественное оформление.
Для предания исходному коду читабельного вида нужно применять соответствующее ПО пусть чорную работу выполняет компьютер (возможно вы помните прекраный документатор кода из пакета СУБД FOXPRO, FOXDOC). Мне так и не удалось разыскать что-то подобное для DELPHI.
|
|
06-06-2003 07:48В дополнение.
Стандарты принятые разработчиками Indy:
http://www.indyproject.org/Teams/Core/Standards/index.html
Они отличаются в паре мелких мест + дополнены и "устрожены"
Например,
if x then
begin
end
else
begin
end
ИЛИ
if x then
else
Надо писать как:
if x then begin
end
else begin
end
=>
1) компактно
2) нельзя допустить ошибку написав 2 оператора в if then без begin
PS: вообще жаль что Borland не перенял у оберона такую полезную штуку, как полный отказ от begin - сделали бы любой оператор комбинированым:
while x do
a;
b;
end;
PPS:
Кода Виктор
С/C++ регистрозависимый язык, отсюда невозможность практического применения данного стандарта, слишком лекго ошибиться. вот и ввели они пару простых правил: THIS_IS_CONST, del_me_please
кроме того после изучения и настройки code complete, код пишется нажатиями 3-4 клавиш
b^J =>
begin
end |
|
05-06-2003 22:52Вообще страшно спорный вопрос. Стандарт нужен, но только в основном только в своей конторе. Я, например, именую все модули только с маленькой буквы:
e_octc.pas
А функции мне больше нравится писать так:
function G_TraceRay( const poly: array of vec3_t; const s, e: vec3_t ): boolean;
Насчёт if-then тоже смотря как. Бывает, так заморачиваешься делать эти отступы - код становится некомпактным, рыхлым. Иногда можно написать и так:
if void( param ) then exit;
param^ := Tex_GetID( id );
Не вижу причин для плохой читабельности. В общем же случае, конечно, надо делать отступы.
Или вот begin-end - всё-таки {} в С компактнее - многие древние языки программирования страдали тем, что там повсеместно использовались длинные операторы в виде осмысленных слов. В OP эти рудименты остались в виде begin-end, not, and, label.
Пишу так:
if ... then
begin
...
...
end else
begin
...
...
end;
А на С компактнее:
if ()
{
...
...
} else
{
...
...
}
Насчёт имён идентификаторов - тут тоже о-о-очень спорный вопрос. Многие суперпрофессиональные программисты не используют MyVariable, а используют myvariable или ещё что-то такое. Например, можно посмотреть исходный код игр Quake I-II - там от Кармака всё в таком духе, какое там MyVariable! Сначала я этот стиль не принял, но теперь вижу, что если не перебарщивать с numuserclipplanes а писать numuser_clipplanes, то всё после небольшой практики вполне читабельно, а код не пестрит вершинами заглавных букв. Да возьмите хотя-бы обычный текст, хоть из этого моего сообщения - разве Пишу Я Вот Таким Стилем, Может Быть Всё-Таки писать вот таким, привычным?
Стиль - дело вкуса, но стандарт, независимо от стиля, среди группы програмистов конечно же, должен быть обязательно. Под конец скажу что стиль форматирования кода, приведённый в статье, вполне неплох, его правила действительно направлены только на лёгкое чтение последнего, но иногда программистам не нравится слишком рыхлый код (как мне), который присущ такому стилю.
|
|
05-06-2003 19:01
05-06-2003 18:27| А в VCL кое где не так форматировано :-))) |
|
|
|
