Ответ на »сообщение 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)]);