Предлагаю на суд зрителей свой небольшой статьец по поводу стиля написания программного кода. Собственно, основа статьи была написана по просьбе руководителя проекта, в котором я некоторое время контрактил (в ответ на моё удивлённое "Ёёё, ну и наваяли! У них чё - зарплата от количества написанных строк зависила?"). Ну, написал первую версию статейки, а потом Остапа понесло...

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

Может, некоторые идеи покажутся супер-банальными (например, о разбиении скриптов на под-скрипты - вы можете подумать: ещё бы посоветовал зубы по утрам чистить...) - но, поверьте, я такое повидал, что лысина дыбом... Наболело...

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

Итак, гоу эхед: zuskin.com/coding_habits.htm

Anatoly MoskovskyЯ использую следующий подход:
Допустим есть окно w_имя_окна, которому надо передать композитный параметр.
Тогда создаем невизуальный объект n_имя_окна_parm,
в котором объявляются все необходимые именно этому окну параметры.Это то, что называется "стрейфорвард солюшн" - т.е. первое, что приходит в голову. Конечно, можно и этот подход осуществить, если неохота посидеть и подумать как облегчить весь последующий девелопмент, найдя универсальное (дженерик) решение, но с тем-же успехом можно отказаться от наследования и для каждого случая строить отдельный (специальный) объект. Дело в том, что аппликация, над которй я сейчас работаю по контракту, написана именно с помощью этого подхода - ох и приходится мудохаться... Во-первых, все PBLы просто наводнены вот такими классами, цель которых - просто передать параметры. Просто наводнение, фиг найдёшь среди них действительно нужный класс! Да уж лучше б создали один класс, содержащий все возможные в аппликации поля для передачи (сколько их - 50? 60?), если ради строгого контроля типов готовы на такое психическое напряжение... Во-вторых, многие скрипты содержат объявления десятков переменных вот таких типов, а потом в CHOOSE CASE решается какие из них инстантиировать. Вместо того чтоб иметь дело всегда с одним классом (или стринговой переменной, содержащей параметры через делимитр). Это уже не говоря о том, что для добавления параметра приходется чекаутить объект, изменять и чекинить обратно - вместо того, чтоб просто добавить строчку в скрипте (при множественности объектов передачи параметров эту строчку всё равно добавляешь). Что может быть проще, чем объявить во всех классах (естественно, на уровне предка) функции uf_key() и uf_get_key() которые соответственно генерируют и принимают аргумент (сохраняя в инстанс вариэйблз) в виде описанного в статье класса-почтальона или просто строки и заполняются девелоперпом в классах-потомках согласно бизнес-правилам? Так что предложенный Вами метод не был рекомендован специально, а не по неведению; более того, я написал целый абзац о его проблематичности, но убрал т.к. статью читают на моей нынешней работе и я не хочу чтоб они восприняли это как камень в свой огород.

Anatoly MoskovskyНо в качестве одного из примеров как технически можно записать такую проверку
было предложено следующее:
Во-первых этот код можно переписать более лаконично: Может, более лаконично, но, ИМХО, чуть менее "понимабельно" по сути. Впрочем, это мелочь.

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

White OwlА я еще вот с этим не согласен:
С классической точки зрения такой цикл надо описывать так:
Я тоже так думал, начитавшись книжек в колледже. Но МНЕ удобней так, как я описАл - жизнь научила. Если {code fragment} сам по себе имеет инденты (табы), зачем усугублять? Если ты привык за годы карьеры иначе и не имеешь охоты "переключаться" - дык и не надо! Привычка - страшная сила, по себе знаю.

White OwlПро создание первичных ключей. Ты перечислил несколько минусов натуральных ключей (все эти минусы можно отмести одним общим возражением - неправильно определено что является натуральным ключом).Приведённое определение - не моё, и звучит очень просто: натуральный ключ - это такой первичный ключ (или кандидат), значения которого кроме уникальной идентификации записей таблицы имеют какой бы то ни было дополнительный смысл в реальной жизни.

White OwlНо ты ни слова не сказал о минусах сурогатных ключей. А вот лично я их ненавижу. Да, они удобнее натуральных в случае если натуральный ключ надо поменять, но зато клиенту прийдется повозится чтобы создать этот самый сурогатный ключ. Хорошо если в БД есть встроенная система генерации (типа sequences в Oracle или @@identity в Sybase). А если нету? Как ты собираешься создавать номер для ключа в мультиклиентском приложении?Даже в тех субэдэшках, что имеют внутренние средства генерации ключей, лучше ими не пользоваться (и в большинстве проектов, куда меня засылала партия, они и не использовались). Решение простое: имеется таблица, состоящая из двух полей: entity_name и next_value. Создал в системе новую сущность - загоняешь в таблицу запись для неё:


