Есть ли какие-либо функции языка Ruby, которых Вы избегаете?

Это может быть очевидно, но я обычно избегаю использования eval, если есть альтернатива.

Цикл for ... in .... Он напрямую компилируется в obj.each (и соответственно выдает странное сообщение об ошибке) и в этом нет необходимости. Я даже не вижу, где это улучшает читаемость - если вы использовали Ruby больше недели, #each должно быть естественным.

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

Избегайте связывания слишком большого количества вызовов методов вместе. В Ruby очень распространено объединение методов в цепочку.

user.friends.each {|friend| friend.invite_to_party}

Это может показаться нормальным, но нарушает Закон Деметры :

Более формально закон Деметры для функций требует, чтобы метод M объект O может вызывать только методы следующих типов объектов:

1. O сам
2. M параметры
3. любые объекты, созданные / экземпляры в объектах прямых компонентов M
4. O

Приведенный выше пример не идеален, и лучшим решением было бы что-то вроде этого:

user.invite_friends_to_party

Проблема примера не является ошибкой Ruby, но очень легко создать код, который ломается Закон Деметры и делает код нечитаемым

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

Я действительно ненавижу "неправильное" использование {} и do ... end для блоков. Кажется, я не могу найти, где именно я изучил эту практику, но обычно принято делать {} для однострочных блоков и do ... end для многострочных блоков.

Использование по назначению:

[1, 2, 3, 4].map {|n| n * n }.inject(1) { |n,product| n * product }

или

[1, 2, 3, 4].inject do |n,product|
  n = n * n
  product = n * product
end

Использование не по назначению:

[1,2,3,4].map do |n| n * n end.inject(1) do |n,product| n * product end

или

[1, 2, 3, 4].inject { |n,product|
  n = n * n
  product = n * product
}

Все, что, конечно, приведет к получению 576

Во-первых: я нарушу многие из этих правил, если это будет для короткого одноразового скрипта, однострочника в командной строке или в irb . Но большую часть времени я трачу на скрипты или приложения среднего или большего размера. Итак:

Избегайте:

• использования блока кода class << self для методов класса. Это симпатичный трюк, но не лучше, чем def self.foo , и менее читаемый (особенно после первой страницы).
• for i в collection : используйте collection.each .
• proc {...} : обычно лямбда {...} лучше.
• переменные класса (например, @@ foo ) . Они проблематичны и обычно без особых усилий могут быть заменены переменными экземпляра уровня класса.
• Все, что вызывает предупреждение, и предпочтительно все, что вызывает предупреждение при запуске через более строгий ruby ​​-w . Это особенно важно, если вы пишете гем для использования другими.
• ' else ' в блоке ' begin ... rescue ... end '. Личные предпочтения: это слишком крайний случай, и поэтому немногие люди даже знают, что он существует или как он работает, чтобы того стоить.
• ObjectSpace и GC . Вам, вероятно, не нужно туда идти. Вы определенно не хотите туда идти.
• = begin и = end многострочные комментарии. Личное предпочтение построчных комментариев. Это меня до чертиков раздражает.

Используйте его, но в умеренных количествах или в крайнем случае (и прокомментируйте его соответствующим образом):

• eval (или class_eval и т. в строке. Есть некоторые приемы метапрограммирования, которые невозможно обойтись без передачи строки. И иногда строковая версия работает значительно лучше (а иногда это имеет значение). В противном случае я предпочитаю отправлять блоки реального кода Ruby для моего метапрограммирования. eval можно полностью избежать для многих задач метапрограммирования.
• Добавление или переопределение методов для классов, которые не были созданы мной и могут использоваться кодом вне моего контроля; он же обезьянка-патч. Это правило в основном предназначено для больших кодовых баз и библиотек; Я с радостью и быстро сделаю исключение для небольших разовых сценариев. Я также сделаю исключение для исправления глючных сторонних библиотек (хотя при обновлении вы можете выстрелить себе в ногу!). Пространства имен селектора (или что-то подобное) в этом отношении помогут сделать Ruby красивым. Тем не менее, иногда это того стоит. ; -)
• Глобальные переменные (кроме классов). Я даже передам $ stdout в качестве параметра своим объектам или методам, а не буду использовать их напрямую. Это делает повторное использование кода намного проще и безопаснее. Иногда этого нельзя избежать (например, $ 0 , $: , $$ и другие переменные среды, но даже в этом случае вы можете ограничить использование).
  • говоря об этом, я предпочитаю полностью ограничить использование глобальных переменных perlish, но если их нужно использовать больше, чем немного, то требует «английский» .
• break, повторить, затем, попробовать: часто они делают блок, цикл или метод более элегантными, чем они могли бы быть в противном случае. Обычно они просто заставляют вас чесать голову в течение нескольких минут, если вы какое-то время не видели этот код.
• __ END __ для блока данных. Отлично подходит для небольшого однофайлового скрипта. Бесполезно для многофайлового приложения.

Не используйте его, но и не избегайте этого:

• try / catch
• продолжения

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

• ' и ' и ' или ' ключевые слова: они имеют другой приоритет, чем && и || , поэтому с ними нужно быть осторожнее. Я считаю, что их различный приоритет очень полезен.
• черная магия регулярных выражений (при условии, что у меня есть несколько примеров для этого в модульных тестах)
• HEREDOC strings

begin nil+234 rescue '' end

Синтаксис, указанный выше, действителен, но вы никогда не должны его использовать.