Страница 2 из 3

Re: Правила в разделе авторского кода

Добавлено: 2014.08.10, 01:50
samdark
Во многих моих расширениях для 1.1 тоже Composer-а нет... всё никак не добавлю.

Тема актуальная, конечно. Для 2.0 мы прям в гайде написали на тему «как сделать нормальное расширение»: https://github.com/yiisoft/yii2/blob/ma ... ensions.md

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

Re: Правила в разделе авторского кода

Добавлено: 2014.08.10, 01:51
zelenin
mickgeek писал(а):zelenin, по теме я высказывался на первой странице. Внимательнее надо читать сообщения)
внимательно прочел все сообщения. то, что один раз высказался, не означает, что миссия выполнена.

Re: Правила в разделе авторского кода

Добавлено: 2014.08.10, 01:54
zelenin
Sam Dark писал(а):Во многих моих расширениях для 1.1 тоже Composer-а нет... всё никак не добавлю.

Тема актуальная, конечно. Для 2.0 мы прям в гайде написали на тему «как сделать нормальное расширение»: https://github.com/yiisoft/yii2/blob/ma ... ensions.md

Не думаю, что стоит на месте расстреливать за не следование этому самому гайду. Например, даже плохо оформленное расширение, если оно делает что-то уникальное (например, работает с каким-то сложным API), может быть полезным и силами сообщества через pull request-ы превратится в конфетку через какое-то время.
все взаимосвязано: не можешь композер сделать - не сможешь сделать уникальное. Будут исключения из правил, но лишь подтверждающие.
Надо не плодить говнокодеров, а поднимать общий уровень комьюнити.

Re: Правила в разделе авторского кода

Добавлено: 2014.08.10, 01:56
samdark
Есть в планах для 2.0 сделать обязательным github для расширений + требование readme и т.д. За этим всё и потянется.

Re: Правила в разделе авторского кода

Добавлено: 2014.08.10, 02:00
samdark
Ну а по форумному общению просто стоит взять за правило общаться конструктивно.

Кто-то запостил расширение, которое уже есть и уже отлично работает — дайте ему ссылку и спросите, а не видел ли он случайно, когда писал своё, вот это вот по ссылке. Если видел, что побудило написать своё?

Если причина есть и просто всё фигово оформлено — расскажите, как улучшить. Если рассказывать как улучшить лень каждый раз, давайте составим документ с лучшими практиками оформления своего кода.

Re: Правила в разделе авторского кода

Добавлено: 2014.08.10, 02:01
mickgeek
zelenin писал(а):
mickgeek писал(а):zelenin, по теме я высказывался на первой странице. Внимательнее надо читать сообщения)
внимательно прочел все сообщения. то, что один раз высказался, не означает, что миссия выполнена.
Очередной спор начинается. На моё следующее сообщение у тебя опять найдётся контраргумент. Нет, спасибо, мне такое общение не нужно.

Re: Правила в разделе авторского кода

Добавлено: 2014.08.10, 02:21
samdark
Давайте лучше составим сборник рекомендаций по оформлению кода, м?

Re: Правила в разделе авторского кода

Добавлено: 2014.08.10, 02:38
mickgeek
Sam Dark, что-то вроде этого? Кстати, на счёт стандарта, хотел узнать, в документе для Yii 1.1 было сказано:
When instantiating class it should be new MyClass(); instead of new MyClass;.
В новом я этого уже не нашёл. Во фреймворке не везде используется подобное создание экземпляров? С чем это связано?

Можно также добавить в рекомендации/плюсы упоминание о наличии информационных файлов типа README.md, LICENSE.md и CHANGELOG.md.

Re: Правила в разделе авторского кода

Добавлено: 2014.08.10, 11:42
samdark
Тут скорее не про пробелы и табы (это просто ссылка на PSR-2 решает), а как раз про readme, лицензию, changelog и т.д.

Re: Правила в разделе авторского кода

Добавлено: 2014.08.10, 12:01
Ekstazi
Немного не в тему, но я вот еще ни разу не использовал composer, но это никак не говорит о неуникальности моего кода или его низком качестве. Поэтому давайте конструктивно решим какие критерии будут являться показателем качественного расширения. Пока что увидел про файлы: readme, license и changelog. Однако возникает другой вопрос - как выбрать подходящую лицензию, чтобы потом не было жалоб. Что рекомендовать - MIT, LGPL, или BSD, или прочие ?

