Идея конкурса «Плагины для MV»

Оценивать, как написано в текущих правилах, но убрать последнюю категорию...то есть оставить 2 категории.

Mur пишет: Неоднократно выше была сказано, если вас что-то не устраивает или не нравится, нет проблем! Но! Будьте любезны тогда высказать и своё видением. Не нравятся предложенные категории (кстати не мной же, но с моими комментариями), нет проблем опишите как вы предлагаете оценивать плагин? Вариант нравится/не нравится не прокатит, ибо в противном случае скатимся к конкурсу «у кого больше друзей».

1. Пункт "Качество кода" - УБРАТЬ!
2. Технодемка для демонстрации работы плагина - ОБЯЗАТЕЛЬНО!

Во первых!... Виноват, окей, оцениваем плагины, хорошо. В топку руби, и 2003 мукер впридачу чего-ж нет, безнадежно стары. Но в таком случае выскажу свое мнение как человек несколько понимающий в скриптах (пункты уже по существу, а не просто бурчание).

• Пункт на красоту кода почти не имеет смысла, кроме ярого безобразия. До сих пор мне не доводилось видеть такого скрипта, который нельзя было бы починить в виду полного непонимания происходящего. А рядовой пользователь в скрипт\плагин и носа не сунет. Максимум штрафовать за совсем ярые случаи, ибо такая оценка не всеми осуществима и скорее является тыком наугад.
• Добавить 2 пункта - работоспособность и презентация. Первое отлов багов, второе качество документации/демки. Это и оценить может каждый, и важно для плагина как такового, и замена утерянному пункту есть.

И все-таки верну должок - голым жсом пользуются только энтузиасты и фанаты, мне их жаль.

Надеюсь, в демке не будет оцениваться маппинг, сюжет и музыка)

Я бы хотел вступиться за пункт «Качество кода».

Мне кажется, что он хорош тем, что:

— Поощряет игроделов заглядывать «под капот»
— Поощряет авторов плагинов писать код, в котором проще разобраться

Наше общество часто делит людей на производителей товара и потребителей. «Не вскрывайте — потеряете гарантию!», «Вы не можете написать программу для своего же устройства, потому что у вас криптоключа разработчика нет» и многими другими способами людей убеждают: мы только потребители, а создают вещи только особенные люди.

И красота Мейкера в том, что он ломает один такой барьер. Что он показывает: сделать игру может каждый.

И вот красота критерия «Качество кода» в том, что оно поощряет каждого посмотреть на этот самый код. Попытаться что-то понять. Возможно увидеть, что программирование — не магия, а умение, которое они вполне смогут освоить.

Я не верю, что у программистов какое-то особое мышление, которое делает понятным то, что другие не понимают. Программисты сталкиваются с теми же проблемами, что и обычные люди. И то, что понятнее обычным людям, понятнее и программистам. Поэтому мне кажется вполне нормальным дать обычным людям возможность оценки.



Я не буду настаивать на этом критерии. В конце концов, мы все выросли в нашем обществе и нам трудно принять, что каждый может программировать. Но критерий красивый.

P.S. А если кто-то не хочет смотреть на код, то он просто может поставить всем по 3 балла.

Я бы хотела, чтобы критерий "красота кода" был. Сама участвовать скорее всего не буду, но хотелось бы посмотреть, как что реализуют участники, поэтому понятность и доступность была бы весьма кстати.

кто настаивает на пункте "красота кода": определитесь что вы понимаете под этим? И как, например я, должен понять что код красивый? Четкие критерии "красивости" кода для нубов есть?

Открываю я, значит, код и... и что? Он должен быть в столбик? или разноцветными буквами сделан? Что я должен увидеть, чтобы сказать "да, код красивый" или нет, "код не красивый"
Эталон "красивости" кода? Я ведь должен на что-то ориентироваться?

Я кажется понял что имеется ввиду...

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

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

