Стандарты оформления

← →
AndrewK (2005-09-01 13:55) [0]

Доброго времени суток, господа!

Есть желание унифицировать работу отдела разработки в области оформления исходных кодов. Нашел несколько стандартов для Delphi, но для БД ничего найти не смог.

Поделитесь опытом, кто-нибудь использует в своей работе стандарты по оформлению кода, именованию объектов баз данных (таблиц, процедур, функций), стандарты оформления интерфейса.

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

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

Заранее благодарен.

← →
Ega23 © (2005-09-01 14:15) [1]

Соглашение о наименованиях -------------------------- При описании структур данных предлагается использовать следующие соглашения и мнемонические нотации. Общие положения. 1. Имена таблиц и полей должны максимально описывать соответств.сущности. 2. В качестве имен не допускается применение слов, которые могут оказаться резервированными в используемых программных средах (напр, слов ORDER, SELECT, DENY, etc) 3. Следует помнить, что для таблиц, импортируемых и экспортируемых возможны ограничения по длине имени табл. - 8 симв, и по длине имени поля - до 10 симв. Эти значения считаются рекомендованными. Таблицы: [<Сокр.Групповое имя>]<Сокр.Функциональное имя таблицы><s|es|Pl|Gr>, где s,es - суффикс для справочников (списков). Напр, Pers - справ. персонала, Sexes - список полов, HWTasks- список заданий для апппатуры Pl- суффикс для таблиц соответствия (планов) Gr - суффикс для таблиц - описателей групп Поля (колонки) таблиц: <Сокр.имя табл.(сущности)|Dat|Unid|Развернутое имя>[<Доп.Функц.имя>][<Описатель логич.типа>][Нумератор] Unid - уник.идентификатор(исп.только для идент.записи,без ссылок на него) Dat - дата <Доп.Функц.имя>=<St|Fl|Gr|Typ|Sum>, где St- статус Fl - флаг (спец.признак) Gr - группа Typ - тип Sum - сумма <Описатель логич.типа>=<Сod|Nam|Lab|Msk|Ord|Id|Nr|Num|Val|Mod|Min|Max| Prc|Not|Txt|In|Out|Add|Cl> Сod - код,перв.ключ,тип данных integer Id - уник.идентификатор - перв.ключ, тип данных integer [identity] Nam - полное имя, тип данных varchar 32,64 Lab - краткое имя, тип данных char 4,8 Msk - маска (использ/нет), тип данных tynyint Ord - порядок отображения, тип данных integer Nr - порядковый (регистрационный) номер (напр., документа) integer,varchar Num - число, количество, тип данных numeric Val - числовое значение, величина, тип данных numeric Mod - режим работы, обработки tynyint Min - минимальное значение, тип данных int, numeric Max - максимальное значение, тип данных int, numeric Prc - числовое значение в процентах, тип данных numeric 5.2 Not - примечание, тип данных varchar 64,255 Txt - текст, описание varchar 64,255,4096,TEXT... In - начальный,исходный (напр.,для дат) Out - конечный,выходной (напр.,для дат) Add - ссылка на дополнительную информацию Img - образ,картинка,бинарный массив Cl - цвет Cnt - счетчик [Нумератор]=[0,1..] Замечания. 1. Развернутое имя использовать не рекомендуется. 2. Дублирование повторяющихся букв категорически не рекомендуется. Например, следует писать не LettTypeCode, а Letypcod. Индексы и дополнительные ключи: <Ix|Ux|Cx>_<Имя Таблицы (м.б.сокращ.)>_<Имя Поля (м.б.сокращ.)> , где Ix - префикс обычного индекса Ux - префикс уникального индекса Cx - префикс кластерного индекса Хранимые процедуры S_<Сокр.Имя функ.группы><Сокр. Функ. имя хранимой процедуры> X_<Сокр.Имя функ.группы><Сокр. Функ. имя внешней хранимой процедуры> Просмотры (view) V_<Сокр.Имя функ.группы><Сокр.Функ. имя просмотра > Назначение Доменов(типов данных) DT0 Дата-время, default 0 (1900.00.00) datetime DTnow Дата-время, default тек.время datetime Flag Флаг, default 0 tinyint GUID Global Identifier uniqueidentifier Img Картинка image INT1 1-байтовое целое, default 0 tinyint INT2 2-байтовое целое, default 0 smallint INT4 4-байтовое целое, default 0 int IntIdentity Автоинкрементное целое Int Identity(0,1) LAB4 Метка - строка 4 символа char(4) LAB8 Метка - строка 8 символов char(8) LongString1024 Длинная строка 1024 симв. varchar(1024) LongString2048 Очень длинная строка 2048 симв. varchar(2048) LongString4096 Очень длинная строка 4096 симв. varchar(4096) Mask Маска (1-используется,0-нет), default 1 bit Nam16 Наименование - строка 16 симв varchar(16) Nam32 Наименование - строка 32 симв varchar(32) Nam64 Наименование - строка 64 симв varchar(64) Not255 Примечание - строка 255 симв varchar(255) Prc5_2 Процент (не целое) numeric(5,2) Sum16_2 Сумма (не целое) numeric(16,2)

