Правила разработки

[Attid]

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


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

grdMain грид
btnStart кнопка
cbbDevItems комбик

допускается оставлять название у компонентов к которым нет обращений например лейбел

2, коментарии на каждый кусок кода из 20 строчек должен быть хоть один коментарий

** это стоит еще обсудить но думаю по стандартным правилам, каждую процедуру что она делает и сложные участки кода

3, форматирование (надо делфорех настроить) общие правила

отступ 2 проблела
увеличение отступа после begin with try и then\else если нет begin\end


4, интерфейс.

4,1 все гриды\комбы должны быть по умолчанию логически отсортированы (по имени)

4,2 гриды с более 15 записями должны сортироваться по клику

4,3 формы должны быть растягиваемы (не забывать про якоря)

4,4 формы с двумя гридами должны иметь сплитер

4,5 формы должны появлятся отцентрироваными на экране

4,6 табордер должен быть логичным (проверять работу без мыши)
4,6,1 одинаковые действия должны быть одинаковы везде

4,7 каждая форма кроме диалогов должна иметь майн меню со всеми действиями.

4,8 каждая форма должна иметь кнопку(или минимум меню(?)) выхода, чтоб не закрывать по крестику

4,9 дабл клик на форме должен редактировать запись за исключением если форма диалоговая, тогда вобор записи и модал резулт = mr_ok

5, транзакции. если этого не требует спец логика то

5,1 все датасеты и транзакции по умолчанию должны установлены в RollBack

5,2 на форме должна быть одна транзакция и не больше

5,3 явное управление транзакциями, никакого Close только RollBack\Commit

6, рефакторинг

6,1 при добавлении новых функций надо по возможности заменять места где были использованы костылики

6,2 если процедура используется в коде, то она не может называться ButtonClick(sender)

6,3 каждые 3 месяца проверять весь код на предмет соответсвия новым правилам

6,4 стараться разбивать процедуры на подпроцедуры по 25* строк

6,5 (?) стронее изучение кода раз в год


7, проверять при пустом датасете недоступность кнопок удалить и редактировать

8, проверять работоспособность форм с большим наполнением данными
(как минимум в несколько раз превышающих визуальный обьем кроме случаев если на реально БД не может быть физически больше данных чем умещающие)
ЗЫ позволяет проверять как будет выглядеть со скролами

9,если предпологается большой набор данных ограничивать его физически (select first 100)

10. не использовать * в запросах (select * from .. и даже select count(*))

[Brainenjii]

Ммм.. А почему на форме должна быть только одна транзакция?

[B4rr4cuda]

Хорошие правила, разве что есть замечание:

1, Имена должны быть логичны и содержать клас компонента в начале названия
gMain грид
btStart кнопка
cbDevItems комбик

Обычно, для улучшения читаемости, используется трехбуквенное обозначение класса:

Код: Выделить всё

grdMain грид 
btnStart кнопка 
cbbDevItems комбик

[Sergei I. Gorelkin]

1) Венгерскую нотацию (префиксы с типами) некоторые считают злом. В принципе, с современными IDE она действительно не так актуальна, как несколько лет назад, т.к. при наведении мышки на идентификатор мы видим его тип. Но это одно из мнений...

2) Лучше меньше комментариев, зато по делу. Формальное требование "на 20 строк кода" может привести к тому, что код будет просто заспамлен.

4) Я бы не стал объединять требования к gui и коду в одну кучу - все-таки это разные категории. Ну а в требованиях к gui есть смысл формализовать побольше: размеры кнопок, интервалы, шрифты, навигацию с клавиатуры и т.д.

6.3) По-хорошему, проверять на соответствие нужно перед каждым коммитом в svn. Иначе за 3 месяца могут такое наворотить, что еще месяц распрямлять придется...

[Attid]

Ммм.. А почему на форме должна быть только одна транзакция?

правила формируются некоторые по правилам которые шепчет логика , другие создаются когда разработчики любят наступать на грабли много раз.
транзакции и интерфейс относятка ко вторым, придуманы сегодня, когда патался разобраться в коде который был закручен по не болуйся, что сам разработчик забыл где какие концы.
а вообще с птичкой видел только 2 возможности.
1, одна транзакция на приложение
2, одна транзакция на форму.
или то же самое по 2 транзакции если используется пищущая и читающая.
остальное от лукавого.у меня 2 транзакции выигрыша пока нету.

B4rr4cuda

Обычно, для улучшения читаемости, используется трехбуквенное обозначение класса:

мысль интересная, особенно когда комбобокс и чекбокс ,но передалывать лениво будет, и три буквы это уже ЦЕЛЫХ три буквы . . . хотя надо и себя нет нет пинать.



Sergei I. Gorelkin

1) Венгерскую нотацию (префиксы с типами) некоторые считают злом. В принципе, с современными IDE она действительно не так актуальна, как несколько лет назад, т.к. при наведении мышки на идентификатор мы видим его тип. Но это одно из мнений.

мышь это зло, использую не ради чтения, а ради автодополнения, больше 2 букв обычно не набираю.

Лучше меньше комментариев, зато по делу. Формальное требование "на 20 строк кода" может привести к тому, что код будет просто заспамлен.

