в продолжении темы профи/не профи...

← →
vecna © (2004-12-22 01:14) [0]

вот почитал http://delphimaster.net/view/14-1103614248/ и решил посмотреть какой же код пишут уважаемые и признанные профессионалы этого форума. Всем советую - очень интересно! =)

Скажу честно - я был разочарован, посмотрев первый попавшийся вариант. мне не понравился код по целому ряду критериев, как исключительно субъективных, так и вполне объективных, мне не понравился неправльный пользовательский дизайн, мне не понравилась общая разнородность кода. Я бы не стал выкладывать такой код на всеобщее обозрение.

← →
Cobalt © (2004-12-22 02:57) [1]

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

← →
Gero © (2004-12-22 03:02) [2]

> И кого же это ты называаешь
> > уважаемые и признанные профессионалы этого форума

Димой зовут.

← →
KilkennyCat © (2004-12-22 04:53) [3]

мда... все-таки непонятно, че вам неймется? Запомните простую вещь: профессионал знает, что он - профессионал, и спорить не будет. Непрофессионалы, которые осознают, что они непрофессионалы - на самом деле уже 99% профи.
А остальные, готовые глотку рвать, но доказать всем и вся (а наверное, себе в первую очередь) свою профи - ламерами были, ламерами и останутся.

← →
VMcL © (2004-12-22 07:55) [4]

>>Gero © (22.12.04 03:02) [2]

Точно, точно, припоминаю, Олегович, вроде...

← →
vecna © (2004-12-22 10:09) [5]

спокойствие...
я вас уверею, что человек действительно является профи по всеобщему признанию сообщества этого форума (и моему в том числе). Мне бы не хотелось называть имен, потому что потом это уже будет выглядеть как претензия, которую необходимо обосновать, чего я делать не хочу. Благо примеров кода "отцов программирования" (это сказано даже без намека на какую-нить иронию) в сети достаточно, каждый может откопать и посмотреть...
А начал я это все к тому, что выкладывая свой код, следует привести его в порядок, т.к. по нему учатся дети =)

зы. естествно, я сначала хотел привести конкретные примеры, когда завел ветку... мне не понравилось например следующее:
1. Антипользовательский дизайн - очень емкое понятие, состоящие из целого ряда факторов, которые очевидны.
2. Неоправдованное использование лишних локальных переменных.
3. Строковые константы в теле кода. Для тех кто сомневается - строки должны быть в dfm"е, в ресурсах или базе, в противном случае имеем гемморой при переводе программы на любой другой язык.
4. использование портянок типа
SomeObject.SomeProperty.SomeMethodName1
SomeObject.SomeProperty.SomeMethodName2
...
SomeObject.SomeProperty.SomeMethodNameN
и не нада меня лечить, что оптимизатор умный - сделает хороший код.
5. Названия переменных по которым трудно догадаться для чего нужна переменная.
6. Ненужна явная инициализация локальных переменых, типа
procedure SomeProc;
var
z: String;
begin
z := "";
...
end;

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

вот.

← →
Плохиш © (2004-12-22 10:20) [6]

Озабоченные дети, вам не надоело, делом бы занялись что-ли или фунбол погоняли.

PS. Это он Борланд имеет ввиду ;-)

← →
DVM © (2004-12-22 10:26) [7]

> 1. Антипользовательский дизайн - очень емкое понятие, состоящие
> из целого ряда факторов, которые очевидны.

конкретнее?

> Неоправдованное использование лишних локальных переменных.

кому мешают?

> Строковые константы в теле кода

согласен

> Названия переменных по которым трудно догадаться для чего
> нужна переменная.

предрассудки

> Ненужна явная инициализация локальных переменых, типа

лучше перестраховаться

← →
ocean (2004-12-22 10:26) [8]

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

← →
Val © (2004-12-22 10:32) [9]

Относительно это все :)
Вот те же строки - да, умно написали и правильно. Но зачем я буду их выносить куда-то, если мне не надо будет _никогда_ переводить программу и у меня их(строк) три штуки?

← →
vecna © (2004-12-22 10:37) [10]

2DVM
>конкретнее?
Разные размеры кнопок, разные шрифиы, причем огромные и видимо(не смотрел) нестандартные (не MS Sans Serif). Неправильные отступы (либо большие, либо их вообще нет), текст TLabel"a невлезающий в отведенный регион. Сейчас уже жалею что не посмотрел на TabOrder, если и там не правильно, то уж извините...

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

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

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