← →
Fay © (2005-09-01 15:11) [2]

2 AndrewK (01.09.05 13:55)
Не надо искать. Надо договариваться.

← →
AndrewK (2005-09-01 15:22) [3]

>Fay © (01.09.05 15:11) [2]

>Не надо искать. Надо договариваться.

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

>Ega23

Спасибо. Буду изучать.

← →
Ega23 © (2005-09-01 15:37) [4]

2 AndrewK (01.09.05 15:22) [3]
Спасибо. Буду изучать.

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

← →
Sergey13 © (2005-09-01 15:57) [5]

2[3] AndrewK (01.09.05 15:22)
>А насчет договоренностей: пробовал. Поговорили, обсудили, договорились. Какое-то время все нормально, затем опять начинается творчество.

Вы просто остановились на полпути. 8-)
Надо было продолжать. Зафиксировали в приказе по подразделению и установили наказания за несоблюдения. Все расписались в приказе об уведомлении.
Дальше дело в соблюдении и контроле.
ИМХО, так.
Хотя, если честно, если ты как начальник (?) не можешь совладать с 5 подчиненными, то и приказ со стандартом может не помочь. ИМХО, опять же.

ЗЫ: Ничего личного, кроме опыта. 8-)

← →
AndrewK (2005-09-01 16:14) [6]

> Sergey13 ©

Начальником я стал буквально на днях, до этого был рядовым программером, поэтому договоренности с другими были не более чем добрыми пожеланиями. Тем более проекты каждый вел самостоятельно. Ну а еще ведь программисты ненавидят контроль и чтобы кто-то лез в их код и учил как надо делать? Правда? :) Знаю, сам такой.

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

Ух как загнул, как в книжках. :)

А насчет пяти подчиненных - справлюсь.

> Ega23 © (01.09.05 15:37) [4]

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

Я понял. Спасибо.

← →
Sergey13 © (2005-09-01 16:17) [7]

2[6] AndrewK (01.09.05 16:14)
> Начальником я стал буквально на днях
Поздравляю!!!

>Сейчас хочу все наладить....
Ну тогда...
"Правильной дорогой идете, товарищи."
(с)
8-)

2 AndrewK (01.09.05 16:14) [6]
Вы не очень-то последовательны 8)
Хотите навязать чужое видение? Или обсудить, но не договариваться?
Хрень какая-то.

>> Договариваться о чем?
>> Поэтому и делаю попытку все описать, потом обсудить с коллективом

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

← →
AndrewK (2005-09-02 13:08) [9]

>Fay © (01.09.05 20:52) [8]
>Вы не очень-то последовательны 8)
>Хотите навязать чужое видение? Или обсудить, но не договариваться?

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

>> Договариваться о чем?
>> Поэтому и делаю попытку все описать, потом обсудить с коллективом

А как иначе? Обсуждать всегда лучше то, что уже готовое. Тогда и быстрее получается и лучше. Тем более в вопросах стандартизации. А иначе начинаются войны вкусов, кто привык for с большой буквы писать, кому-то пробелы не нравяться, кто-то оператор try finally end не переваривает. А так есть документ, который выставляется на обсуждение. По нему принимаются конструктивные предложения или замечания. Вопросы вкусов отсекаются директивно. Получается нормальный рабочий документ. Дальше только контроль.

>> киньте какой-нибудь пример стандарта на разработку

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

>> Вот этот прототип я сейчас и делаю.

Прототип стандарта, который я делаю включает в себя не только правила оформления объектов базы данных, но и стандарт оформления кода, стандарт оформления директорий проектов, правил и рекомендаций по разработке отдельных блоков, стандарт оформления пользовательских интерфейсов и еще много чего.

>> И цель не навязать всем свое видение как надо писать

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

Надеюсь, я более или менее нормально объяснил на этот раз.

2 AndrewK (02.09.05 13:08) [9]
Я бы выбрал (собственно, так и сделал) эволюционный подход.
А записывать результаты переговоров стоит только в случае изменения состава команды.

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