Ответ 1

Вероятно, это означает, что определение вашего класса занимает более 100 строк кода.

Ответ 2

Да, это потому, что общие линии считаются слишком большими rubucop. Я согласен, что классы не должны затягиваться слишком долго, но думаю, что в конечном итоге это должно быть определено: у класса есть отдельная ответственность, методы достаточно кратки, есть методы, которые можно использовать через модуль и т.д. Число/предупреждение однако это большое предупреждение. Если что-то в классе выглядит нормально, вы можете добавить # rubocop:disable ClassLength непосредственно над определением класса.

Ответ 3

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

В .rubocop.yml

# Allow classes longer than 100 lines of code
ClassLength:
  Max: 250 # or whatever ends up being appropriate

Ответ 4

Общий ответ

Нужно ли отключать этот коп, если я хочу, чтобы мой класс был больше 100 или здесь нужно настроить максимальную длину. Что ты предлагаешь?

Я использую rubocop с этим документооборотом, предполагая, что я столкнулся с уже существующей базой кода с множеством предупреждений:

• Запустите rubocop --auto-gen-config, чтобы создать файл "TODO". Включите этот файл в основной файл конфигурации rubocop. Подробнее см. В их документации. В вашем примере это создаст конфигурацию, которая позволяет использовать длинные классы (не менее 236 строк или более, если у вас более крупные классы).

• Теперь, если вы запустите rubocop, он будет игнорировать все правонарушения, которые вы вложили в ваш TODO файл, то есть теперь все будет выглядеть нормально. Только если вы введете больше ошибок/предупреждений (например, класс с 237 строками), он снова запустится. Итак, на данный момент rubocop ничего не сделает для вас, кроме как предотвратить вас, чтобы сделать его хуже.

• Время от времени, когда у меня есть время, чтобы убить, я выбираю правило из файла TODO и работаю над ним. Существует три возможности:

  • Удалить правило из файла TODO. Это восстановит исходное поведение rubocop.
  • Отремонтируйте номер, связанный с ним. Скажем, теперь длина класса ограничена 250; Я хотел бы установить его (скажем) 100 строк, но я знаю, что у меня нет времени для реорганизации многих классов прямо сейчас. Поэтому я установил значение 240. Это вызовет все классы, которые находятся между 240 и 250 линиями; вероятно, лишь немногие, с которыми я могу справиться легко. Я исправляю их и двигаюсь дальше. В другой день я, возможно, вернусь к нему и перейду от 240 до 230 и т.д.
  • Иногда я решаю, что я не беспокоюсь о конкретном предупреждении. Затем я перемещаю конфигурацию из файла TODO в соответствующий .rubocop файл, позволяя ему постоянно.

Итак, нет никаких жестких и быстрых правил обо всем этом. Вы должны найти свои собственные ценности. Некоторые вещи, с которыми сталкиваются объекты rubocop, полностью соответствуют мне, поскольку они более соответствуют стилю кодирования, чем правильность или что-то еще.

Конкретный ответ

Нужно ли отключать этот коп, если я хочу, чтобы мой класс был больше 100 или здесь нужно настроить максимальную длину. Что ты предлагаешь?

У меня наверняка есть максимальное количество строк, настроенных для моих файлов классов (а также для методов). Длина единицы кода (будь то класс или метод) - очень простой, но эффективный "запах кода", который указывает на выраженный код и кандидатов на рефакторинг/разделение.

Я выбрал для себя некоторые цифры, и я придерживаюсь их. I.e., я не постоянно перемещаю их вверх или вниз, чтобы соответствовать конкретному коду, но если часть кода вырастает "1 строка слишком большая", я принимаю меры. В большинстве случаев моя цель состоит в том, чтобы разбить ее примерно наполовину, что в конечном итоге приведет к минимальным требуемым усилиям.

Если класс очень длинный, он обычно нарушает правило "одна ответственность за класс". Обычно полезно разбить его на части. Не только случайные подклассы, но и actully OO-оправданные, узорные, конструкции.

Если метод очень длинный, он иногда может указывать на принимаемые меры OO (т.е. введенные классы или метод разбивается на существующие классы, особенно если метод состоит из больших конструкций if/else или особенно case), но чаще всего он требует простого старомодного рефакторинга в более мелкие (вероятно, частные) методы.

Удачи в поиске ваших любимых настроек в rubocop, это потрясающе.