Лео правильно понял моё видение. Можно назвать "понятность кода", а не красота. Просто так конкурс будет более полезен для людей, у которых пока не хватает знаний написать свой плагин.

Green-Leo, в MV для этой цели есть параметры у плагинов, которые разработчик плагина описывает в начале кода и которые можно менять прямо из мукера, не открывая код плагина. Ковырять код плагина - подход неправильный, т.к. в таком случае ты не сможешь легко обновить плагин на новую версию, когда её сделает автор плагина.

PanzerCat пишет: Эталон "красивости" кода? Я ведь должен на что-то ориентироваться?

Эталоном «красивости» можно считать стандартный код мейкера. Вот, например, экран карты: github.com/rpgtkoolmv/corescript/blob/ma..._scenes/Scene_Map.js

На что стоит обратить внимание:

• Тут почти все названия что-то значат. «Scene_Map», а не «sm». «isReady», а не «ir». «fadeInForTransfer», а не «fiTr». Есть несколько общепринятых однобуквенных названий (x, y, z для координат, i, j для индексов), а остальные принято писать более-менее целиком. Названия должны быть написаны так, чтобы их поняли другие люди.
• Код написан с отступами. Например, внутри условного ветвления if (...) { ... } текст между { и } сдвигается на одну клетку. Это позволяет людям понять, к чему относится условие. Компьютеру всё равно, что сдвинуто, что нет. А людям помогает.

Для Руби тоже можно посмотреть стандартный код мейкера. Вот, например, код экрана карты в VX Ace: github.com/orzFly/RPGMakerDefaultScripts...r-vx.en/Scene_Map.rb

Мур, мои 3 критерия: Оригинальность, Полезность, Оформление демки (не маппинг и прочее, а как показал функционал плагина) и документации (описание функционала в хелпе)

UPD. Для тех, кто за "красивость" кода. Предлагаю следующее: существуют правила оформления кода, которым в сообществе программистов очень стоит соблюдать. Это базовые правила, которые делают код читаемым и понятным, а значит красивым.
Вот, например, правила: learn.javascript.ru/coding-style
Автор, который полностью соблюдал эти правила, автоматом получает 5 баллов. Если же автор не соблюдал какие-то правила, то минусуются баллы по степени "тяжести", то есть критичности оформления, которые делают читаемость кода чуть хуже или намного хуже.

DK пишет: UPD. Для тех, кто за "красивость" кода. Предлагаю следующее: существуют правила оформления кода, которым в сообществе программистов очень стоит соблюдать. Это базовые правила, которые делают код читаемым и понятным, а значит красивым.
Вот, например, правила: learn.javascript.ru/coding-style
Автор, который полностью соблюдал эти правила, автоматом получает 5 баллов. Если же автор не соблюдал какие-то правила, то минусуются баллы по степени "тяжести", то есть критичности оформления, которые делают читаемость кода чуть хуже или намного хуже.

Чорт, после этого изменения я хочу забрать своё спасибо

По-моему пробелы вокруг вложенного вызова и то, где находятся скобки возле else — последнее, что влияет на читаемость. Куда больше влияют плохо формализуемые вещи (что выносится в функции, как выбираются названия и т.д.).

У каждого свои заморочки со стилем, которые не всегда повышают читабельность и снимать балы четко по конкретному варианту - полный бред.
В идеале, код просто должен быть легко читаемым (как и любой текст), чтобы не требовалось долго всматриваться, чтобы разглядеть отдельные слова и словосочетания.

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

Насчёт сокращений в духе sm, они вполне уместны, когда фрагмент кода, их использующий, небольшой.
Это позволяет слегка сэкономить время и сократить длину строки.

Насчёт скобок, нередко используют разное оформление для функций и условных блоков. Благодаря чему, можно не всматриваясь сильно в код, заметить границы функций.
Но это не всегда и также имеет некоторые минусы (например, потерю одной строки в каждой функции).