после этого появится правило не чаше одного комента на 5 строчек =)
"по делу" трудно определить, для меня многое в коде как самособой разумеещеяся, типа присвания переменой, для других это уже сложно.

4) Я бы не стал объединять требования к gui и коду в одну кучу - все-таки это разные категории. Ну а в требованиях к gui есть смысл формализовать побольше: размеры кнопок, интервалы, шрифты, навигацию с клавиатуры и т.д.

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

6.3) По-хорошему, проверять на соответствие нужно перед каждым коммитом в svn. Иначе за 3 месяца могут такое наворотить, что еще месяц распрямлять придется...

согласен, но сидим не в конторе, а кто где может. по этому труднее с этим делом. а еще и авралы то вообще.

[B4rr4cuda]

мысль интересная, особенно когда комбобокс и чекбокс ,но передалывать лениво будет, и три буквы это уже ЦЕЛЫХ три буквы . . . хотя надо и себя нет нет пинать.

То что ЦЕЛЫХ три это точно , я для делфи ставил менеджер один, китайского производства, забыл как называется... Так вот он автоматом, при добавлении компонента на форму, менял имя, учитывая имя класса. Добавлял три буквы. С тех пор привык и продолжаю именовать именно так. В частности это

btStart кнопка

ненадолго ввело меня в гипнотический ступор , пытался найти недостающую n. =)

[Deepthroat]

btStart кнопка

ненадолго ввело меня в гипнотический ступор Smile, пытался найти недостающую n. =)

Ага, и со мной то же самое.

4,4 формы должны появлятся отцентрироваными на экране

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

[dymken]

1. Где-то были более-менее употребительные сокращения, там действительно: TGrid, TDBGrid - grd, кнопки - btn итп. Т.е. алгоритм (может Канту писал или еще кто, не помню) : убираем все гласные и повторные согласные. Так вот, я полагаю, лучше поискать этот список в инете и воспользоваться им, нежели придумывать свои сокращения.
P.S. Тоже bt режет глаз

2. Насчет комментариев согласен с Горелкиным: тривиальные методы можно не комментировать, к тому же многое говорит само название метода (если оно грамотно составлено). А вот сложные и запутанные алгоритмы, нужно и подробнее описать.

3. Тоже уж есть стандарт - как минимум сорцы VCL . В общем да, всегда 2 пробела, begin всегда с новой строки (за исключением else begin) ну итп.

Но в целом согласен: стандарту быть. Не только в коде, но и в ГУИ.
У нас тут работают один разработчики корпоративной системы. Так вот, кнопка "Закрыть" в разных формах принимает различные вариации: то справа внизу "Выход"/"Закрыть", то на панели инструментов значок с дверью, то просто никаких кнопок нет, а нужно нажимать крестик - очень путает и нервирует.
И еще, имхо, нужен стандарт на концептуальном уровне - метафоры итп.

Все имхо

[Attid]

Но в целом согласен: стандарту быть.

угу решил умную книжку почитать =)

[dymken]

Еще неплохая книга есть: Стив Макконелл "Совершенный код". Читал к сожалению не целиком, времени не хватает

[Padre_Mortius]

А я добавлю на нее ссылочку
Может пригодится кому-нить)

Модератор а я пожалуй её удалю для вашего же блага, только в личку.

[Attid]

добавил

Код: Выделить всё

4,5 формы должны появлятся отцентрироваными на экране

4,6 табордер должен быть логичным (проверять работу без мыши)
4,6,1 одинаковые действия должны быть одинаковы везде

4,7 каждая форма кроме диалогов должна иметь майн меню со всеми действиями.

4,8 каждая форма должна иметь кнопку(или минимум меню(?)) выхода, чтоб не закрывать по крестику

4,9 дабл клик на форме должен редактировать запись за исключением если форма диалоговая, тогда вобор записи и модал резулт = mr_ok

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

II как правельнее его разделить на юниты или побить на вкладывемые inc файлы

нужно для того чтоб проще разбираться\искать и делить между програмистами.

[Attid]

ну пока все молчат еще добавлю пока без циферок, потом перенумерую.

Код: Выделить всё

7, проверять при пустом датасете недоступность кнопок удалить и редактировать

8, проверять работоспособность форм с большим наполнением данными 
(как минимум в несколько раз превышающих визуальный обьем кроме случаев если на реально БД не может быть физически больше данных чем умещающие)
ЗЫ позволяет проверять как будет выглядеть со скролами

9,если предпологается большой набор данных ограничивать его физически (select first 100) 

10. не использовать * в запросах (select * from ..  и даже select count(*))

[vital]

"Стандарт стилевого оформления исходного кода Delphi":
http://www.delphikingdom.com/asp/viewitem.asp?catalogid=802

"Стандарты написания исходного кода в Delphi":
http://www.delphiplus.org/articles/delphi/source_code_standards/index.html

Ничего более подробного по сабжу мне пока не встречалось.

P.S. И велосипед изобретать не нужно

Ну и ещё...
Xavier Pacheco, Steve Teixeira "Delphi 4 Developer's Guide Coding Standards Document":
http://www.econos.de/delphi/cs.html

[Attid]

P.S. И велосипед изобретать не нужно Laughing

как отвечал ev в соседней ветки велосипед велосипеду рознь.

есть свои тонкости как и в среде так и в компании, за ссылки спасибо.

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