← →
TUser © (2004-12-22 10:39) [11]

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

← →
Sandman25 © (2004-12-22 10:51) [12]

[10] vecna © (22.12.04 10:37)

Если не хотите явно инициализировать локальную переменную, объявите ее AnsiString. Я поднимал на форуме ветку по этому поводу и наилучшим советом был именно этот.

← →
y-soft © (2004-12-22 10:55) [13]

>vecna © (22.12.04 10:37) [10]

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

Ой, не всегда компилятор гарантирует, особенно в ранних версиях Delphi :(

← →
msguns © (2004-12-22 11:03) [14]

>1. Антипользовательский дизайн - очень емкое понятие, состоящие из целого ряда факторов, которые очевидны.

Очевидны для кого ?

>2. Неоправдованное использование лишних локальных переменных.

Кто определяет "лишность" и " неоправданность" ? Хотя нагромождение всяких i1,i2,i3,... и т.д., безусловно, засоряет код, делая его трудночитаемым

>3. Строковые константы в теле кода. Для тех кто сомневается - строки должны быть в dfm"е, в ресурсах или базе, в противном случае имеем гемморой при переводе программы на любой другой язык.

Ну если мы так круты, что пишем все свои программы в расчете на "росповсюдження" по всему свету, то да. По мне проще прочитать выводимые при выполнении тексты и надписи в самом коде, чем лазить по ресурсам.

>4. использование портянок типа
SomeObject.SomeProperty.SomeMethodName1
SomeObject.SomeProperty.SomeMethodName2
...
SomeObject.SomeProperty.SomeMethodNameN
и не нада меня лечить, что оптимизатор умный - сделает хороший код.

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

>5. Названия переменных по которым трудно догадаться для чего нужна переменная.

Без возражений.

>6. Ненужна явная инициализация локальных переменых

Категорически не согласен ! Наверное потому, что старый ассемблерщик и привык полученный пул памяти чистить, несмотря на то, что многие ОС делают это при аллокэйте. С т.зр. скорости затраты ничтожные, а польза в том, что делают логику прозрачнее.

← →
Плохиш © (2004-12-22 11:37) [15]

>ocean (22.12.04 10:26) [8]
>говорят, в добрые старые времена "профессионалы" набирали
>программу "кирпичом" (т.е без пробелов и с переводом строки не
>раньше 80-й позиции)

Говорят, в Москве кур доят.

← →
Anatoly Podgoretsky © (2004-12-22 11:38) [16]

vecna © (22.12.04 10:09) [5]
Ну тут могут быть разные причины, например
1. старый код, который не трогается даже при переносе на новую версию Дельфи.
2. Его методика, к который он привык, давно программирует, может в новых проектах делает уже по другому.
3. Лишняя перестраховка
и многое другое.

1. Антипользовательский дизайн
Ну это вообще не программирование, это другая профессия, которую должен делать совсем другой человек.

2. Неоправдованное использование лишних локальных переменных.
Без кода трудно говорить, оправдано или нет.

3. Строковые константы в теле кода.
Не так важно, кроме того например ресурсные строки не всегда были в Дельфи. Константы конечно были. Кстати Дельфи неплохо оптимизирует поторяющие текстовые константы. В общем не существенно, особенно для одноразовых проектов или для одноразовых констант.

4. использование портянок типа
Вопрос спорный и зависит от кода, я например по разному делаю, где отдельная переменная, где with (редко), где такое вот повторения. Все в зависимости от ситуации.

5. Названия переменных по которым трудно догадаться для чего нужна переменная.
Вот это плохо.

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

← →
vecna © (2004-12-22 11:40) [17]

Sandman25 [12]
я всегда думал String и AnsiString - одно и тоже, если нет $H.

y-soft [13]
Возможно, я не работал с версиями младше 5, поэтому не могу ничего сказать.

msguns [14]
снова, говорим про профессиональный код. это к 1 и 2. Примеры в [10]

> огульно критиковать по одному обрывку кода.. не вникая в контекст..

какой еще контекст?
процедура стотоит только из указанных строк:
pricedure SomeProc;
begin
SomeObject.SomeProperty.SomeMethodName1;
...
SomeObject.SomeProperty.SomeMethodNameN;
end;

> Категорически не согласен !
Я тоже долго и много писал на ассемблере, но не стоит переносить привычки из одной среды в другую, особенно если они различны. Конекретный пример, будучи гуру в MS SQL Server"е нельзя оставаться верным принципам при переходе например в Oracle. И это касается любой среды. Необходимо знать, учитывать и уметь пользоваться спецификой в каждом конкретном случае, или я не понимаю что вы вкладываете в слово "профессионал".

← →
Игорь Шевченко © (2004-12-22 11:43) [18]

> 3. Строковые константы в теле кода. Для тех кто сомневается
> - строки должны быть в dfm"е, в ресурсах или базе, в противном
> случае имеем гемморой при переводе программы на любой другой
> язык.

Всякий овощ приносит пользу, будучи употреблен надлежащим образом в надлежащее время. Пуристам настоятельно рекомендую читать Program Files\Borland\Delphi\Demos\*.*

С уважением,

← →
vecna © (2004-12-22 11:48) [19]

2Anatoly Podgoretsky

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

← →
Sandman25 © (2004-12-22 11:50) [20]

[17] vecna © (22.12.04 11:40)

Sandman25 [12]
я всегда думал String и AnsiString - одно и тоже, если нет $H.

Именно так. И чтобы у программиста, использующего Ваш код, не появились непонятные проблемы после добавления такой директивы, следует отвязаться от директив и явно прописать AnsiString.

← →
Суслик © (2004-12-22 11:52) [21]

Работающий код - необходимое условие профи.

Красивый код - ни необходимое, ни достаточное.

Я всегда исхожу из первого - даже есть код страшен как смерть.

← →
DiamondShark © (2004-12-22 11:54) [22]

> 3. Строковые константы в теле кода. Для тех кто сомневается
> - строки должны быть в dfm"е, в ресурсах или базе, в противном
> случае имеем гемморой при переводе программы на любой другой
> язык.

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

Ты же конкретный код не приводишь. А общего вида рассуждения можно до морковкиного заговения вести...

← →
vecna © (2004-12-22 11:58) [23]

2 Игорь Шевченко

Demos - демонстрируют примеры использования технологий, а не то как нада писать на самом деле, и не могут служит примером качественного кода. Там даже не всегда try..finally стоит в тех местах где это нужно.

← →
Игорь Шевченко © (2004-12-22 12:19) [24]

vecna © (22.12.04 11:58) [23]

Марксизм не догма, а руководство к действию.

> Там даже не всегда try..finally стоит в тех местах где это
> нужно.

Обычно к такого рода фразам приводят примеры, иллюстрирующие сказанное.

С уважением,

← →
Суслик © (2004-12-22 12:25) [25]

> try..finally

В легких, небольших, учебных приложениях потребность в такой конструкции вообще редка. Зачастую в случае ошибки продолжение вообще работать дальше не может - не имеет смысла.

Может в этом и крутость - не делать заведомо лишних вещей?

← →
vecna © (2004-12-22 12:28) [26]

2Игорь Шевченко

ну вот например...
Db\MastApp\Main.pas

procedure TMainForm.UpdateRSConnect(const Dbpath: string);
...
var
...
RSCON: TIniFile;
begin
RSCon := TIniFile.Create(TiniFilename);
TempStr := RSCon.ReadString(...);
...
RSCon.Free;
end;

← →
stone © (2004-12-22 12:33) [27]

> vecna © (22.12.04 12:28) [26]

ИМХО, там не может возникнуть исключение, поэтому RSCon.Free; произойдет в любом случае. Следовательно конструкция try..finally не обязательна.

← →
vecna © (2004-12-22 12:45) [28]

2stone

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

← →
Sandman25 © (2004-12-22 12:47) [29]

[27] stone © (22.12.04 12:33)

Была бы Java, сразу было бы видно, может ли ReadString бросить исключение, а так приходится знать реализацию метода. И при изменении этой реализации (добавление исключения) могут возникнуть проблемы.

← →
Anatoly Podgoretsky © (2004-12-22 12:53) [30]

Это как не не может, путь для возникновения исключения здесь большое количество, даже без кода в точках.

← →
Игорь Шевченко © (2004-12-22 12:54) [31]

Sandman25 © (22.12.04 12:47) [29]

> И при изменении этой реализации (добавление исключения)
> могут возникнуть проблемы.

Был у меня знакомый, написал один раз такой код:
var
a: Byte;
begin
a := 0;
a := SomeParameter.SomeFunction (SomeFunctionParameter);
....
end;

В ответ на вопрос, зачем два раза присваивать, он сказал: а вдруг второй раз не присвоится, так хоть нулем будет переменная заполнена.

С уважением,

← →
Алхимик © (2004-12-22 12:56) [32]

> [31] Игорь Шевченко © (22.12.04 12:54)

Если функция из сомнительной библитотеки, то оправдано.

← →
Игорь Шевченко © (2004-12-22 12:59) [33]

Алхимик © (22.12.04 12:56) [32]

:)

