На заметку:
Я частенько использую оператор (L)Parameters вместо оператора (Local) Private. Разумеется в данном случае нужно соблюсти условие, что в начале списка идут реальные параметры, а после них то, что используется в качестве переменых, ну и не забыть про максимальное количество. Удобно по следующим причинам:
- меньше загромождается исходный текст за счет отсутсвия операторов объявления переменных
- при некорректном вызове функции не возникает ошибка, связанная с тем, что в функцию передается параметров больше, чем там заявлено.

> никогда...
И совершенно напрасно.

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

Пример, попробуй убедить что это пример плохого тона...
***********************************************************
***********************************************************
PROCEDURE S0014
***********************************************************
* 2003.08.15.0-14 Последние изменения
***********************************************************
LPARAMETERS PAR0, PAR1, PAR2, PAR3, nFox, cKey, cAns, sKey, mKey, cIco, rKey
cAns = 'MASTER.ICO'
mKey = IIF (TYPE('PAR0')='C', PAR0, 'EXPERT')
sKey = IIF (TYPE('PAR1')='C', PAR1, '')
cKey = IIF (TYPE('PAR2')='C', PAR2, '') +';'
cIco = IIF (TYPE('PAR3')='C', UPPER(ALLTRIM(PAR3)), cAns)
и т.д.

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

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

> И если в каждой п/ц делать абсолютный контроль тады,
> даже не знаю как и обозвать ситуацию.
> Ну что Убедил ?
Так это оказывается была попытка меня в чем-то убедить....
Называете как хотите, и, разумеется, абсолютно в каждую мелкую процедуру этого вставлять не требуется, но иногда, когда такого контроля нет, там, где без него невозможно обеспечить приемлемую устойчивость программы я отпускаю в адрес программеров не очень приятные для них слова.

> Следует помнить, что ... Вы можете вернуться к
> написанному коду спустя несколько месяцев (лет)
Совершенно верно. Это один из вопросов, которым я задаюсь весьма часто,
и достаточно регулярно, и уже наработал достаточно различных уловок, благодаря которым я видя свой исходник через много времени могу с ходу дать пояснения, и не потому, что я это помню, а потому, что я в своем стиле это сразу вижу.

-) Читабельность (понятность) кода
?Однозначный проигрыш....
Ничего подобного. Читается очень легко и быстро.

>После слова (L)Parameters подразумеваются именно параметры, т.е. нечто,
>что принимается от вызвавшей процедуры или передается в вызвавшую
>процедуру. А здесь необходимо держать в памяти, что это не так.
>(Напоминаю: Вы год не возвращались к этой процедуре, думаю не сразу
>сообразите, где кончаются параметры и начинаются переменные)
Приведенный выше участок кода примерно двухлетней давности из первого-же подвернувшегося под-руку исходника.(Дата, указанная в нем - означает наличие мелких доработок на эту дату в пределах всего текста функции (в данном частном случае)). Кстати посмотрите повнимательнее, я думаю что не только я, но и многие другие сразу поймут, где есть фактические параметры, а где начинаются псевдопеременные. Вопрос по разграничению параметров и псевдопеременных я снял практически сразу, как у меня возникла идея такого способа объявления перменных.


-) Модифицируемость (легкость изменения) кода
?Опять проигрыш
Да Вы, батенька, жуткий консерватор. Учитесь видеть несколько шире Ваших привычек.

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

>Сделали это при вызове данной процедуры,
>а в самой процедуре забыли описать.
Если конечно забыл, это случается крайне редко, а вот как способ еще раз протестировать свой проект на эту неприятность, я стараюсь не упускать.
Описанный Вами прием я часто использую, что-бы протестировать свой проект на предмет того, как он справится с данной ситуацией либо за счет предпринятых ранее профилактических действий, либо действиями обработчика ошибок. Добавление параметров при вызове функции в моей практике случается не часто, а вот вызов функции с меньшим их количеством, вопрос более серъезный, и встречается гораздо чаще, и тут-то как раз контроль на типы переменных и/или параметров очень даже к месту.

