Стандарты кодирования Magento

40

Я недавно начал активно работать с Magentoи Code наркоманом , и я хотел бы знать , какие стандарты я должен следовать.

Я попробовал стандарты кодирования Zend , но я не хочу использовать ограничение в 80 строк, и оно также не используется в ядре.

После этого я попробовал стандарты CS2 , но это также не работает из-за _различных функций и имен классов, которые содержат _в себе и не имеют пространств имен.

Итак, есть ли другой стандарт, которому базовый код соответствует 100%? Если нет, то не должен ли magento иметь свои собственные стандарты кодирования? Он имеет свой собственный сайт для обмена стеками, и разработчики расширений могут использовать некоторые четко определенные стандарты кодирования.

Влад Преда
источник

Ответы:

18

Лучшие практики Magento довольно хорошо описаны здесь Джошем Праттом . Он предлагает принять и следовать стандартам стиля Zend Code, и я могу только присоединиться к нему.

Длина максимальная линия не является строгим требованием. Однако с точки зрения читабельности слишком длинные строки не приветствуются.

user487772
источник
2
Спасибо, я переключил ruleset.xml на 120 символов, разрешенных на строку, чтобы я не получил досадных ошибок в моей IDE :)
Влад Преда
1
Вот правила из Magento 2: raw.github.com/magento/magento2/master/dev/tests/static/… . Ходят слухи, что они используют их в Magento 1.x.
Боб Броди
1
Тим, как ты думаешь, мы должны использовать анализатор кода Magento? magento.stackexchange.com/a/8743/41
календжордан
1
@BobBrodie - я управляю Magento 1.x и не знаю, как такие изменения появятся в Magento 1.x. Это было бы большим и ненужным изменением, приводящим к огромным различиям без причины. Стандарт кодирования Magento 1 - ZF +, Magento 2 - PSR-1/2. Пожалуйста, смотрите ответ Зявы для «официального» сниффера.
Петр Каминский
12

Вот последний стандарт кодирования торговой площадки Magento для Magento1 и Magento2

MEQP2 для Magento2

MEQP1 для Magento1

https://github.com/magento/marketplace-eqp

Кайсар Сатти
источник
1
Сделано это как принятый ответ, так как это официальные стандарты кодирования. Спасибо @QaisarSatti
Влад
11

Я хотел бы заявить, что мы должны использовать анализ кода Magento 2 в качестве стандарта для Magento 1.X и 2.X: https://github.com/cobhimself/phpcs-magento-rules/blob/master/ ruleset.xml

И вот, по сути, зеркало этого набора правил в качестве отдельного хранилища: https://github.com/cobhimself/phpcs-magento-rules

kalenjordan
источник
1
Я лично использую: github.com/magento-ecg/coding-standard
B00MER
2
Ах, хороший звонок. Я думаю, что ссылка, которую я разместил, была упомянута в обсуждении Magento 2 github ... есть идеи, если / как та, которую вы опубликовали, отличается? Это, безусловно, более авторитетный аккаунт на github.
Календжордан
2

Этот пост немного стар (2008), но я думаю, что он все еще действителен:

Соответствует ли Magento стандартам кодирования ZF? да

За некоторыми исключениями, такими как:

  • короткие открытые теги разрешены в шаблонах.
  • точки конкатенации не заключены в пробелы.
  • Отступы для длинных строк жестких переносов всегда должны быть на одну мягкую вкладку вперед.

Редактировать Поскольку Тим в комментарии, в основных шаблонах Magento нет коротких открытых тегов, и лучше их не использовать, так как они не рекомендуются (см. Здесь ).

Но мой вам совет ... Поскольку вы пишете свой собственный модуль, используйте свой собственный стиль кодирования. Из моего опыта вы будете делать меньше ошибок при написании кода в своем собственном стиле, с которым вы знакомы, чем если вы будете следовать стилю кодирования Magento в один день и, например, стилю кодирования Wordpress в следующий раз только потому, что вы пишете модуль для другого проекта веб-сайта. ,

Домен Вранкар
источник
2
Я строго не согласен. Расширение сообщества должно быть читаемым для других.
user487772
2
И я никогда не видел короткие открытые теги в Magento.
user487772
1
Точка зрения. Поскольку у меня было довольно многолетний опыт программирования одновременно на разных проектах на разных языках программирования, у меня никогда не было проблем с чтением хорошо структурированного кода, независимо от стиля кодирования, но когда дело доходит до быстрого переключения между проектами и при написании кода гораздо удобнее иметь один и тот же стиль в вашем собственном коде, чем поддерживать совместимость стиля кодирования с другими людьми вне вашей команды.
Домен Вранкар,
@ DomenVrankar не предполагает, что ваш стиль кода хорошо структурирован и читаем, а также мнение? Принимая во внимание, что в командах, подобных Zend, есть много людей, которые принимают решение о том, что такое стиль и что он известен во всем мире. Просто пища для размышлений ...
Том Бурман,
Я тоже не согласен.
sv3n