> Вы можете обосновать, почему исключения не возникнет, для
> меня, если честно, это не очевидно ?

В этой процедуре кроме записи(+ 1 случай чтения) в ini-файл я не вижу. Поэтому для меня большой вопрос откуда здесь может взяться исключение, которое не позволит выполнить RSCon.Free;

[31] Игорь Шевченко © (22.12.04 12:54)

Дело не в сомнительности библиотеки. Дело в том, что при переходе на более новую версию Delphi может быть изменен код ReadString.
Если реализацию метода пишу я (или хотя бы моя компания), я могу не писать ненужные проверки. Но если это сторонняя разработка, то можно и подстраховаться, чтобы не пришлось переделывать кучу кода.
Указанный в примере код для Borland является внутренней разработкой, поэтому они проверки и не использовали. Но не думаю, что они рекомендуют поступать точно так же тем, кто не работает в Borland, то есть тем, для кого это будет "внешняя" разработка.

>DiamondShark © (22.12.04 13:43) [37]
>Тогда принцип очень простой: исключение может возникнуть везде.

Вот именно. Но некоторые этого не понимают...:) (или делают вид)

[37] DiamondShark © (22.12.04 13:43)

Примерно так. Точнее, если созданный объект не удаляется сразу же. Замедлением пренебрегаем. Безопасность и однообразие стиля налицо.

