Мы довольно много поговорили о том, какими же должны быть хорошие функции. И наверняка у некоторых из вас начал зарождаться вопрос, почему же мы такие зануды? На самом деле мы, команда курса считаем, что особенно когда вы работаете над большим проектом, в большой команде нужно максимально щепетильно относиться к качеству вашего кода. Когда вы проектируете интерфейс вашего кода, нужно быть параноиком и перфекционистом. Очень важно выработать навык предвидения того, как можно неправильно интерпретировать ваш замысел, который вы вложили в ваш код. И вы здесь можете спросить, ну зачем мне быть идеальным разработчиком? Почему мне нельзя быть просто хорошим? И вот без этого всего, без всех этих страшных рекомендаций, просто буду писать код как-нибудь и все будет нормально. Ну хорошо, представьте, что вы работаете в большой команде и вы хороши, но так процентов на 60. И вот у вас есть коллеги, ну скажем 10 человек, вы написали какой-то код и дальше ваши коллеги иногда приходят и его как-то читают, исправляют. И вот 6 человек, они правильно поняли ваш замысел, как-то код обновили, все довольны, вы довольны и коллеги довольны, код понятный, но остальные 4 ничего не поняли. Они каждый из них как-то пришел, либо он прочитал код и страдает, либо он как-то его кое-как исправил и все разнес и в итоге страдают и эти 4 человека и вы страдаете, потому что ваш код теперь совершенно непонятен и те 6 человек тоже, им сначала было хорошо, а теперь они тоже в печали, потому что непонятно что случилось с вашим кодом. Именно поэтому планка качества к коду очень высока, особенно когда вы работаете в большой команде. Однако, некоторые из вас могут сказать, ну зачем мне писать понятный код, если всегда есть комментарии, то есть написал кот как-нибудь, прокомментировал, и все замечательно. Даже непонятный код будет понятен, потому что есть комментарии, но знаете если вы издаете книгу с вашим кодом, то есть вы написали, все там пояснили, распечатали и она зафиксирована, ну почему бы и нет, пишите как хотите, но все таки, если речь идет о реальном коде, который работает в продакшене, его как-то меняют, он как-то развивается, то нужно думать еще и о том, что ваш код будет кто-то менять. И вряд ли ему будет дело до изменения комментариев. Вообще главная проблема комментариев в том, что если вы забыли обновить, то код продолжит компилироваться и нормально работать. Если же вы допустили ошибку в коде, то он сломается. Поэтому комментарии часто россинхронизируются с основным кодом и нужно стараться их количество минимизировать, например, за счет понятности функций. В некоторых командах на самом деле, есть хорошая практика, документирование не совсем всего кода, а только заголовка функции, только сигнатуры, то есть там буквально, в нескольких строчках написано, что эта функция делает, вот этот параметр означает это, вот этот означает это и возвращает функцию вот это. Очень замечательно если ваша команда к этому приучена и обновляет эту документацию, но если команда так не делает, то довольно тяжело будет заставить ребят обновлять комментарии к функциям. Гораздо проще научиться все таки сами функции поддерживать в адекватном состоянии, поэтому комментарии, они иногда нужны если речь идет о сложном коде, но далеко не везде. Старайтесь в первую очередь делать код понятным. Чем же мы будем заниматься дальше в нашем блоке? Этот блок будет как я уже говорил набором рекомендаций к написанию хорошего кода. Эти рекомендации не обязательны, вы можете их нарушать, понимая последствия их нарушения. Есть некоторые рекомендации более общие, которые вам пригодятся довольно часто в вашей карьере разработчика и они оформлены как видеолекции, в привычном формате. Есть же рекомендации, которые скорее про некоторые особенные случаи проектирования программ, про особенно большие программы и мы их оформим в виде материалов для чтения, то есть если вам надо будет вы к нам вернетесь и поймете, ага, вот если я хочу вот так-то и так-то хитро оформить функцию, то это надо делать вот так. И наконец будут задачи. Задачи призванные, во-первых, показать вам разницу между плохим кодом и хорошим, то есть скажем вы попробуете найти ошибку в плохом коде и в хорошем, и увидите, что в хорошем коде это явно делается легче и поймете почему это так, то есть за счет чего хороший код - лучше плохого. Во-вторых, мы предоставим вам возможность написать хороший код, то есть решить какую-то задачу так чтобы этот код был понятным и расширяемым. Вот такой замечательный план. Давайте начнем с того, что изучим как же правильно передавать данные в функцию.
