Евгений Б.
5330 сообщений
#13 лет назад
Цитата ("wrc"):
Нужно ОБОСНОВАТЬ использование какого-то конкретного стандарта.

ну да, я могу с пол литры обосновать переменные вида kjdghskdjghsdv
обоснование простое, что бы никто не догадался.. потенциальный враг в принципе ничего не понял.

ну есть правила оформления кода и что? есть и госты по этому поводу.. может лучше нормативку смотреть, если перед оборонкой отчитываться потом?
Андрей Чепурной
598 сообщений
#13 лет назад
Цитата:
Я вообще в нём мало разбираюсь
вот как то меня это убило...
Гость
405 сообщений
#13 лет назад
Цитата ("MMM_Corp"):
Да не, что вы на человека набросились, все правильно, хочет что то знать, хочет порядка.

wrc, как идея, одна голова хорошо, а 2 еще лучше, намного эффективней будет собрать несколько дельфийцев со стажем, и провести платный холивар по САБЖу, старые кануны устарели, и требуют переоценки, новые идеи, новые возможности и взгляды, уверен к такому мероприятию будет много внимания, и вам сделаем хорошо и для общества пользу, в виде новых какунов форматирования кода, да и проекта в целом. Один человек просто будет навязывать свой взгляд, а это не хорошо однозначно!

MMM_Corp, вы дело говорите, именно и хотелось бы услышать мнение знающих людей, которые придерживаются какого-то стандарта. Я готов с моего тендера бюджет перекачать в платный холивар. Это конечно капля в море, может только на пиво хватит. Не судите строго, моя ситуация не позволяет сейчас больше. Может кому-то из заказчиков тоже нужна конвенция и могут присоединиться финансово.
Николай М.
1895 сообщений
#13 лет назад
Ну тогда я хочу холивара)))

из профи делфийцев из фриланса могу предложить еще фрилансера Virston, возможно и ему будет это интересно

вам нужно определится с критериями холивара, местом и гарантом оплаты, думаю одного дня на это мероприятие будет достаточно, также нужна мотивация, возможно есть ещё заказчики, которые будут заинтересованы, возможно студии разработки (таких не рекомендую по причине что не знаком с такими), в прочем нужно начать сбор фрилансеров с ТОП-10 с прикладного программирования и таких же заказчиков, которые заказывают "на лево", также наверное вам потребуется разрешение администрации, поскольку если будет это мероприятие здесь, то лучше конечно ничего не нарушать и такие меры должны конечно бить легально контролированными
Гость
405 сообщений
#13 лет назад
Цитата ("MMM_Corp"):
Ну тогда я хочу холивара)))

из профи делфийцев из фриланса могу предложить еще фрилансера Virston, возможно и ему будет это интересно

вам нужно определится с критериями холивара, местом и гарантом оплаты, думаю одного дня на это мероприятие будет достаточно, также нужна мотивация, возможно есть ещё заказчики, которые будут заинтересованы, возможно студии разработки (таких не рекомендую по причине что не знаком с такими), в прочем нужно начать сбор фрилансеров с ТОП-10 с прикладного программирования и таких же заказчиков, которые заказывают "на лево", также наверное вам потребуется разрешение администрации, поскольку если будет это мероприятие здесь, то лучше конечно ничего не нарушать и такие меры должны конечно бить легально контролированными

Вы думаете реально найти ещё заказчиков, кому нужна конвенция? Вы кого-то конкретно имеете в виду?

Позвольте я сформулирую мою проблему другими словами ещё раз, чтобы было понятно зачем оно надо.

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

Хотелось бы услышать мнения професииональных Delphi программистов, какую именно конвенцию они используют и почему. Её преимущества и недостатки. Особый упор нужно сделать на комментарии и изящество кода. То есть, чтобы конвенция напрягала кодеров хорошо комментировать свой код, и по-возможности поддерживать его в управляемом состоянии.

