>>Венгерскую нотацию (префиксы с типами) некоторые считают злом
Я бы сказал что ее сделали злом
Изначально она была придумана для того чтобы отличать правильный код от неправильного.[url]http://ru.wikipedia.org/wiki/Венгерская_нотация[/url]
[url]http://local.joelonsoftware.com/mediawiki/index.php/Как_заставить_неправильный_код_выглядеть_неправильно[/url]
Статистика: Добавлено kik13 — 02.03.2008 05:03:05
]]>
А если в count впихнуть все поля таблицы, то он будет действовать аналогично count(*) (надо проверить), но последнее быстрее, так как экономится операция проекции.
монописуально как и COUNT(1)
Статистика: Добавлено Attid — 03.02.2008 10:27:11
]]>
COUNT(*) будет разбираться быстрее, чем COUNT(имя_поля)
Первое вернет количество строк в таблице - то, что обычно и требуется получить. Второе, насколько я понимаю, вернет количество строк с не NULL в поле имя_поля? Ну так это разные вещи.
А если в count впихнуть все поля таблицы, то он будет действовать аналогично count(*) (надо проверить), но последнее быстрее, так как экономится операция проекции.
Статистика: Добавлено Deepthroat — 02.02.2008 20:17:00
]]>
COUNT(*) returns the number of items in a group, including NULL values and duplicates.
COUNT(ALL expression) evaluates expression for each row in a group and returns the number of nonnull values.
COUNT(DISTINCT expression) evaluates expression for each row in a group and returns the number of unique, nonnull values.
Взято из описания TransactSQL
Статистика: Добавлено Padre_Mortius — 31.01.2008 13:37:00
]]>
Статистика: Добавлено alexs — 31.01.2008 11:48:07
]]>
Vadim писал(а):COUNT(*) будет разбираться быстрее, чем COUNT(имя_поля).
а ты знаешь что это разные вещи и вернет разные результаты ?
тогду уж лучше попробуй COUNT(1)
Статистика: Добавлено Attid — 31.01.2008 11:34:20
]]>
COUNT(*) будет разбираться быстрее, чем COUNT(имя_поля).
Статистика: Добавлено Vadim — 31.01.2008 11:06:27
]]>
]]>
10. не использовать * в запросах (select * from .. и даже select count(*))
Насчет select count не согласен. Его так и надо использовать:
Код:
SELECT COUNT(*)
FROM table_name
WHERE <predicate>;
Зачем тратить драгоценное время на проекцию? Это уже квадратное колесо выходит.
Статистика: Добавлено Deepthroat — 31.01.2008 00:25:11
]]>
Дык, стандарт он потому и стандарт, что не свой у каждого
это я про велосипед отвечал, когда еще не прочитал что там за ссылки. тема же про правила програмирования а не форматированию кодеа, которое занимает одну строчку из правил .
так что на консерваторию попрошу не покушаться.
Статистика: Добавлено Attid — 29.01.2008 14:12:47
]]>
Attid писал(а):
как отвечал ev в соседней ветки велосипед велосипеду рознь.
есть свои тонкости как и в среде так и в компании, за ссылки спасибо.
от туда стиль коментирования распешу, а форматирование надо будет все равно утилитой, а регстр можно в словарь запихнуть и его в свн запихнуть.
P.S. И велосипед изобретать не нужно Laughing
как отвечал ev в соседней ветки велосипед велосипеду рознь.
есть свои тонкости как и в среде так и в компании, за ссылки спасибо.
от туда стиль коментирования распешу, а форматирование надо будет все равно утилитой, а регстр можно в словарь запихнуть и его в свн запихнуть.
Дык, стандарт он потому и стандарт, что не свой у каждого:) ИМХО, форматирование и регистр - это просто неотъемлимая часть процесса кодирования, т.е. такие вещи должны выполняться на автомате. Я себя приучил и при наборе текста это само собой разумеется(самому же проще по своим же исходникам лазить:)). По-моему, если имеет место кодирование как попало и последующее интенсивное использование форматтеров, значит "в консерватории что-то поправить нужно"(с)
Статистика: Добавлено vital — 29.01.2008 13:40:33
]]>
P.S. И велосипед изобретать не нужно Laughing
как отвечал ev в соседней ветки велосипед велосипеду рознь.
есть свои тонкости как и в среде так и в компании, за ссылки спасибо.
от туда стиль коментирования распешу, а форматирование надо будет все равно утилитой, а регстр можно в словарь запихнуть и его в свн запихнуть.
Статистика: Добавлено Attid — 29.01.2008 13:07:12
]]>
"Стандарты написания исходного кода в 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
Статистика: Добавлено vital — 29.01.2008 12:30:38
]]>
Код:
7, проверять при пустом датасете недоступность кнопок удалить и редактировать
8, проверять работоспособность форм с большим наполнением данными
(как минимум в несколько раз превышающих визуальный обьем кроме случаев если на реально БД не может быть физически больше данных чем умещающие)
ЗЫ позволяет проверять как будет выглядеть со скролами
9,если предпологается большой набор данных ограничивать его физически (select first 100)
10. не использовать * в запросах (select * from .. и даже select count(*))Статистика: Добавлено Attid — 29.01.2008 12:16:59
]]>
Код:
4,5 формы должны появлятся отцентрироваными на экране
4,6 табордер должен быть логичным (проверять работу без мыши)
4,6,1 одинаковые действия должны быть одинаковы везде
4,7 каждая форма кроме диалогов должна иметь майн меню со всеми действиями.
4,8 каждая форма должна иметь кнопку(или минимум меню(?)) выхода, чтоб не закрывать по крестику
4,9 дабл клик на форме должен редактировать запись за исключением если форма диалоговая, тогда вобор записи и модал резулт = mr_ok
вот еще вопрос про рефакторинг кода.
какой нибуть юнит со временем разрастается, но в нем всегда можно выделить что-то и вынести. и это можно засунуть в правила
вопрос
I с какого момента считать юнит слишком большим ? (типа если с одной процедурой понятно что типа на экран, с юнитом вроде как пока не устанешь в нем искать =) ) может есть какие-то понятия в этом смысле ?
II как правельнее его разделить на юниты или побить на вкладывемые inc файлы
нужно для того чтоб проще разбираться\искать и делить между програмистами.
Статистика: Добавлено Attid — 29.01.2008 00:43:11
]]>
Модератор а я пожалуй её удалю для вашего же блага, только в личку.
Статистика: Добавлено Padre_Mortius — 28.01.2008 20:11:20
]]>
Статистика: Добавлено dymken — 28.01.2008 16:51:25
]]>
Но в целом согласен: стандарту быть.
угу решил умную книжку почитать =)
Статистика: Добавлено Attid — 28.01.2008 13:17:44
]]>
2. Насчет комментариев согласен с Горелкиным: тривиальные методы можно не комментировать, к тому же многое говорит само название метода (если оно грамотно составлено). А вот сложные и запутанные алгоритмы, нужно и подробнее описать.
3. Тоже уж есть стандарт - как минимум сорцы VCL
. В общем да, всегда 2 пробела, begin всегда с новой строки (за исключением else begin) ну итп.Но в целом согласен: стандарту быть. Не только в коде, но и в ГУИ.
У нас тут работают один разработчики корпоративной системы. Так вот, кнопка "Закрыть" в разных формах принимает различные вариации: то справа внизу "Выход"/"Закрыть", то на панели инструментов значок с дверью, то просто никаких кнопок нет, а нужно нажимать крестик - очень путает и нервирует.
И еще, имхо, нужен стандарт на концептуальном уровне - метафоры итп.
Все имхо
Статистика: Добавлено dymken — 28.01.2008 09:02:00
]]>
btStart кнопка
ненадолго ввело меня в гипнотический ступор Smile, пытался найти недостающую n. =)
Ага, и со мной то же самое.
4,4 формы должны появлятся отцентрироваными на экране
Лично я всегда делаю, чтобы запоминалось расположение формы при закрытии. Тогда форма откроется там, где пользователь ее бросил. Начал делать так после того, как попользовался одной программой, которую все время ставил в угол, а она, сцуко, всегда появлялась в центре экрана. В конце-концов нервы не выдержали
Статистика: Добавлено Deepthroat — 28.01.2008 00:26:32
]]>
мысль интересная, особенно когда комбобокс и чекбокс ,но передалывать лениво будет, и три буквы это уже ЦЕЛЫХ три буквы . . . хотя надо и себя нет нет пинать.
То что ЦЕЛЫХ три это точно
, я для делфи ставил менеджер один, китайского производства, забыл как называется... Так вот он автоматом, при добавлении компонента на форму, менял имя, учитывая имя класса. Добавлял три буквы. С тех пор привык и продолжаю именовать именно так. В частности это ненадолго ввело меня в гипнотический ступорbtStart кнопка
, пытался найти недостающую n. =)Статистика: Добавлено B4rr4cuda — 27.01.2008 23:30:41
]]>
Brainenjii писал(а):Ммм.. А почему на форме должна быть только одна транзакция?
правила формируются некоторые по правилам которые шепчет логика , другие создаются когда разработчики любят наступать на грабли много раз.
транзакции и интерфейс относятка ко вторым, придуманы сегодня, когда патался разобраться в коде который был закручен по не болуйся, что сам разработчик забыл где какие концы.
а вообще с птичкой видел только 2 возможности.
1, одна транзакция на приложение
2, одна транзакция на форму.
или то же самое по 2 транзакции если используется пищущая и читающая.
остальное от лукавого.у меня 2 транзакции выигрыша пока нету.
B4rr4cuda
Обычно, для улучшения читаемости, используется трехбуквенное обозначение класса:
мысль интересная, особенно когда комбобокс и чекбокс ,но передалывать лениво будет, и три буквы это уже ЦЕЛЫХ три буквы . . . хотя надо и себя нет нет пинать.
Sergei I. Gorelkin
1) Венгерскую нотацию (префиксы с типами) некоторые считают злом. В принципе, с современными IDE она действительно не так актуальна, как несколько лет назад, т.к. при наведении мышки на идентификатор мы видим его тип. Но это одно из мнений.
мышь это зло, использую не ради чтения, а ради автодополнения, больше 2 букв обычно не набираю.
Лучше меньше комментариев, зато по делу. Формальное требование "на 20 строк кода" может привести к тому, что код будет просто заспамлен.
после этого появится правило не чаше одного комента на 5 строчек =)
"по делу" трудно определить, для меня многое в коде как самособой разумеещеяся, типа присвания переменой, для других это уже сложно.
4) Я бы не стал объединять требования к gui и коду в одну кучу - все-таки это разные категории. Ну а в требованиях к gui есть смысл формализовать побольше: размеры кнопок, интервалы, шрифты, навигацию с клавиатуры и т.д.
как сказал выше это чисто местное, когда работал в МВ там было правило все действия в акшенах, на каждое действие должно быть меню, горячий кнопка, при необходимости кнопка на форме., про таб забыл, сча допишу =)
6.3) По-хорошему, проверять на соответствие нужно перед каждым коммитом в svn. Иначе за 3 месяца могут такое наворотить, что еще месяц распрямлять придется...
согласен, но сидим не в конторе, а кто где может. по этому труднее с этим делом. а еще и авралы то вообще.
Статистика: Добавлено Attid — 27.01.2008 22:03:01
]]>
2) Лучше меньше комментариев, зато по делу. Формальное требование "на 20 строк кода" может привести к тому, что код будет просто заспамлен.
4) Я бы не стал объединять требования к gui и коду в одну кучу - все-таки это разные категории. Ну а в требованиях к gui есть смысл формализовать побольше: размеры кнопок, интервалы, шрифты, навигацию с клавиатуры и т.д.
6.3) По-хорошему, проверять на соответствие нужно перед каждым коммитом в svn. Иначе за 3 месяца могут такое наворотить, что еще месяц распрямлять придется...
Статистика: Добавлено Sergei I. Gorelkin — 27.01.2008 18:57:08
]]>
1, Имена должны быть логичны и содержать клас компонента в начале названия
gMain грид
btStart кнопка
cbDevItems комбик
Обычно, для улучшения читаемости, используется трехбуквенное обозначение класса:
Код:
grdMain грид
btnStart кнопка
cbbDevItems комбикСтатистика: Добавлено B4rr4cuda — 27.01.2008 17:32:14
]]>
]]>
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 — 27.01.2008 14:11:28
]]>