сидел писал правила разработки для своего маленького коллектива , решил предоставить их на общий суд может кто чего из личного опыта добавит
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(*))
, я для делфи ставил менеджер один, китайского производства, забыл как называется... Так вот он автоматом, при добавлении компонента на форму, менял имя, учитывая имя класса. Добавлял три буквы. С тех пор привык и продолжаю именовать именно так. В частности это 
