|
|
Регистрация | << Правила форума >> | FAQ | Пользователи | Календарь | Поиск | Сообщения за сегодня | Все разделы прочитаны |
|
Опции темы | Поиск в этой теме | Опции просмотра |
#1
|
||||
|
||||
Delphi code convensions
Коллеги, в недавнем прошлом я озаботился вопросом создания правил оформления Delphi кода, которым я мог бы неукоснительно следовать в своем проекте. В принципе, можно взять готовые от Embarcadero: http://edn.embarcadero.com/article/10280#2.2
Но хочется иметь на руках осмысленный набор правил. А для этого их хорошо бы обсудить, а где обсуждать, как не на форуме? Предлагаю начать. Сначала Borland, а теперь и Embarcadero, предлагает в начале каждого файла писать копирайт-блок вида: Код:
{*******************************************************} { } { Borland Delphi Visual Component Library } { } { Copyright (c) 1995,98 Inprise Corporation } { } {*******************************************************} 1) Зачем писать название проекта, если оно и так ясно из проджект груп? 2) Зачем писать копирайт, файл скорее всего, принадлежит компании/либо может быть ей использован? Другими словами зачем вообще этот блок? Невозможно заточить карандаш тупым топором. Столь же тщетно пытаться сделать это десятком тупых топоров |
#2
|
||||
|
||||
Цопирайт — права на распространение, лучше писать, что авторство принадлежит конкретно тебе.
Код:
{ потрачено.pas авторы: сидоджи, сладенький и большой дым } Тут скорее всего рассчитано на то, что кто-нить скачает, не сможет разобраться (ну или вопросы возникнут), он сможет с тобой связаться — Как тебя понимать? — Понимать меня не обязательно. Обязательно меня любить и кормить вовремя. На Delphi, увы, больше не программирую. Рекомендуемая литература по программированию Последний раз редактировалось M.A.D.M.A.N., 29.04.2014 в 09:32. |
#3
|
||||
|
||||
В свое время озадачивался аналогичным вопросом. В авторском праве есть понятие произведения и публикации. Когда код является произведением (то есть несет некую общественно полезную функцию), об этом нужно объявить и заодно указать, кто автор данного произведения. А годы, указываемые в копирайтах -- годы публикации произведения.
Выполнение этой нехитрой процедуры для кода и делается предлагаемой шапкой. Не стоит путать форумы с богадельнями. © Bargest |
#4
|
||||
|
||||
Цитата:
Тут вижу как минимум следующие проблемы: 1) Как быть с опенсорсной разработкой - ведении проекта где-нибудь на GitHub? Получается, что модуль выложен в открытый доступ(опубликован), практически сразу после создания в еще "сыром" виде. 2) Получится, что неопубликованные модули не соответствуют рекомендованному стандарту - это же нехорошо 3) Непонятно какую функцию несет копирайт. Ну разместили мы информацию о нем в модуле. Фактически, ничто не мешает кому-нибудь взять ваш модуль, изменить в нем блок копирайта и зарегистрировать как свой код - если вы не успели зарегистрировать свой. Другими словами, этот блок никого ни к чему не обязывает, а лишь информирует. Зачем нам эта информация в модулях - вот в чем вопрос. Лично мне больше нравится версия madman. Этот блок позволяет определить происхождение данного модуля. В итоге, можно обратится к разработчику за разъяснениями\более новыми версиями. В таком контексте использование копирайта мне кажется логичным. Кстати, коллеги, а кто-нибудь вообще пишет этот блок? Невозможно заточить карандаш тупым топором. Столь же тщетно пытаться сделать это десятком тупых топоров Последний раз редактировалось madMonia, 30.04.2014 в 11:42. |
#5
|
||||
|
||||
Если что-то универсальное делаю, то пишу пояснение, что это и зачем.
— Как тебя понимать? — Понимать меня не обязательно. Обязательно меня любить и кормить вовремя. На Delphi, увы, больше не программирую. Рекомендуемая литература по программированию |
#6
|
||||
|
||||
стандарт Jedi
Нашел еще в интернете стандрат, используемый командой джедаев.
Копирайт у них выглядит так: Код:
{******************************************************************************} { } { Project JEDI Code Library (JCL) } { } { The contents of this file are subject to the Mozilla Public License Version } { 1.0 (the "License"); you may not use this file except in compliance with the } { License. You may obtain a copy of the License at http://www.mozilla.org/MPL/ } { } { Software distributed under the License is distributed on an "AS IS" basis, } { WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License for } { the specific language governing rights and limitations under the License. } { } { The Original Code is JclGraphics.pas. } { } { The Initial Developer of the Original Code is documented in the accompanying } { help file JCL.chm. Portions created by these individuals are Copyright (C) } { 2000 of these individuals. } { } { Contains various graphics related classes and subroutines such as a Win32 } { regions encapsulatiion, a very fast TBitmap replacement and various } { transformation and filtering routines. } { } { Unit owner: Wim de Cleen } { Last modified: June 7, 2000 } { } {******************************************************************************} Как мы видим инфа следующая: 1) Название проекта 2) Более менее подробное описание лицензии 3) Краткое описание цели модуля 4) Владелец модуля 5) Дата последней модификации модуля На мой взгляд: 1) Название проекта имеет смысл, если речь идет о названии исходного проекта откуда модуль взят. Тоесть, при использовании чужих модулей без переработки следуюет оставить информацию откуда модуль был взят 2) Описание лицензии - чушь. Хватит название проекта, дальше нагуглить инфу (или централизованно хранить для всех модулей этого проетка) вполне можно. Максимум можно краткую инфу - не более одной строки. 3) Краткое описание цели модуля - дело полезное 4) Владелец модуля - чушь. Может у JEDI и есть четко закрепленный владелец для каждого модуля, но в реальных условиях такого может и не быть. Вся необходимая информация должна содержаться в VCS. 5) Дата изменения - еще большая чушь, бессмысленное дублирование инфы. Ваше мнение коллеги? Невозможно заточить карандаш тупым топором. Столь же тщетно пытаться сделать это десятком тупых топоров |
#7
|
||||
|
||||
Цитата:
По поводу овнера вопрос тоже спорный, допустим произошла ситуация, как в абзаце выше, я по фамилии могу найти чувака и его лично спросить. — Как тебя понимать? — Понимать меня не обязательно. Обязательно меня любить и кормить вовремя. На Delphi, увы, больше не программирую. Рекомендуемая литература по программированию Последний раз редактировалось M.A.D.M.A.N., 30.04.2014 в 13:07. |
#8
|
||||
|
||||
Мне кажется все намного проще. Дело в том, что филиалы одной компании занимающийся разработкой программного обеспечения, обычно обмениваются исходниками и во избежании путаницы с разными версиями, стали лепить такой копирайт с авторством и датой.
Жизнь такова какова она есть и больше никакова. Помогаю за спасибо. |
#9
|
||||
|
||||
Ну если использовать дату изменения для отслеживания версии модуля...
Не уверен, что это может принести реальную пользу, а постоянный гемор с отслеживание соответствия заголовка реальному положению вещей будет. С автором, конечно вопрос - по идее конкретного человека проще найти, чем кого-то из JEDI Team, который знает про этот модуль. С другой стороны: 1) Существование модуля, про который из всей команды знает только один человек, - это зло 2) Что делать с ситуацией, когда один человек написал модуль, а другой внес изменения - кто из них автор? Ну или владелец по логике JEDI Невозможно заточить карандаш тупым топором. Столь же тщетно пытаться сделать это десятком тупых топоров |
#10
|
||||
|
||||
Цитата:
Цитата:
Поэтому в открытых проектах вместо одной даты чаще всего стоит период, соответствующий всему периоду открытой разработки. Если проект подбирает другая команда или делается форк проекта, начинается новый период, что отражается в копирайтах. По мере переписывания и отхода от первоисточника копирайты прошлой команды вначале становятся просто упоминанием, а потом исчезают вовсе. Цитата:
Любители писать слово "свобода" даже на заборах вставляют свою молитву и в блок авторских прав. Здравомыслящие же люди исходят из того, что код, выложенный в открытый доступ, самим фактом выкладывания подразумевает открытость и не парятся по поводу лицензий, выбирая что-то простое из двух-трех пунктов. Цитата:
Не стоит путать форумы с богадельнями. © Bargest |
#11
|
||||
|
||||
Я делаю так:
1. Для опен-сорс проектов - подписываюсь, проставляю год написания, пишу под какой лицензией код. 2. Для проектов, которые вряд ли когда-либо покинут пределы моего компа, но вероятность возможна - просто пишу в шапке адрес своего сайта и краткое описание "а о чём это я". 3. Для проектов внутри компании, в которой я работаю - следуем указаниям тимлида по оформлению кода Оставайтесь хорошими людьми... VK id2634397, ds [at] phoenix [dot] dj |
#12
|
||||
|
||||
Цитата:
А если тимлид - это ты? Невозможно заточить карандаш тупым топором. Столь же тщетно пытаться сделать это десятком тупых топоров |
#13
|
||||
|
||||
Цитата:
Часто тимлид действует не по собственному усмотрению, а по стандарту, разработанному однажды внутри компании (возможно, состоящему из предпочтений этого тимлида, но все же). Я для своих наработок (которые пределы моего компа редко покидают) просто пишу название файла, его краткое описание, автора и год изменения. Название - чтобы знать оригинальное имя, если файл придет кому-то, например, с именем в виде MD5. Описание - чтобы знать, зачем файл. Автора - чтобы знать, к кому обращаться, и год, чтобы знать, насколько это древний файл (думаю, в 2050 году будет не особо полезно возиться с моими наработками под Real-Mode x86) Что касается лицензии - имхо, глупо писать ее в тексте файла. Те, кому на лицензию собственно плевать (а я уверен, таких 98%), ее просто-напросто удалят или проигнорируют, или же просто скопипастят интересующие куски кода. А те, кому не плевать, посмотрят на лицензию в соответствующем прилагаемом файле (в котором будет написано что-то вроде WTFPL). jmp $ ; Happy End! The Cake Is A Lie. Последний раз редактировалось Bargest, 03.05.2014 в 19:01. |
Этот пользователь сказал Спасибо Bargest за это полезное сообщение: | ||
Freeman (04.05.2014)
|
#14
|
||||
|
||||
Моё мнение о вашей дискуссии:
— Как тебя понимать? — Понимать меня не обязательно. Обязательно меня любить и кормить вовремя. На Delphi, увы, больше не программирую. Рекомендуемая литература по программированию |
Эти 2 пользователя(ей) сказали Спасибо M.A.D.M.A.N. за это полезное сообщение: | ||
Bargest (03.05.2014),
dr. F.I.N. (03.05.2014)
|
#15
|
||||
|
||||
Цитата:
Не стоит путать форумы с богадельнями. © Bargest |
Этот пользователь сказал Спасибо Freeman за это полезное сообщение: | ||
Alegun (04.05.2014)
|