И создаёшь хранимую процедуру или функцию которая принимает название сущности и возвращает следующее значение нумератора (доступ скриптов к таблице будет осуществляться ТОЛЬКО через неё); естественно, эта функция увеличивает next_value на единицу готовя почву для следующего вызова; даже более того - если запись для данной сущности ещё не существует, она её создаёт вышеназванным инсёртом (или генерирует ошибку, что, ИМХО, лучше - всё надо делать обдуманно). Этот способ (в отличие от неуправляемых оракловских сиквенсов) делает генерацию ключа частью транзакции (со всеми вытекающими для мультиклиентских приложений преимуществами). Да и зачем загружать систему кучей сиквенсов если можно иметь одну маленькую табличку? А сначала создавать запись с отоинкрементом, затем считывать новорожденное значение через @@identity - всё равно что ехать из Питера в Москву через Северный Полюс. Лучше разбить всё на этапы: сначала генерируешь нумератор в переменную, затем вставляешь везде, где надо в рамках данной транзакции (например, в первичный ключ таблицы-master и во внешние ключи таблиц-details). Именно так я собираеюсь создавать номер для ключа в мультиклиентском приложении. Лишь одно обидно: все эти умные идеи - не мои :-).

White OwlНатуральные ключи всегда лучше.В программировании (да и вообще в жинзи) вряд-ли есть вещи, которые ВСЕГДА лучше.

White OwlДаже если ты вынужден передавать пять-восемь полей для идентификации одной записи - все равно это намного лучше чем работать с абстрактным числом.А если 20-30 - это, по твоей логике, вааще кайф! Кстати, натуральный номер работника - такое-же абстрактное число (плюс куча всяких ограничений и возможных неприятных сюрпризов в будущем), просто оно уже существовало до создания записи в базе данных. Что будешь с этим делать, ненавистник суррогатных ключей?

White OwlХотя бы тем, что серверу БД прийдется вести только один индекс а не два. А это приводит к более быстрой работе всей базы.Зависит от многих обстоятельств. В некоторых ты прав (например, если до черта инсёртов и мало селектов). А кроме этого момента, ЧЕМ ИМЕННО естественные ключи лучше? Ты просто написал что ненавидишь суррогатные, что, согласись, не аргумент. Я не ищу спора - мне просто совершенно откровенно интересно что хорошего в том, что за все эти годы выпило у меня столько крови.

White OwlПро передачу параметров в окна.
А зачем вообще открывать окна с параметрами? Намного проще делать так:
Тогда ты сохранишь и читабельность кода и не понадобится заводить структур, и у тебя останется возможность открыть окно с неполным набором параметров. И в будущем, если понадобится добавить в w_target новый параметр, тебе не нужно будет заниматься перекомпиляцией всех объектов которые открывают данное окно (и используют структуру для передачи параметров)Речь шла вообще о передаче параметров между объектами, окно - просто пример. В твоём примере с of_SetKey есть преимущества, но есть и недостатки. Представь, что w_target открываетска из многих скриптов w_source-а - каждый раз писАть набор вызовов of_SetKey, да ещё и в будущем мейнтененс предоставлять? Да и зависит w_target от w_source-а, что не есть хорошо - я бы предпочёл принять аргументы, проверить (если требуется) и рапихать куда надо внутри w_target-а (скажем, в функции, вызываемой фреймворком из события Open).

18-я весна[quot Ursego][quot Anatoly Moskovsky]Т.е. если я правильно понял из этого абзаца, то единственная проблема состояла в том, что сложно искать нужный класс в библиотеке?
Ну это конечно так, если их именовали как бог на душу положит.Нет, главная проблема - очень много возни в скриптах. Целый экран определений переменных, а затем - длиннейшие CHOOSE CASE-ы с кастингами на все случаи жизни и вызов другой функции, внутри которой - та-же история с CHOOSE CASE-ами и кастингом, но в обратном направлении. И это вместо одного примитивного стринга са всеми нужными параметрами! Павбывав бы! Короче, много лишней девелоперской работы, но мне-то что - оплата почасовая. Готов героически заваливать пиблы всё новыми и новыми объектами, в каждом из которых - лишь несколько инстанс вариэйблз - почему нет, если за дурную работу платят? А с тем-же почтальоном - работа выполнялась бы быстрей, сопровождение сложной аппликации не превращалось бы в длинные попытки понять что в этих f...g скриптах понаписано... Не, это было бы убыточно для меня.