Например, расммотрим сценарий, когда 1 кодер работает над проектом год-два и потом уходит. Второй кодер должен без особых проблем включиться в проект и быстро разобраться с ним. Надеюсь, понятно написал.
Николай М.
1895 сообщений
#13 лет назад
Проблема понятна, на себе испробована когдато, легко решается с помощью и соответствующим форматированием комментариев, правда удивляет что бардак в файлах проекта никого не волнует, а меня очень даже... и все делаю для удобного разбиения по полочкам не только в среде но и в файлах, кстати можете не искать, стандартов тоже не писано никаких)))

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

но! стать одним из автором конвенции по форматировании кода современного Делфиста,...
Гость
405 сообщений
#13 лет назад
Цитата ("MMM_Corp"):
... кстати можете не искать, стандартов тоже не писано никаких ...

Мне как-то слабо верится, что стандартов нет. Мне кажется должны быть конторы, которые занимаются более менее правильной разработкой софта на Delphi в командах более чем 2 чел., и я хотел бы знать какие стандарты они используют и по каким причинам.
Вадим Т.
3240 сообщений
#13 лет назад
wrc, пожалуйста посмотрите тут:

Вообще, хороший сайт. Там приводится несколько стандартов. То, что приведенные стандарты староваты, не является их недостатком.

==
Так как это раздел форума "Общение", то выскажусь:

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

2. Писать свой Code Conventions считаю делом неблагодарным. Так как это сродни изобретению велосипеда со всеми вытекающими (потери времени, ошибки, и т.д.). Эту задачу лучше оставлять крупным компаниям у которых для этого есть специальные люди, в идеале — самим идеологам и создателям того или иного языка.

3. Также, передавая кому-то проект, например другой команде на разработку, или продавая проект/бизнес кому-либо, и т.д. намного проще и эффективнее (и солиднее) сослаться на широко распространенный авторитетный Code Convention, а не снабжать продукт своими дополнительными документами с описаниями своего стандарта.

4. Полное соответствие авторитетным соглашениям кодирования является важной составляющей качества кода. И, соответственно, стандартизованный код имеет большую ценность, то есть стоит дороже.
Вадим Т.
3240 сообщений
#13 лет назад
Цитата ("wrc"):
Годится ли например эта ?

Кстати, вполне годится.

Тут еще интересно, что если через какое-то время придете к тому, что тот или иной стандарт Вам не подходит, то относительно несложно перейти на другой стандарт кодирования, который подходит.
Это не так долго и дорого как кажется, учитывая возможности программ-форматировщиков и технологии рефакторинга.
Даже на довольно немелких проектах, вплоть до человеко-года разработки, переход на другой стандарт кодирования может занять лишь несколько часов-день, при условии что текущий код сам по себе стандартизован.
Гость
405 сообщений
#13 лет назад
Цитата ("tvv"):
wrc, пожалуйста посмотрите тут:

Вообще, хороший сайт. Там приводится несколько стандартов. То, что приведенные стандарты староваты, не является их недостатком.

tvv, спасибо, но вроде бы для Delphi это тот же самый документ, что я привёл в изначальном посте.

Если следовать этому стандарту - то почему именно этому?

Возможно надо задать вопрос по-другому: каким образом обеспечить хотя бы приемлемое комментирование кодером того, что он / она пишет? Сегодня посмотрел на код и ужаснулся. Комментов практически нет. Видимо предполагалось, что всё очевидно.
Вадим Т.
3240 сообщений
#13 лет назад
Цитата ("wrc"):
Если следовать этому стандарту - то почему именно этому?

Чтобы ответить на этот вопрос, нужно взять список разных стандартов, определить чем они друг от друга отличаются (отличий обычно относительно немного), и оценить достоинства и недостатки каждого.
Сожалею что не могу помочь с этим, так как на Делфи не кодил где-то последние лет 8.
Могу показать лишь общий подход, если есть сомнения, то лучше выбирать самый авторитетный и распространенный стандарт. На самом деле выбор того или иного стандарта кодирования не так принципиален, зато факт того, использовать ли стандарт или вобще не использовать, абсолютно принципиален.

Цитата ("wrc"):
Возможно надо задать вопрос по-другому: каким образом обеспечить хотя бы приемлемое комментирование кодером того, что он / она пишет? Сегодня посмотрел на код и ужаснулся. Комментов практически нет. Видимо предполагалось, что всё очевидно.

