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

Конечно, надо чередовать. Что-то узнали - закрепили практикой - узнали - закрепили и т. д. :)

Согласен))

Это хорошо видно на некоторых наших студентах. Видно на первых задачках, что чувак явно "шарит" (либо вспомнил уроки Паскаля в восьмом классе, либо сам что-то выучил, либо имел опыт на другом языке некий). Но при этом для проф. программиста его код - это боль, т. к. всё в целом логично, но "не то" и "не так". Т. е. из "кулибина" надо превратиться в нормального спеца в стандартной гильдии :)

DRY не всегда есть хорошо :-)

Это не шутка как бы :-)

О чем

TelegramChannel.channels_search(searching = "проститутки", its_about = 10)

🤔

Пет-проджект, говорите

Всё верно, что-то вроде вашего кода я и имел в виду в своём предыдущем высказывании :) Ну, можно посмотреть ruby code style guide, если на что-то конкретное ссылаться, а не на собственное "пролетарское чутьё".

предлагаете на разбор, типа как в одном из предыдущих видео? :)

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

как курсив-то тут сделать?

разобрался )

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

вот этот разбор @installero имел в виду: https://www.youtube.com/watch?v=2AHQytI-H_g

На уровне общих принципов, т. к. некогда видео пилить:

1. Чем меньше кода, тем лучше
2. Названия в Ruby - слова английского языка без сокращений (за исключением общеизвестных аббревиатур)
3. Нельзя смешивать ввод-вывод (puts, gets) и "логику" в одном классе
4. Названия переменных и методов должны соответствовать содержанию и функции соответственно (скажем, its_about - мимо)
5. Требуется следовать известным ожиданиям и договорённостям. Класс совсем не похож на то, как предлагается использовать HTTParty в самой документации HTTParty, а должен быть очень похож.
6. Следует избегать "тревожного программирования". Например, не следует проверять типы на каждый чих - только в местах контакта с пользователем.
7. Следует избегать двух названий для одной и той же штуки. Не следует без необходимости делать разные имена у аргументов конструктора и instance-переменных.
8. attr_accessor - старший брат attr_reader
9. Стоит, по возможности, минимизировать количество аргументов у методов. Если не получается - keyword params (они же named arguments)

В целом, на самом деле, с пятого пункта стоит начать. Good artists copy, great artists steal. Если можно код максимально близко к образцу слизать - именно так и следует делать.

Самое главное правило, как говоил мой ментор: "код пишут для людей, а ещё его иногда компьютер читает"

У вашего ментора хороший ментор: https://www.goodreads.com/quotes/6086714-programs-are-meant-to-be-read-by-humans-and-only