[38] Johnmen © (22.12.04 13:45)

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

>Sandman25 © (22.12.04 13:50) [40]

Не только в твой, но это не камень :)
Просто надо здраво относится к применяемым не своим методам.
В данном случае, думаю, это Sandman25 © (22.12.04 13:37) [36]
есть признак некоторой "догматичности"...

[42] Johnmen © (22.12.04 13:59)

Понятно.
Но если ты помнишь, с чего это всё началось, то Java в этом отношении всё равно лучше. Вот такая у меня "догма" :)

Суслик © (04.12.22 11:52) [21]
категорически не согласен.
работающий код может написать кто угодно. я видел просто ужаснейшие куски кода, которые, тем не менее, прекрасно работали. разумеется, до того момента, когда надо "слегка" изменить функциональность кода. вот тогда это превращается в кошмар.

вообще, следует определиться с терминами. ибо значение слова профессионал - это человек, получающий деньги за свою работу. т.е. работающий по профессии.

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

итак, плохой код для меня - это код:
1. в котором есть повторяющиеся (полностью или с незначительными изменениями) куски;
2. который сложно понять без дополнительных описаний (сюда входят и названия функций/переменных);
3. в котором есть ненужная (читать: невостребованная) функциональность.

> Sandman25 © (22.12.04 14:04) [43]

Это ты про декларацию исключений, как части интерфейса?

Ну, так в аналогичной ситуации это ничем не поможет (не надо про сборщик мусора).

[46] DiamondShark © (22.12.04 14:45)

Если описано TIniFile.ReadString throws Exception, то я буду писать
with TIniFile.Create(...) do
try
ReadString...
finally
Free
end;
если throws не написано, я буду писать
with TIniFile.Create(...) do
begin
ReadString...
Free
end;

А без throws в синтаксисе Delphi я вынужден сам решать, какую конструкцию использовать. Причем, в первом случае я бессмысленно замедляю работу, во втором - рискую нарваться на неприятности в будущем.

> Sandman25 © (22.12.04 14:54) [47]

Так в том-то и дело, что ни декларация ни отсутсвие декларации исключений не заставляет использовать ни первую ни вторую конструкцию.

Декларация только ограничивает передачу исключений вверх. Иными словами, декларация может заставить тебя писать блок except, но никак не finally.

в продолжении темы профи/не профи... Найти похожие ветки