1. Требовать. А как иначе? Желательно формально, прямо указывая в спеке проекта. Указывая критерии качественного кода, в том числе полное соблюдение такого-то стандарта кодирования, полное покрытие комментариями на грамотном английском языке всех классов, паблик и протектед методов и т.д.

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

3. Нанять на стороне эксперта (а лучше двух-трех, причем не обязательно дорогих и понтовитых), который/которая/которые раз в неделю будет ревьюить код, и писать отчет о состоянии проекта (обычно это 2-4 часа в неделю, выходит недорого). Если напишет что с кодом не так, и это соответствует спеке, и Вы с этим соглсаны, разработчик обязан исправить. Это тоже нужно формально зафиксировать с разработчиком формально, чтобы он подчинялся инструкции от эксперта, заапрувленной заказчиком (Вами).
Вадим Т.
3240 сообщений
#13 лет назад
Почему важно это формализировать... Приведу мои примеры, думаю, будет понятно:

— Комментировать код? А где в ТЗ написано, что код нужно комментировать? Мы можем это сделать, но это займет время, и заказчику будет стоить +10% стоимости проекта. (я выступал экспертом, указывал про отсутствие коментов в каждом отчете, это ответ менеджера разработчиков)

— Да, комментарии на русском языке. А что тут такого, мы же с Вами оба русскоязычные? (я был заказчиком, в ТЗ написал о необходимости комментов, расписал стандарты и принципы комментирования, но забыл указать, что должны быть на английском языке)

— Этот товарищ, которого вы нам навязали, зацикленный параноик, и вообще болен на голову. Если он такой умный, то пусть сам пишет вам код. Вернуть предоплату? Еще чего, мы же уже два месяца работаем. (это тимлид написал заказчику, я выступал экспертом, проект по разработке безопасных хранилищ информации)

— Мы не согласны ни с одним существующим стандартом кодирования. Более того, у каждого в нашей команде свое мнение как писать код, и я не буду заставлять моих ребят писать так, как они не хотят. Если уж вы настаиваете на стандарте, в конце проекта весь код прогоним через форматировщик. Или доплачивайте. (заказчик, который является моим хорошим знакомым, попал... этот разговор с командой был у него через три месяца после старта проекта, когда он попросил меня бегло проревьюить код)
Евгений Б.
5330 сообщений
#13 лет назад
Ну вот то, что есть

ГОСТ 19.101-77
ГОСТ 34.201-89 - ТП, Описание программного обеспечения
РД 50-34.698-90 - раздел 6. ТРЕБОВАНИЯ К СОДЕРЖАНИЮ ДОКУМЕНТОВ С РЕШЕНИЯМИ ПО ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ

ГОСТ 19.401-78 (СТ СЭВ 3746-82)ТЕКСТ ПРОГРАММЫ. ТРЕБОВАНИЯ К СОДЕРЖАНИЮ И ОФОРМЛЕНИЮ
Постановлением Государственного комитета СССР по стандартам от 18 декабря 1978 г. № 3350 срок введения установлен
с 01.01. 1980 г.
Владимир С.
581 сообщение
#13 лет назад
MMM_Corp, Вы применяете по разному :
'=True'
'= true'
'=true'


при использовании автоматического форматирования данные вопросы отпадают, настроить можно по выбранным стандартам.
Николай М.
1895 сообщений
#13 лет назад
Virtson, мне было интересно, насколько люди внимательны... ну хоть вы присмотрелись, а то все кричат, кричат...) да я в курсе что можно и без равно тру, но я лично пишу, так удобнее читать, и удобнее сменить тру на фелс
Владимир С.
581 сообщение
#13 лет назад
Оффтопик
MMM_Corp, за упоминание меня спасибо. Потрудиться на благо Delphi - сообщества я готов, при наличии времени =)
.
Топик-стартеру - подобную тему лучше поднимать здесь :

или
Гость
405 сообщений
#13 лет назад
Цитата ("tvv"):
Почему важно это формализировать... Приведу мои примеры ...

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

Это заставило улыбнуться.

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

Тему закрываю. Если кому-то будет интересно с какой конвенцией остановились в результате - спрашивайте в личке. Думаю это вопрос пары дней. Спасибо.