Как стать автором
Обновить

Комментарии 5

Чему могут научить пул реквесты в чужие проекты

Согласен, что примеров из игр не было, поправил статью. Я не правильно выразился. Пытался сказать, что приведенные строки кода и скрины реквеста относятся к Unity (например, атрибут SerializedField).

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

Некоторые сомнительные рекомендации:

Очевидно, вклад в чужой репозиторий требует прочтения чужого кода, что само по себе учит новому.

Есть такое новое, которому лучше не учиться. Пример - да прямо там рядом на картинке. После того, как в C# появились автоматические свойства (auto property) - уже больше 10 лет как ЕМНИП - совершенно незачем для реализации доступа к полю/свойству только для чтения приделывать ещё и теневую переменную. Да и до того незачем было городить две реализации: оптимизация путем замены свойства полем выгляит явно сомнительной и, скорее всего, преждевременной: метод получения свойства чтение поля почти наверняка будет встроен в код по месту. И, кстати, давать примеры кода лучше не картинкой а вставкой кода.

Рас ты хочешь внести изменения в чужой код, значит это… Рефакторинг! Отличный способ попрактиковаться в этом направлении. Приятное с полезным.

  • Видишь повторяющиеся строки кода? Вынеси в отдельный метод.

Если кто-нибудь начнет бездумно выносить повторяющиеся строки в отдельный метод, то добром это не кончится - эти повторяющиеся строки часто имеют шанс при дальнейшем развитии проекта меняться в разных местах по-разному - с неприятными последствиями для того метода, куда их вынесли (и да, слово "Рас" поправьте).

Вежливость, конструктивность помогут тебе.

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

Спасибо за конструктивную критику. Статью я поправил, пример с кодом заменил. Пройдемся по порядку.

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

Есть такое новое, которому лучше не учиться

Считаю придиркой. Конечно есть такое новое, чему лучше не учиться. Значит ли это, что не учиться вовсе? Никогда не смотреть чужой код?

Пример - да прямо там рядом на картинке

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

Если кто-нибудь начнет бездумно выносить повторяющиеся строки в отдельный метод, то добром это не кончится

Это очевидно, что бездумно ничего делать не нужно. Не должен же я к каждому методу рефакторинга прописывать дисклеймер о грамотности его применения? Я написал о самом факте рефакторинга и привел кратко примеры, приложил ссылку на подробный разбор методов, где можно изучить все методы подробно.

Про вежливость полностью согласен. С незнакомыми стоит общаться на вы, безусловно. Конечно список изменений - это список, снимок экрана я заменил.

"Рас" и "Раз" поправил, это мой давний косяк, раЗ я пишу статью. Пора мне уж научиться раС и навсегда)))

Давайте становиться лучше!

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории