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

Форум для изучающих FPC и их учителей.

Модератор: Модераторы

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

Сообщение Attid » 27.01.2008 15:11:28

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


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(*))
Последний раз редактировалось Attid 29.01.2008 13:17:48, всего редактировалось 2 раз(а).
Аватара пользователя
Attid
долгожитель
 
Сообщения: 2585
Зарегистрирован: 27.10.2006 17:29:15
Откуда: 44°32′23.63″N 41°2′25.2″E

Сообщение Brainenjii » 27.01.2008 16:26:40

Ммм.. А почему на форме должна быть только одна транзакция?
Аватара пользователя
Brainenjii
энтузиаст
 
Сообщения: 1351
Зарегистрирован: 10.05.2007 00:04:46

Сообщение B4rr4cuda » 27.01.2008 18:32:14

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

Обычно, для улучшения читаемости, используется трехбуквенное обозначение класса:
Код: Выделить всё
grdMain грид
btnStart кнопка
cbbDevItems комбик
Аватара пользователя
B4rr4cuda
энтузиаст
 
Сообщения: 693
Зарегистрирован: 28.12.2007 07:48:35

Сообщение Sergei I. Gorelkin » 27.01.2008 19:57:08

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

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

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

6.3) По-хорошему, проверять на соответствие нужно перед каждым коммитом в svn. Иначе за 3 месяца могут такое наворотить, что еще месяц распрямлять придется...
Аватара пользователя
Sergei I. Gorelkin
энтузиаст
 
Сообщения: 1395
Зарегистрирован: 24.07.2005 14:40:41
Откуда: Зеленоград

Сообщение Attid » 27.01.2008 23:03:01

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

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

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

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



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

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

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

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

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

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

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

согласен, но сидим не в конторе, а кто где может. по этому труднее с этим делом. а еще и авралы то вообще.
Аватара пользователя
Attid
долгожитель
 
Сообщения: 2585
Зарегистрирован: 27.10.2006 17:29:15
Откуда: 44°32′23.63″N 41°2′25.2″E

Сообщение B4rr4cuda » 28.01.2008 00:30:41

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

То что ЦЕЛЫХ три это точно :) , я для делфи ставил менеджер один, китайского производства, забыл как называется... Так вот он автоматом, при добавлении компонента на форму, менял имя, учитывая имя класса. Добавлял три буквы. С тех пор привык и продолжаю именовать именно так. В частности это
btStart кнопка
ненадолго ввело меня в гипнотический ступор :), пытался найти недостающую n. =)
Аватара пользователя
B4rr4cuda
энтузиаст
 
Сообщения: 693
Зарегистрирован: 28.12.2007 07:48:35

Сообщение Deepthroat » 28.01.2008 01:26:32

btStart кнопка

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

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

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

Лично я всегда делаю, чтобы запоминалось расположение формы при закрытии. Тогда форма откроется там, где пользователь ее бросил. Начал делать так после того, как попользовался одной программой, которую все время ставил в угол, а она, сцуко, всегда появлялась в центре экрана. В конце-концов нервы не выдержали :lol:
Аватара пользователя
Deepthroat
постоялец
 
Сообщения: 144
Зарегистрирован: 06.09.2007 00:21:34
Откуда: Outer Heaven

Сообщение dymken » 28.01.2008 10:02:00

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

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

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

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

Все имхо :)
dymken
новенький
 
Сообщения: 11
Зарегистрирован: 10.01.2008 11:50:14

Сообщение Attid » 28.01.2008 14:17:44

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

угу решил умную книжку почитать =)
Аватара пользователя
Attid
долгожитель
 
Сообщения: 2585
Зарегистрирован: 27.10.2006 17:29:15
Откуда: 44°32′23.63″N 41°2′25.2″E

Сообщение dymken » 28.01.2008 17:51:25

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

Сообщение Padre_Mortius » 28.01.2008 21:11:20

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

Модератор а я пожалуй её удалю для вашего же блага, только в личку.
Padre_Mortius
энтузиаст
 
Сообщения: 1265
Зарегистрирован: 29.05.2007 17:38:07
Откуда: Спб

Сообщение Attid » 29.01.2008 01:43:11

добавил
Код: Выделить всё
4,5 формы должны появлятся отцентрироваными на экране

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

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

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

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


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

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

нужно для того чтоб проще разбираться\искать и делить между програмистами.
Аватара пользователя
Attid
долгожитель
 
Сообщения: 2585
Зарегистрирован: 27.10.2006 17:29:15
Откуда: 44°32′23.63″N 41°2′25.2″E

Сообщение Attid » 29.01.2008 13:16:59

ну пока все молчат еще добавлю пока без циферок, потом перенумерую.
Код: Выделить всё
7, проверять при пустом датасете недоступность кнопок удалить и редактировать

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

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

10. не использовать * в запросах (select * from ..  и даже select count(*))
Аватара пользователя
Attid
долгожитель
 
Сообщения: 2585
Зарегистрирован: 27.10.2006 17:29:15
Откуда: 44°32′23.63″N 41°2′25.2″E

Сообщение vital » 29.01.2008 13:30:38

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

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

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

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

Ну и ещё...
Xavier Pacheco, Steve Teixeira "Delphi 4 Developer's Guide Coding Standards Document":
http://www.econos.de/delphi/cs.html
vital
новенький
 
Сообщения: 86
Зарегистрирован: 17.10.2007 14:52:59

Сообщение Attid » 29.01.2008 14:07:12

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


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

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

от туда стиль коментирования распешу, а форматирование надо будет все равно утилитой, а регстр можно в словарь запихнуть и его в свн запихнуть.
Аватара пользователя
Attid
долгожитель
 
Сообщения: 2585
Зарегистрирован: 27.10.2006 17:29:15
Откуда: 44°32′23.63″N 41°2′25.2″E

След.

Вернуться в Обучение Free Pascal

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 6

Рейтинг@Mail.ru