Ответ на »сообщение 386« (Geo)
___________________________
я собственно на таком языке и программирую :) (Где всё инициализируется неявно)

Ответ на »сообщение 384« (Max Belugin)
___________________________
>>> А в дельфи мало того что есть переменная, так еще и ее состояние неопределено и по умалчанию там мусор
Ну, никто не запрещает программировать на VB, где переменная любого типа заведомо инициализирована заведомо известно каким значением. А я как-то уже давно перестал допускать ошибки, обусловленные забывчивостью в отношении инициализации переменных.

Кстати, вспомнилась старая хохма:
Настоящие програмимисты не пишут на Паскале. Строгая типизация данных -- для людей со слаборй памятью.

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

P.S. Для особо серьезеых людй замечу, что каждый из двух предыдущих абзацев неявно заканчивается смайиликом ;-)

Ответ на »сообщение 383« (panda)
___________________________
Как это может объяснить высказывание Сергея Рощина В контексте сообщения шла речь о подавлении Warning`ов. Так что лучше пусть будет одна лишняя строка, которая компилятором всё равно игнорируется, чем опастность нажить себе неприятность!

Ответ на »сообщение 383« (panda)
___________________________
в C# нет никакого возвращаемого значения по умолчанию. Если ничего явно не возвращать, то код просто не скомпилируется. Соответственно нет такого типа ошибок. А в дельфи мало того что есть переменная, так еще и ее состояние неопределено и по умалчанию там мусор. Который в частом конкретном случае 0 но в военное время может достикать PI

Ответ на »сообщение 382« (Max Belugin)
___________________________

Ну и? Delphi тоже такие фокусы знает:
[Warning] Unit1.pas(31): Return value of function 'TForm1.A' might be undefined

Как это может объяснить высказывание Сергея Рощина: "Есть такая неприятная особенность, что если не проинициализировать function XXX:integer то чаще всего результат будет 0 и это вполне логично и на этапе отладки будет правильно, а на какой-нибудь десятый раз у пользователя в Магадане там будет нечто иное." ?

Ответ на »сообщение 380« (panda)
___________________________
в С++ и Java такое поведение и в магадане и в африке.... так что ловится на этапе компиляции (жабы под рукой нет нет, в C#

test.cs(3,14): error CS0161: 'MainClass.a(int)': не все ветви кода возвращают значение )

Ответ на »сообщение 378« (panda)
___________________________

А кто-нибудь нарвется, используя булевские типы не по назначению.

Хм, что-то в этом есть... :-)

Ответ на »сообщение 379« (Cepгей Poщин)
___________________________

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

Меня знаете, что смущает в этой логике: как же в Магадане при этом работаю программы на C++ или Java? Там ведь пока return не скажешь, результат не присвоится.

Ответ на »сообщение 373« (Ins)
___________________________
Так и поступаю, использую директивы {$WARNINGS ON} и {$WARNINGS OFF} Но короче и нагладнее проинициализировать в начале result, кроме того есть вероятность, что {$WARNINGS ON} по ходу дальнейших исправлений потеряется, и предупреждения перестанут появлятся вообще.
Многие привыкают присваивать в начале функции значение Result. Вот именно. Мало ли что там в будущем в условиях можно наворотить. Есть такая неприятная особенность, что если не проинициализировать function XXX:integer то чаще всего результат будет 0 и это вполне логично и на этапе отладки будет правильно, а на какой-нибудь десятый раз у пользователя в Магадане там будет нечто иное. Дальше можно размышлять долгими полярными ночами о теории, практике и красивом коде :-)

Ответ на »сообщение 373« (Ins)
___________________________

Ага, честно. В том то и дело, что ну никак не нарвемся! :)
Так это Вы не нарветесь. А кто-нибудь нарвется, используя булевские типы не по назначению. Например, так:

  ShowMessageFmt('%d', [Ord(False)]);
  ShowMessageFmt('%d', [Ord(True)]);
  B := Boolean(2);
  ShowMessageFmt('%d', [Ord(B)]);

По моему Ins прав. Многие привыкают присваивать в начале функции значение Result. Во многих случаях это правильный стиль. Поэтому в приведенном выражденном случае делают присвоение автоматически.
Действие по шаблону. Не слишком подходящему в данном случае, но в принципе правильному.

Ответ на »сообщение 375« (Geniepro)
___________________________
>>> Если бы этот программист хоть немного поработал на функциональных языках и привык к тому, что повторно присвоить значение переменной нельзя <...>
Интересный момент. Я на функциональных языках не работад (Excel не в счет). Естественно, я привык иногда загонять в переменную промежуточные расчеты (для лучшей читаемости кода и, возможно, для поиска глюков при отладке). Однако такой способ реализации функции и у меня вызывает отторжение.

Не убедительно ;-)

Ответ на »сообщение 366« (Geo)
___________________________

Почему же чаще встречается первый вариант? Кто-нибудь задумывался над таким вопросом?

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

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

:о))

Ответ на »сообщение 373« (Ins)
___________________________
>>> В том то и дело, что ну никак не нарвемся! :)
Компилятор, как я понимаю, выдает свой варнинг исходя из того, что инициализация переменной Result происходит в операторе case, в котором нет раздела else. Соответственно, при таком подходе можно упустить какой-либо вариант. Вычислением логических выражение и определением их полноты компилятор не занимается.

Честно говоря, меня это устраивает. Пусть он проверяет синтаксис и быстро компилирует это дело в EXE. А смыслом получившегося кода я займусь сам. А если представить себе противоположное... Компилятор, который работает два часа, чтобы в конце концов определить, что такая-то потенциальная ошибка на самом деле в данной программе никогда не наступит ;-)

Ответ на »сообщение 372« (Geo)
___________________________

Компилятор просто честно и благородно предупреждает, что можем нарваться.
Ага, честно. В том то и дело, что ну никак не нарвемся! :)

А те, кому это давит на нервы, могут варнинги отключить ;-)

О, это как раз про меня! ;)
Так и поступаю, использую директивы {$WARNINGS ON} и {$WARNINGS OFF}

Ответ на »сообщение 371« (Ins)
___________________________
А что плохого в этом варнинге? Компилятор просто честно и благородно предупреждает, что можем нарваться. Он (в отличие от программиста) не может понять, что третьего не дано ;-) А работе программы наличие варнинга при компиляции, насколько мне известно, ничуть не мешает.

А те, кому это давит на нервы, могут варнинги отключить ;-)

Кстати, очень неприятно, что Delphi выдает
[Warning] Unit1.pas(31): Return value of function 'Max' might be undefined
на такую конструкцию

function Max(a, b: Integer): Integer;
begin
  case a > b of
    true: Result:=a;
    false: Result:=b;
  end;
end;

То же самое будет с другими перечислимыми типами, все значения которых можно перечислить в одном case. Приходиться либо использовать описанный Geo прием, либо вставлять в case..end else, что мне кажется не менее неестественным.

Ответ на »сообщение 367« (Антон Григорьев)
___________________________
>>> А вообще - как-то мало я с чужим кодом работаю...
Ну, я такое достаточно часто встречал, изучая примеры на VBA (Excel, Access). Будем считать, что это еще одна диверсия Микрософта против устоявшейся культуры программирования ;-)

Ответ на »сообщение 368« (Ins)
___________________________
>>> А я первый вариант использую часто <...>
Это совсем другой случай. Задаем одно значение и потом проверяем все условия выхода с этим значением. Если не вывалились и дошли до конца, значит реультат прямо пртивоположный. Там это оправданная методика, позволяющая сделать код более читаемым. Я же говорю про абсолютно симметричный случай из двух вариантов. Будем считать, что виновата привычка ;-)

Ответ на »сообщение 369« (panda)
___________________________
>>> Потому что Вы плохо отстреливаете тех, кто так пишет ;)
И чем я их буду отстреливать? МБР что ли? Никакое другое оружие просто не дострелит до США и не сможет поразить программистов Микрософта ;-)

Господа, спасибо! Вы меня успокоили. А то я уже волноваться начал, что я такой дурак и не понимаю таких простых вещей. Оказалось, что дурак все же не я :-D

Ответ на »сообщение 366« (Geo)
___________________________

Почему же чаще встречается первый вариант?
Потому что Вы плохо отстреливаете тех, кто так пишет ;)
Я вот хорошо отстреливаю, поэтому мне обычно второй вариант показывают :)

А я первый вариант использую часто. Только немного не в таком виде. Допустим есть функция, которая выполняет какие-либо действия и возвращает true, если все прошло хорошо и false, если где-то по дороге произошел сбой.

function SomeFunc: Boolean;
begin
  Result:=false;
  {далее идет сложный алгоритм, построенный либо на if-then, либо на обработке исключений, и когда мы добираемся до конца алгоритма - выставляем Result:=true}
end;

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

Ответ на »сообщение 366« (Geo)
___________________________

Во втором варианте, вроде бы, при выполнении получается на один оператор меньше. Почему же чаще встречается первый вариант? Кто-нибудь задумывался над таким вопросом?

Может быть, потому, что на одно слово "else" меньше? Набирать быстрее ;)

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

Захотелось мне что-то потрепаться (побазарить ;-)) на околопрограммные темы. А заодно и тему поднять. А посему предлагаю на обсуждение вопрос.

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

function Max(N1,N2 : Integer) : Integer;
begin
  Result:=N1;
  if N2 > N1
  then
    Result:=N2;
end;

Хотя мене более естественным кажется такой код:

function Max(N1,N2 : Integer) : Integer;
begin
  if N2 > N1
  then
    Result:=N2
  else
    Result:=N1;
end;

Во втором варианте, вроде бы, при выполнении получается на один оператор меньше. Почему же чаще встречается первый вариант? Кто-нибудь задумывался над таким вопросом?

К вопросу об оптимизациии- рекомендую посетить сайт
http://www.fastcode.dk/fastcodeproject/fastcodeproject/index.htm
функции и memory manager котрые там реализованы войдут в RTL Delphi 2006 (Dexter)

Родной сайт Fowler'а хорош еще юмором. Например, выдержки из некоторых
описаний инструментов рефакторинга.
Smalltalk ... To all those who think that PhD projects are doomed to irrelevance.
IntelliJ Idea  This is a fully fledged IDE.  (Все-таки птичник!)
Together-J  ... Recently bought by Borland (or whatever they call themselves these days)
Bicycle Repair Man  This at least gets a prize for the best name!

Жаль, что в X-develop не упоминается Паскаль.

Ответ на »сообщение 362« (Как слышно? Прием!)
___________________________
>>>С появлением объектной технологии ... появилось большое количество плохо
спроектированных, неэффективных и малопригодных к сопровождению и расширению приложений.
Да, припечатал. Разумеется в дообъектную эпоху таких приложений не было :)

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

Забавная реклама рефакторинга с уничижительной антирекламой ООП:

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

Как говорится, что у трезвого на уме, то у рекламщика на языке.

Ответ на »сообщение 359« (Как слышно? Прием!)
___________________________

Ссылочку по рефакторингу лучше было дать на
www.refactoring.com , чем на магазин книжки.

Что-то я там не нашел текста книги на русском языке. Плохо искал?
И бумажная книга все-таки удобнее.

Ответ на »сообщение 358« (Антон Григорьев)
___________________________

Ну, я, например, не знаю, как, не подчёркивая это, отвечать на Круглом столе на многие вопросы, связанные с тем, как создавать, копировать и уничтожать объекты, почему после выполнения Free переменная не равна nil и т.п. Создать язык, в котором можно будет не знать, что переменная типа объект является указателем, вполне реально, но Delphi таким языком не является.
Ну так это проблема в конкретных людях, которые не читают книг с базовыми знаниями по языку программирования. О том, что объекты в Delphi - динамические, опытный разработчик должен всегда помнить. А если помнит, то зачем делать себе напоминание в виде "крыжиков"?

Ссылочку по рефакторингу лучше было дать на
www.refactoring.com , чем на магазин книжки.

Ответ на »сообщение 357« (panda)
___________________________

Зачем подчеркивать каждый раз, что переменная типа объект на самом деле является указателем?

Ну, я, например, не знаю, как, не подчёркивая это, отвечать на Круглом столе на многие вопросы, связанные с тем, как создавать, копировать и уничтожать объекты, почему после выполнения Free переменная не равна nil и т.п. Создать язык, в котором можно будет не знать, что переменная типа объект является указателем, вполне реально, но Delphi таким языком не является.

Ответ на »сообщение 353« (Geo)
___________________________

У объектов есть методы. У методов есть реализация.
Ну... если они не абстрактные :-)
Почему бы в реализации методов объектов (низкоуровневое, с точки зрения ООП, программирование) не воспользоваться паскалевскими конструкциями с указателями на облесть памяти?
Потому что смысла не имеет. Зачем подчеркивать каждый раз, что переменная типа объект на самом деле является указателем? Если так хочется низкоуровневости, давайте перейдем на С++ и будем писать **p++^=q++=*r-s

Ответ на »сообщение 354« ()
___________________________

Объект в дельфи - это указатель на область памяти.
А в Java не так что ли?

Если этого не знать, то тогда будешь делать
А:=В, а не А.Assign(B).
Если этого не знать, то нельзя вообще написать программу сложнее, чем "Hello, world".

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

Ответ на »сообщение 354« ()
___________________________

Ответ на »сообщение 352« (panda)
___________________________
Объект в дельфи - это указатель на область памяти.
Если этого не знать, то тогда будешь делать
А:=В, а не А.Assign(B).

Сам обжегся на этом свое время.Речь идет не о том, что есть объект в Delphi, а о том, как это описывать. Причём компилятору как раз по барабарабану, речь идет исключительно об удобстве.

Ответ на »сообщение 352« (panda)
___________________________
Объект в дельфи - это указатель на область памяти.
Если этого не знать, то тогда будешь делать
А:=В, а не А.Assign(B).

Сам обжегся на этом свое время.

Ответ на »сообщение 352« (panda)
___________________________
У объектов есть методы. У методов есть реализация. Почему бы в реализации методов объектов (низкоуровневое, с точки зрения ООП, программирование) не воспользоваться паскалевскими конструкциями с указателями на облесть памяти?

Ответ на »сообщение 351« (Geo)
___________________________

Я просто хотел сказать, что поскольку Паскаль стараниями Борланда плавно перетекал в Дельфи, то некоторые приемы программирования разработанные в интерваое TurboPascal-6.0 -- Delphi 1.0 не потеряли своей актуальности до сих пор. Может быть и можно их избегать, но стоит ли?
А я как раз посмотрел с другой стороны: у современного Паскаля (Delphi) очень много нововведений, сближающих его, например, с Java. Так может стоит оперировать понятиями более высокого уровня (объектами, а не указателями на память с данными)?

Ответ на »сообщение 349« (panda)
___________________________
Точно. Но спорить по глупому не хочется. Я просто хотел сказать, что поскольку Паскаль стараниями Борланда плавно перетекал в Дельфи, то некоторые приемы программирования разработанные в интерваое TurboPascal-6.0 -- Delphi 1.0 не потеряли своей актуальности до сих пор. Может быть и можно их избегать, но стоит ли?

»сообщение 349« (panda) Давайте уже точно определимся сколько должно выпасть волос, что бы признать человека лысым ;)))

Ответ на »сообщение 348« (Geo)
___________________________
Это начинает походить на спор: "Кто сильнее: слон или кит" ;-)

Ответ на »сообщение 347« (panda)
___________________________
Пишу про ту версию Delphi, про которую знаю.

А если продолжить сравнение, то в изначальном Паскале ООП вообще не поддерживалось. А в TP 6 уже были объекты (хоть и не классы). Так что, по-моему, разница между Паскалем Вирта и TP 6 все же больше, чем между TP 6 и Delphi.

Ответ на »сообщение 339« (Geo)
___________________________

Совсем забыл дописать :-)
А причем здесь Delphi 6? Официально сейчас продается только Delphi 2005. Так что не забудьте рассмотреть "class helpers".

Ответ на »сообщение 343« (al_mt)
___________________________

Ссылочку не подбросите?
Пожалуйста: http://www.books.ru/shop/books/30436

Ответ на »сообщение 339« (Geo)
___________________________

>>> Delphi очень далеко ушел от Turbo Pascal.
Ой ли? Разница между Delphi 6 и Turbo Pascal 6.0 ненамного больше, чем разница между Turbo Pascal 6.0 и Паскалем Вирта.

ООП в Turbo Pascal 6.0 имеется
В предыдущеем сообщении браузер сглючил :-(

Так вот, как насчет ссылок на класс (class of), виртуальных конструкторов, методов класса (class procedure), единого предка всех классов, RTTI? Это было? А реализация интерфейсов (с точки зрения не COM, а именно ООП)? Это по-Вашему ничто?

Ответ на »сообщение 339« (Geo)
___________________________

>>> Delphi очень далеко ушел от Turbo Pascal.
Ой ли? Разница между Delphi 6 и Turbo Pascal 6.0 ненамного больше, чем разница между Turbo Pascal 6.0 и Паскалем Вирта.
ООП в Turbo Pascal 6.0 имеется
А как насчет указателей на классы (class of),

Ответ на »сообщение 338« (panda)
___________________________

Ответ на »сообщение 333« (al_mt)
___________________________

В общем речь идёт о всяких жутковато-выглядящих решениях, когда алгоритмы достаточно сильно завязаны на язык, а еще надо, чтобы другие чётко код понимали.
Такие алгоритмы надо рефакторить. Когда я в свое время первый раз прочитал Фаулера, это произвело на меня неизгладимое впечатление.
Ссылочку не подбросите?

Неужели Вы сами ни когда так не писали? Сразу в ассемблере???
Э... да. Как-то уж так получилось, что сразу. Ну или переписывал программы с бейсика на ассемблер. Однажды посмотрел Паскаль для Z80, но он мне не понравился.Угу... Что паскаль, что С для Z80 были ужасны и не работали :) Самый лучший вариант, был такой целочисленный компилятор васика, вот на нём с ассемблерными вставками. Или на чистом ассемблере... Но логику всё равно предварительно на "птичьем языке"...

Ответ на »сообщение 341« (Geo)
___________________________

Ответ на »сообщение 340« (Tricky)
___________________________
Были приведены ссылки на официальные документы, в которых говорится, что начиная с Delphi 7 сам язык программирования называется Delphi

да пофиг эти "официальные документы" - это маркетинговый ход. Паскалем он не перестал быть пока что, правда? Аналогично, как и Си - есть разные его модификации, есть разные компайлеры и среды разработки. Но от этого язык не перестал называться Си.

Ответ на »сообщение 340« (Tricky)
___________________________
>>> Delphi - это IDE. А язык программирования - Object Pascal.
Неоднократно поднимавшийся вопрос. Были приведены ссылки на официальные документы, в которых говорится, что начиная с Delphi 7 сам язык программирования называется Delphi

Ответ на »сообщение 339« (Geo)
___________________________

Ответ на »сообщение 337« (panda)
___________________________
>>> Delphi очень далеко ушел от Turbo Pascal.
Ой ли? Разница между Delphi 6 и Turbo Pascal 6.0
...разница между Turbo Pascal 6.0 и Паскалем Вирта.


Господа!  Delphi - это IDE. А язык программирования - Object Pascal.
поэтому сравнивая не путайте.
Можно сравнивать оболочки (TP, "супервижн", BPW, IDE Delphi).
А можно сравнить языки (Object Pascal, BP with objects, паскаль Вирта, etc). Это будут совершенно разные сравнения.

Ответ на »сообщение 337« (panda)
___________________________
>>> Delphi очень далеко ушел от Turbo Pascal.
Ой ли? Разница между Delphi 6 и Turbo Pascal 6.0 ненамного больше, чем разница между Turbo Pascal 6.0 и Паскалем Вирта.

ООП в Turbo Pascal 6.0 имеется

Ответ на »сообщение 333« (al_mt)
___________________________

В общем речь идёт о всяких жутковато-выглядящих решениях, когда алгоритмы достаточно сильно завязаны на язык, а еще надо, чтобы другие чётко код понимали.
Такие алгоритмы надо рефакторить. Когда я в свое время первый раз прочитал Фаулера, это произвело на меня неизгладимое впечатление.

Неужели Вы сами ни когда так не писали? Сразу в ассемблере???
Э... да. Как-то уж так получилось, что сразу. Ну или переписывал программы с бейсика на ассемблер. Однажды посмотрел Паскаль для Z80, но он мне не понравился.