Также и с пробелами и пустыми строками, нужно смотреть по ситуации.

P.S. Код в движке Мейера далеко не идеал. Временами названия переменных вводят в заблуждение, в других случаях, он заставляет скакать по множеству файлов, построчно собирая логику, а также активно использует переменные, объявленые фиг знает где.

По критериям оценки согласен с ДК
Полезность, предсказуемость, стабильность и насколько быстро тебе удалось по мануалу настроить плагин в чистом проекте

предлагаю: оригинальность, полезность, УДОБСТВО. Плагины пишутся для пользователей,а потому важно насколько его легко воткнуть в проект, настроить, подстроить под себя. При этом чтоб от косяков пользователя не случалось незапуска игры, а например выводилось окошко "в параметре "герой" должен быть ID (номер) героя в базе данных, а не его имя".

Также предлагаю "непрограммистам" высказывать свои желания. Может, вам нужен какой-то определенный плагин, а его нигде нет? Программисту будет выгодно написать то, что хотят форумчане, ведь тогда этот человек за него проголосует. А форумчанин будет рад получить то, что хотел. А заплатит за эту работу форум Заодно потренируемся писать ТЗ.

От себя очень бы хотел плагин на анимацию. Например, в маршруте событий вводишь команду
anim('shot', 2, 4, 12, 11, 5, 12)
и графика твоего перса заменяется на графику с чарсета "шот", причем 2-ой сет из этого чарсета, кол-во кадров - 4, кадры меняются со скоростью - сначала 12 кадров в секунду, потом 11, потом 5, потом 12. Если же вводишь вместо последних 4 цифр одно, то скорость смены кадров одинаковое. После этой анимации спрайт меняется на прежний.
Если кто-то пожелает такое сделать - составлю ТЗ поконкретнее и обещаю отдать этому плагину максимальные баллы

Dmy пишет:

DK пишет: UPD. Для тех, кто за "красивость" кода. Предлагаю следующее: существуют правила оформления кода, которым в сообществе программистов очень стоит соблюдать. Это базовые правила, которые делают код читаемым и понятным, а значит красивым.
Вот, например, правила: learn.javascript.ru/coding-style
Автор, который полностью соблюдал эти правила, автоматом получает 5 баллов. Если же автор не соблюдал какие-то правила, то минусуются баллы по степени "тяжести", то есть критичности оформления, которые делают читаемость кода чуть хуже или намного хуже.

Чорт, после этого изменения я хочу забрать своё спасибо

По-моему пробелы вокруг вложенного вызова и то, где находятся скобки возле else — последнее, что влияет на читаемость. Куда больше влияют плохо формализуемые вещи (что выносится в функции, как выбираются названия и т.д.).