Re: Правила в разделе авторского кода

Добавлено: 2014.08.10, 12:10
mickgeek
Думаю, стоит рекомендовать ту же, что и используют разработчики фреймворка. А там уже, если автор решит почитать про типы лицензий, сам выберет себе подходящую.

Re: Правила в разделе авторского кода

Добавлено: 2014.08.10, 12:10
slavcodev
Не надо license и changelog, не всем надо в них разбираться.
С лицензией не надо ее просто написать, потому что рекомендовано, в ней нужно разбираться, зачем она и что подразумевает.
Думаю достаточно readme и код в гит-репозитории на гитхабе, битбукете или подобных

Re: Правила в разделе авторского кода

Добавлено: 2014.08.10, 12:11
Ekstazi
Я тут придумал название темы в авторском коде: "Как мне сделать хорошее расширение или рекомендации для авторов кода". Думаю так никого не обидит.

Re: Правила в разделе авторского кода

Добавлено: 2014.08.10, 12:30
zelenin
Ekstazi писал(а):Немного не в тему, но я вот еще ни разу не использовал composer, но это никак не говорит о неуникальности моего кода или его низком качестве. Поэтому давайте конструктивно решим какие критерии будут являться показателем качественного расширения. Пока что увидел про файлы: readme, license и changelog. Однако возникает другой вопрос - как выбрать подходящую лицензию, чтобы потом не было жалоб. Что рекомендовать - MIT, LGPL, или BSD, или прочие ?
но, прости, без композера твоим расширением будут пользоваться в 10 раз меньше разработчиков и только если оно реально уникально, а не очередное поделие.

Re: Правила в разделе авторского кода

Добавлено: 2014.08.10, 12:40
zelenin
Чек-лист:

1. Поддержка composer https://getcomposer.org/ + ссылка на статью Как добавить поддержку composer в свою библиотеку. Наличие репозитория на github (предпочтительно) либо bitbucket. (обязательный пункт)
2. Соответствие PSR-1/2/4
https://github.com/php-fig/fig-standard ... tandard.md
https://github.com/php-fig/fig-standard ... e-guide.md
https://github.com/php-fig/fig-standard ... oloader.md
(я бы поставил как обязательный пункт, но понимаю, что второй пункт это дело вкуса разработчика)
3. Наличие readme.md на англ. языке, при отсутствии на русском обязательно. Описание установки и использования.

Обсуждаем, дополняем.

Re: Правила в разделе авторского кода

Добавлено: 2014.08.10, 17:28
Ekstazi
Ни один из пунктов нельзя делать обязательным. Но я бы ввел обязательным пунктом - только конструктивная критика, за иное - бан. "Типа - хорошее расширение, только добавьте поддержку composer" вместо "да без composer ваш код гавно, зачем вы вообще в руки клавиатуру взяли...". Но, боюсь, этого никто не одобрит.

Re: Правила в разделе авторского кода

Добавлено: 2014.08.10, 17:46
zelenin
если не делать обязательным пункты, тогда работать эта тема не будет.

Re: Правила в разделе авторского кода

Добавлено: 2014.08.10, 19:45
Ekstazi
Будет, вас же не заставлял никто использовать composer или yii. Или github осваивать. Все учатся рано или поздно. И стараются сделать свой код лучше. Вот поэтому я и против категоричной критики новичков. Когда-то я и сам был таким, и, если б я услышал подобное в свой адрес, то ответил бы очень грубо, вместо принятия за истину.

Re: Правила в разделе авторского кода

Добавлено: 2014.08.11, 00:44
zelenin
Ekstazi писал(а):Будет, вас же не заставлял никто использовать composer или yii. Или github осваивать. Все учатся рано или поздно. И стараются сделать свой код лучше. Вот поэтому я и против категоричной критики новичков. Когда-то я и сам был таким, и, если б я услышал подобное в свой адрес, то ответил бы очень грубо, вместо принятия за истину.
это не критика новичков. просто вы сами походу дела новичок и поймете о чем я лишь пройдя определенный путь.

Re: Правила в разделе авторского кода

Добавлено: 2014.08.11, 01:14
lynicidn
:D