Филипп, может, решение с конкатенированным стрингом с параметрами внешне выглядит и ужасно, но те 4 с лишним года, что я работал с фреймворком, использующим этот метод, были просто кайфом. Я ведь изпользую ту технологию, что применяется на фирме, где работаю в этот момент, и ничего не решаю. Просто констатирую что мне нравится, а что нет. Может, если когда-нибудь решение как писАть будет зависеть от меня, то за мои любумые методы глаза выцарапаю, а пока покорно "прогибаюсь под изменчивый мир". Из ответов вырисовывается следующая картина: каждый держится хваткой бультерьера за то, с чем свыкся. Наверно, в этом нет ничего плохого, ведь принять что-то новое - всегда шок. Я вот с Оракла на SQL Server спрыгнул - как на Марс попал. Поработал несколько недель -ничего, жить можно! Несмотря на многие годы с PL/SQL вижу, что T-SQL намного удобней в работе - признаю, что моё мнение по этому вопросу было ошибочным (более того, сейчас мне хочется сделать создателям Оракла что-то неприятное за их топорную работу - шоб они в аду в бесконечном курсорном цикле крутились!). Впрочем, это уже вне темы.

Шатёркинда ладно - sql тоже затронем :)

автор
*** BAD code: ***

SELECT @country_name = country.country_name
FROM country,
city,
address
WHERE country.country_id = city.country_id
AND city.city_id = address.city_id
AND address.address_id = @address_id;

*** GOOD code: ***
SELECT @country_name = country.country_name
FROM country
JOIN city
ON city.country_id = country.country_id
JOIN address
ON address.city_id = city.city_id
AND address.address_id = @address_id;

что-то мне подсказывает, что всё с точностью до наоборот :)Я до недавнего времени тоже не был поклонником метода с ключевым словом JOIN - более того, стоял на "старом" синтаксисе насмерть, как 26 бакинских комиссаров. А всё из-за многолоетней привычки. Но на новой работе меня заставили перейти на новый синтакс, и поработав с ним я стал его поклонником (думаю, отзывы в этой ветке тоже кое-что да изменят в моих взглядах). Если вкратце, то при WHERE-методе всё свалено в одну кучу; при JOIN-методе мы имеем несколько меньших "кучек", и каждый раз можем комфортно сосредоточиться на том, как одна таблица связана с общей картиной; проанализировав её, переходим к следующей. Как в притче с веником: целый веник сломать трудно, а по прутику - легко!

18-я веснарассмотрим в разрезе рефакторинга:
Допустим поменялся набор параметров для вызова окна (добавлен, удален, переименован параметр)
При технике 1 если не везде в вызывающем коде отразить эти изменения, то ошибки после удаления или переименования всплывут только в рантайм при попытке открыть окно.
При технике 2 ошибки после удаления или переименования возникнут уже при компиляции и их придется исправить.ОК, ошибки всплывут на несколько минут позже, при юнит-тесте. Видишь, что параметр не получен - смотришь почему (в вызывающем скрипте). Из-за этого наводнять аппликацию десятками объектов, да ещё и поддерживать (каждый раз изменять) их?

18-я веснаСамодокументирование.
Техника 1. Перечень и тип возможных параметров можно узнать только проанализировав алгоритм разбора этих параметров в окне.
Техника 2. Параметры отделены от алгоритма и четко видны.При первом методе всё сосредоточено в скрипте, принимающем параметры (Open, pfc_open, uf_get_key() или что бы там ни было) - имею в виду в плане самодокументации, чтоб понять что передаётся. Т.е. всё - в одном месте, а не разбросано по разным частям аппликации как в методе 2. О чём ещё мечтать бедному программисту? Кроме того, не все параметры всегда передаются (имеются объекты параметров, используемые в разных обстоятельствах - иначе пришлось бы иметь не сотни, а тысячи подобных "красавцев"). И вот я смотрю на поля объекта параметров, которые, как ты пишешь, "четко видны", и вижу, что имеются незаполненные. Что это? Баг или нет? Как определить? Всё равно придётся лезть в открывающий скрипт и смотреть логику, алгоритм, а при неполучении ожидаемого результата - дебагировать.

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

Anatoly MoskovskyА мой вопрос был: как конкретно реализована передача разных наборов аргументов в разные окна используя наследование Message?Я так предполагаю, имеется некий класс (унаследованный от Message) с полями для передачи самых часто встречающихся в приложении сущностей (а в каждой аппликации их как правило хоть несколько штук да имеется) плюс, быть может, поинтеры для транспортировки datawindows, datastores и NVOs и прочих непримитивных типов, а от него унаследованы другие, в которых объявлены дополнительные, уже специфические для тех частей аппликации где объекты будут использованы. Причём базовый класс может быть инстантиирован для использования as is если имеющихся в нём полей достаточно. Или не угадал?

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

urvasПрограммист!
Пиши так, чтобы конечному пользователю было комфортно, удобно и приятно.Это уже абсолютно другая тема, хоть и важная. А сейчас обсуждается тема - чтоб было комфортно, удобно и приятно программисту. Мы ж тоже люди!

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