Скобки возле else сокращают разрыв с 3 до 1 строки, что делает комбинацию ‘} else {‘ похожей на разделительную линию и позволяет не перемещая взгляд, увидеть переход целиком.

Это как если бы я писал тут



А дальше тут.
Насчёт пробелов во вложенном вызове, согласен. Имя вызываемого метода, вложенный метод и закрывающая скобка, выглядят тремя отдельными объектами, а не одним действием.

Пока не дочитала до сообщения ДК о правилах оформления кода, была уверена, что под "красотой кода" имеется в виду его архитектура и отсутствие "запаха": чтобы не было непонятно названных функций и переменных, чтобы одна функция или объект не брали на себя слишком много ответственности - короче, все эти принципы чистокого кода, благодаря которым программисту проще разобраться в чужом коде. Мне кажется, для плагинов для Мейкера это не менее важно, чем удобство вставки автором, который не скриптер. Я где-то читала: у кода тоже есть целевая аудитория тех, кто его прочтёт, и писать надо с расчётом на неё.

А пробелы расставлять и машина умеет.

EvilCat пишет: была уверена, что под "красотой кода" имеется в виду

Ты пропустила шум в чате, но особую неприязнь этот пункт заработал из-за того, что не совсем ясно как его оценивать не посвященным жс. Сами же непосвященные предлагают разные варианты - от ascii артов (в шутку конечно же) и до упрощения и комментирования кода до уровня возможности изучения сорцов для изучения программирования.

EvilCat пишет: А пробелы расставлять и машина умеет.

Надо посмотреть не режет ли gulp-js-prettify комментарии...

С практической точки зрения, учитывая суть нашего любительского мейкерского сообщества - чем больше изменений непосвящённый (зачастую даже в ЖС!) может внести и добиться нужного результата, тем лучше. Эффективно нахачить, так сказать.

Я сейчас стараюсь писать свой новый код именно с этим заделом. К тому же сегодня в твоём коде хачат посторонние, а через несколько лет этим посторонним можешь оказаться ты сам (позабывший всё)...

EvilCat пишет: чтобы не было непонятно названных функций и переменных, чтобы одна функция или объект не брали на себя слишком много ответственности

Именно всё перечисленное и имелось ввиду. Откуда взялись остальные додумки я не знаю.

EvilCat пишет: благодаря которым программисту проще разобраться в чужом коде.

Да! Да! И ещё три тысячи раз да! ИМЕННО В ЭТОМ И БЫЛА ОСНОВНАЯ ИДЕЯ что бы любой мало-мальски разбирающийся (или только начинающий, или вообще только только мечтающий научится) мог глянуть на текст и понять о чём тут речь!

EvilCat пишет: А пробелы расставлять и машина умеет.

АМЕН!

Значит ещё раз подводя итог, предлагаю компромиссное решение. Сделать вариант в виде оценки, насколько легко и просто установить и настроить плагин. Насколько широко автор представляет возможность «тонкой настройки» (например задать положение на экране, цвет и размер шрифтов итд)

Что же касается пункта красота, пусть это будет КАЧЕСТВО кода. А критерии оценки будут в виде дополнительного бонуса.

Предлагаю немного изменить конструкцию оценки от 1 до 4 баллов и сделать как это делается в различного рода текстах. Есть некое утверждение и вы с ним согласны или нет:

4 балла — Да!
3 балла — Скорее да, чем нет.
2 балла — Скорее нет, чем да.
1 балл — Нет!

Итак предварительные правила получаются такие: Писать можно на чём угодно (Ruby или JavaScript). Писать можно под что угодно (RPG Maker MV, XP или VX Ace). Писать можно на любую тему (в рамках приличия и не нарушая законодательство). Срок конкурса 2 недели + 1 неделя на форс мажор.

Теперь что касаемо критериев оценки, всё ниже перечисленное оценивается от 1 до 4 баллов:

1. Оригинален ли плагин (нова ли сама идея)?
2. Полезен ли лично для вас плагин?
3. Легко ли было установить и настроить плагин (всё ли было понятно)?
4. Достаточно ли параметров (лично для вас) вынесено в настройки плагина?

Дополнительно по 1 баллу за каждый пункт можно дать за «Читабельность кода»:

• Аккуратное форматирование (переносы скобки итд)
• Наличие комментариев (описание параметров вызова функции)
• Вменяемые (не сокращённые) названия функций (gcs() → getCurrentState() итд)
• Отсутствие перегруженных функций со сложным функционалом и размером более 1000+ строк
• Отсутствие специфических конструкция понятных лишь гуру

Если голосующий не разбирается в программировании или не хочет оценивать «Читабельность кода» он просто игнорирует этот пункт.

Так же 1 дополнительный балл даётся при наличии техно-демки.

Ну вот как-то так. Надеюсь теперь все «специфические» вкусы удовлетворены?

p.s. И наверное стоит добавить пункт, что голосовать могут те, кто был зарегистрирован до старта начала конкурса или выставил свою работу на конкурс. (по 10 сообщений это думаю бред)