> Но никакого сообщения об ошибке не последовало.
> Что все правильно? Нет, просто это не было воспринято как ошибка.
> И попробуй потом такую ошибку отлови!
Вопрос поднят правильно, актуальный, но не к месту.
Если от какой-либо функции требуется увеличение ее функциональности, для чего, собственно, и был дабавлен новый параметр (как я это понимаю) при ее вызове, то забывать об этом нельзя, и вряд-ли это относится ко мне в большей степени, чем к кому-либо другому. Наличие такой ситуации уже изначально является ошибкой программиста, а программист, любой, обязательно должен тестировать свои текущие доработки на корректность отработки функционала.


> ... объявлять переменные непосредственно перед
> их первым использованием.
> Такое объявление облегчает редактирование кода
> (переменная уже не нужна, но ее объявление все еще есть)
Абсолютно не возражаю, но с течением времени и формированием моего собственного стиля программирования я счел целесообразным собрать в одно - два - три места объявление переменных каждой функции. Я веду весьма жесткий контроль за неиспользуемыми переменными, для чего у меня есть собственные приемы, а объявление их кучкой мне дает возможность сразу одним взглядом охватить картину что и как объявлено, чему какое значение присвоено и т.п.


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

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

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

С уважением ко всем, Yura.

> но дело-то в том,
> что именно общение подобного рода и дает почву для идей.
Конечно, иначе-б и меня тут небыло.


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

> И где тады вугоду искать от, ставших бесполезными TYPE("???")="?"
Если работа над проектом окончательно прекращена, и все отлажено, тогда уже наличие или отсутствие этого уже не имеет никакого значения, все-равно туда уже больше никто не заглянет, но и любой законченный проект с этого времени начинает умирать. Эта группа операторов имеет пользу если, работа продолжается, более того, когда такая функция кочует из одного проекта в другой, и тем-более, если она передается другим программистам, которые должны ее использовать, не заглядывая в нее, которые, безусловно, могут напутать с передачей праметров, и при этом забыть о необходимости тестирования своего-же кода. В качестве другого программиста может быть кто угодно, в том числе и он сам через какое-то время. Так у меня есть уже ряд функций, в которые и заглядывать уже не хочется, и, разумеется, я далеко не всегда помню что, и в каком порядке туда нужно передать, но ведь работают.... Эти несколько строчек - это великое дело.


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


> то абсолютно те же слова можно адресовать и Вам.
Возможно, я в грудь себя не бью.


> Ваш вариант
LPARAMETERS PAR0, PAR1, PAR2, PAR3, nFox, cKey, cAns, sKey, mKey, cIco, rKey
> Классический вариант
LPARAMETERS PAR0, PAR1, PAR2, PAR3
LOCAL nFox, cKey, cAns, sKey, mKey, cIco, rKey
> Отличие в единственном слове "LOCAL". Все!
> Ну и какой смысл был в такой экономии?
Так ведь я не призываю к безоговорочному подражанию, с другой стороны Вы асолютно правильно разделили. Надо полагать в таком случае данное слияние двух операторов в один не привело к ухудшению читаемости текста, о чем было сказано выше, да и от других замечаний не осталось и следа. Что-же касается использования одной или двух строк в данной ситуации принципиальной разницы нет, и я использую в зависимости от ситуации оба варианта. В простейших функциях я отдаю предпочтение своему варианту, в сложных - стандартно, но и там зачастую некоторый ряд переменных я прописываю в строке параметров, и кроме дополнительного удобства в этом я ничего не нахожу.


> По сути, что Вы использовали функцию ключевого слова
> LPARAMETERS как главную функцию.
Совершенно верно, с полным пониманием содеянного


> А смысл? Экономия одного единственного слова? Я даже не знаю,
> как обозвать-то человека занимающегося подобными выкрутасами.
Могу подсказать, как - человек с творческим подходм к делу, если Вам угодно. С одной стороны смысла в этом может и не быть, с другой, противоположной стороны - в рамках из этих двух строк - экономия видимого пространства на экране монитора 50%. Хотите Вы этого или нет, но уже не раз мной отмечено, что в отдельных случаях вытягивание текста в одну строку вместо расписывания по вертикали дает очень значительный выигрыш в понимании сущности реализованного алгоритма работы функции даже при явном недостатке комментариев. Могу привести наглядный пример.


> что основная задача ключевого слова LPARAMETERS -
> это объявление параметров. Задание области видимости
> и создание новых переменных - это второстепенная функция,
> которая необходима для выполнения основной функции.
Приятно иметь дело с грамотными людьми. Использование второстепенной функции данного конкретного оператора в качестве главной не несет никаких деструктивных действий, благодаря безупречной его работе, но зато в целом ряде случаев, по крайней мере в моей практике, оказывается весьма полезной.
Знать основное назначение операторов языка очень полезно, но и не менее полезно бывает видеть возможность использования конструкций языка во всем объеме их возможностей, значимость которых может даже превосходить их основное назначение.


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


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


> Никогда не знаешь, где тебя это догонит.
> Язык такой.
Согласен. Свобода действий огромная, - понимай что делаешь, а при нестандартном использовании конструкций языка требуется тройное тестирование. Острожность, аккуратность, тщательность во главе угла.

Затравка на следующий пост - А мой обработчик ошибок умеет бороться с ошибкой номер 12, а Ваш?

Удачи всем.

При использованиии Delphi я так-же не применяю таких вольностей, правда, по причине того, что я его знаю значительно слабее, чем фокс, а что касается хранимых процедур, так там действительно не место для нестандартных стилей. Использовать один стиль или нет?, так конечно, практически любой программист будет пытаться использовать более удобные на его взгляд конструкции в рамках языка, тут и обсуждать нечего, что-же касается фокса, то свободы здесь предостаточно, и если свойства операторов позволяют использовать нестандартные или не совсем стандартные обороты, почему не попробовать? Предвижу массу возражений в этом моменте - скажу сразу: далеко не всегда такими вещами стоит пользоваться, вероятность неудачного применения второстепенных свойств операторов вкачестве основных много выше удачного, но в данном случае я считаю это удачной находкой, возражения, которые основываются только на том, что другие программисты так не привыкли для меня не являются убедительными.
Если-бы все люди принимали-бы только общепринятые вещи, то, возможно, и землю-бы до сих пор считали-бы плоской. Другой пример - на сколько тяжел был переход бухгалтеров от счет к калькуляторам, все расчеты выполненные на калькуляторах перепроверялись на сетах. Попытайтесь обосновать справедливость такой проверки с сегодняшней точки зрения, или заставить кого-то из бухгалтеров вновь взять в руки счеты. Привыкайте, господа, иногда в жизни встречаются вещи не очень привычные, а иногда и совершенно нестандарные. На этом и стоит весь прогресс человечества.
Общепризнанные вещи не есть раз и на всегда утвержденный стандарт, не подлежащий критике, сомнениям и экспериментам, и уж тем-более не подлежат для вечного использования как единственно возможный вариант.

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


> нужно аккуратнее предлагать "очень нестандартные" приемы,
Данный прием не является очень нестандартным. Здесь использовано стандартное свойство стандартного оператора,хоть и второстепенного.
Применненная конструкция является просто непривычной для взгляда многих программистов, но не более того.


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


> Например, в данном случае, если бы в VFP был оператор LPARAMETER,
> а не было бы LOCAL, то твой способ был бы оправданным способом
> обойти это ограничение.
Было время, когда такого оператора в фоксе небыло, однако предложенная мной конструкция не спользовалась. Небыло LOCAL, использовали PRIVATE, небыло-бы PRIVATE, был-бы общепринятым стиль глобальных переменных, или они-бы вообще на фоксе бы не объявлялись, вместо объявления просто присваивали-бы им какое-то начальное значение и все. Я-же стою на том, что явно должны быть объявлены абсолютно все переменные, и против использования переменных глобальных, а вот как именно их объявить - дело другое.


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


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