В этом видео мы рассмотрим 11 ошибок которые допускают новички во время написания своего кода Это очень важные ошибки которые стоит убрать с вашего кода , потому что они вызывают огромное количество багов .
Всего лишь досмотрев данное видео до конца вы сможете сэкономить огромное количество времени , сделать ваш код более профессиональным и научитесь писать его более правильно .
Итак , первая ошибка это то , как вы называете свои переменные .
Ваши переменные должны быть всегда на английском языке и содержать такие же слова .
Часто в коде я замечаю , как кто-то использует русские слова , примерно как на экране .
В принципе это вам никто не запрещает делать , но согласитесь смотреть на такой код достаточно смешно .
Да , разработчик не может перевести обычные слова из русского в английский язык , это становится достаточно смешно и данный код выглядит вообще не профессионально .
Сразу же приходит ощущение , что его написал какой-то школьник Даже если эта программа достаточно сложная То есть это может быть какое-то ядро , либо же сложный сервер и так далее Но когда вы видите такие переменные , такие названия функций , это реально очень смешно , и вам нужно исправить эту ошибку .
Научитесь писать ваши переменные , а также названия функций , классов и так далее на английском языке .
Даже если вы не знаете английский язык , вы можете перевести это в переводчике и потом вставить это в код .
Это не занимает много времени , но ваш код выглядит намного лучше .
Вторая ошибка , когда используют очень много анонимных функций .
Да , анонимные функции достаточно хороши , они позволяют упростить множество кода .
Например , если у вас есть маленькая функция , вы можете сделать из нее анонимную функцию , а также можете встроить ее в другое значение , для того чтобы всего лишь одной строчкой сделать какие-то действия .
Но бывает и такое , когда анонимные функции используют очень часто .
То есть у вас даже , например , нет обычной функции , у вас практически каждая строчка кода это анонимная функция Лямбда .
Так тоже не стоит делать , нужно везде соблюдать баланс .
Если вы знаете какую-то технологию , например оператор Маржа , либо же другие операторы .
Вам не нужно теперь использовать данную технологию везде , потому что везде нужно соблюдать баланс .
То же касается и Лямбда .
Поэтому если у вас есть выражение , которое вы можете записать в одну строчку используйте Лямбда .
Если же это выражение становится достаточно сложным , то лучше всего создать обычную функцию , так как спустя некоторое время вам будет проще понять обычную функцию , чем функцию Лямбда .
Третья ошибка это не использовать TypeHinta и PEP8 .
В случае если вы используете какие-то сложные структуры , которые сами создаете , например у вас есть дата классы , либо же есть собственные классы , на которых есть определённые значения , либо же у вас есть функция , которая возвращает какое-то значение , например int , str и так далее .
Очень хорошо , если вы используете типизацию , то есть вы указываете какой тип принимает определенные переменные и также возвращается из вашей функции .
Тем самым сразу же можно будет понять из подсказок IDE , какой тип возвращается , вам не нужно будет всё это самому проверять , тем самым другие разработчики смогут проще ориентироваться в вашем коде .
Также аннотация используется и для обычных переменных .
Если у вас переменная принимает результат какой-то функции , эта функция возвращает какую-то сложную структуру с определенными данными , тем самым вам не нужно проверять результаты , вы можете сразу видеть это значение .
По поводу P8 , очень часто новички начинают писать свой код , не соблюдая отступы , даже между функциями у них нет никаких отступов , тоже самое касается и аргументов .
Многие начинают добавлять лишние отступы , либо же вообще их не ставят .
Это вообще не соответствует стандартам .
А эти стандарты придумали для того , чтобы ваш код было проще считать .
Даже вы сами спустя некоторое время после написания кода не сможете понять , что вы здесь написали , потому что ваш код будет похож на свалку , где есть множество различных значений , функций , вы все налепили друг на друга и вам очень сложно ориентироваться в таком коде .
Поэтому также очень важно соблюдать и PEP8 .
Четвертая ошибка это не комментировать свой код .
Многие не комментируют свой код и потом удивляются , почему они не могут понять свой проект .
Лично я , когда открываю свои проекты спустя долгое время , я спокойно понимаю , что там написано .
Да , иногда бывает нужно разобраться , но всё же это даётся относительно легко .
Многие же жалуются на то , что они могут понять свой проект , не могут прочитать код , что здесь полный мусор .
Конечно же здесь полный мусор , если вы не оставляли свои комментарии , не использовали PEP8 и так далее .
Комментарии вообще одна из важнейших составляющих вашего кода .
Если у вас есть какая-то функция , либо какой-то сложный класс , где вы понимаете , что в дальнейшем вы можете не понять данный код , то лучше написать комментарий .
Естественно , не нужно писать комментарий под каждую строчку кода , что переменная типа int принимает такое-то значение .
Это делает ваш код только более мусорным .
Но если код не очевидный , обязательно пишите комментарии .
Даже если ваш проект на 100 строчек кода , либо на 50 строчек кода , я вообще не вижу проблемы написать пару строчек комментариев , для того чтобы потом можно было легко понять , как это работает .
Пятая ошибка это когда хранят важные данные внутри самого кода , то есть когда вы внутри вашего кода ставите важные апи токены , различные логины , пароли , возможно даже данные для авторизации в соц сетях , если вы пишите какого то определенного бота , изначально кажется что здесь нет ничего плохого , это ведь ваш скрипт и никто не получит к нему доступ .
Но не забывайте так же такую вещь что вы можете случайно залить данные файлы на гитхаб либо же вас попросит кто то поделиться софтом , вы уже забыли о том , что у вас API токены , возможно какие-то пароли , вы даёте ему данный файл , он успешно забирает ваш токен , например с помощью которого вы управляете своим ботом в телеграмме , а бот телеграмма управляет каналом на 500 тысяч подписчиков и с помощью данного бота они например удаляют все посты , Как вам такое ?
Поэтому , если нужно хранить какие-то важные данные , используйте переменные окружения .
У нас на канале также есть об этом видео .
В итоге , если вы зальёте данные в софт на GitHub , они не получат эти данные , потому что не хранятся в переменной окружения системы .
То есть в окружении своей системы вы заранее создаёте эти переменные .
Если же программа работает в другой системе , данных переменных там нет , естественно , ваших данных там тоже нет .
Поэтому это намного безопаснее , чем записывать такие данные в код .
Следующая ошибка это когда вы не понимаете проблему в вашем коде , вы получаете определенные исключения и сразу же бежите на форму для того , чтобы написать вопрос .
То есть , когда вы даже не пытаетесь разобраться , даже не пытаетесь погуглить информацию , сразу бежите на стек Overflow , либо же на Telegram чаты , начинаете писать свой вопрос , прикладывать скрины видео и так далее , а у вас там ошибка просто элементарная .
То есть , например , вы создали переменную a , а в принте написали переменную b , и вам интерпретатор говорит , что такой переменной просто нет .
То есть это всё элементарно понять , даже если просто перевести эту ошибку .
Некоторые начинают бежать на форумы , задавать вопросы , потом смотрят на свой код и просто понимают , что они написали одну букву не так .
Либо же у них не установлен модуль , и им Python прям говорит , что у вас нет данного модуля , вам нужно его установить , то есть просто ввести pip install и название модуля , но они не могут найти решение данной проблемы и начинают писать другим разработчикам .
Поэтому нужно научиться искать информацию .
Более опытные программисты ищут заранее эту ошибку , потому что , как правило , эту ошибку уже решили за вас миллион раз .
Потому что новички думают , что их ошибка она уникальная и ни у кого данной ошибки не было и только они первые её получили .
Хотя до того , как вы получили данную ошибку , на неё ответили уже тысячу раз .
Даже если вы используете неизвестную библиотеку , либо же неизвестную технологию , все равно есть те люди , которые тоже ее используют , столкнулись с теми же ошибками и тоже нашли ответ , и написали все это на стек оверфлоу , поэтому нужно просто научиться искать информацию .
Итак , седьмая ошибка это попытки написать все с нуля .
Опять же , это может быть хорошей практикой .
Когда вы начинаете что-то изучать и пишите с нуля определённую технологию , это в принципе хорошо , потому что вы прокачиваете свои знания , прокачиваете знания в определённых технологиях , в определённых библиотеках и т .
Д .
Но есть и обратная сторона .
Это кстати свойственно только новичкам , потому что более продвинутые разработчики обычно не пишут всё с нуля .
И так в чем же у нас проблема ?
Что новички пытаются создать с нуля абсолютно все .
То есть они пытаются создать все протоколы , все чаты , все алгоритмы шифрования , алгоритмы хеширования , они думают , что именно их алгоритм хеширования будет лучший , что у них не будет коллизии , только в их алгоритме шифрования будет самая лучшая защита .
Они начинают смотреть в соц сети что у них реализована двухфакторка с 6 знаками а нужно 12 потому что по их мнению это не безопасно .
Хотя там всего 1-2 попытки .
И начинают создавать все функции подряд , какие-то алгоритмы , подписи и так далее .
Я не понимаю , что алгоритмы шифрования , к примеру , можно очень легко взломать , если это написали вы сами .
А другие алгоритмы шифрования , которые сейчас все применяют это очень хорошо протестированная технология , и многие пытаются её взломать , но не могут .
То есть для чего в данном случае изобретать велосипед ?
Это касается именно определённых технологий , и начинают с нуля изобретать свой веб-фреймворк , свой собственный веб-сервер .
В принципе , как для практики , это достаточно хорошо , потому что вы сможете понять определённые технологии , но изобретать всё с нуля я в принципе не вижу смысла .
Итак , восьмая ошибка , когда начинают создавать определённый проект , даже скорее всего сложный проект , не продумывают заранее его архитектуру .
То есть к примеру им нужно создать какой-то сложный сервер , который принимает 10 тыс клиентов , должен сохранять данные в виде аватарки , никнейма и так далее .
Должна быть возможность изменить определённые данные , возможно вам нужна определённая авторизация и прочее .
И они просто начинают писать данный проект .
То есть создают файл WePHR и начинают писать сервер .
Но в чём же здесь ошибка ?
А ошибка в том , что если вы не продумаете архитектуру , и у вас будет сложный проект , вы тысячу раз его потом будете переписывать .
Потому что изначально вы не знаете всех мелочей , когда у вас нет даже представления о том , как это будет работать , вы запишите сначала в одной структуре , потом вы поймёте , что это не работает , потому что если пользователь меняет данные , нужно что-то подключить , вы начнёте это всё менять , потом в определённый момент вы поймёте , что проект вообще полностью не так собран , вам нужно его удалить и написать всё сначала уже правильно .
Так вот если вы потратите хотя бы 15 минут , того чтобы продумать как это будет работать , либо же даже потратить несколько часов на то чтобы это продумать , как это будет всё сохраняться , в какую базу данных , почему именно база данных , а не например обычный JSON файл или ещё что то , какая именно база данных , тут тоже нужно понимать скорость и так далее .
Возможен также алгоритм шифрования , как вы будете безопасно передавать данные , которые вам передал клиент .
Это всё нужно заранее продумать для того , чтобы у вас не было потом проблем .
Когда у вас полная структура проекта , вы можете просто взять и начать её писать .
Итак , девятая ошибка очень смешная , когда у вас есть определённый список , любой итриумый объект , по которому можно пройти с циклом .
Так вот некоторые разработчики делают что-то подобное .
Они создают цикл , ставят ренч , потом вычисляют длину иттерируемого объекта , делают -1 для того чтобы не выйти за границы этого значения , потом обращаются к объекту и его индексу .
Так вот , в итерируемых объектах уже реализованы те методы , которые позволяют просто бежать по циклу .
То есть вы можете просто использовать цикл for без ranch , просто написать ваш итерируемый объект , например ваш список , и вы цикли , вы будете сразу же бежать по списку .
Очень смешная ошибка , но многим думаю поможет .
10 очень важная ошибка , когда вы делаете программы на 200+ строк в одном файле .
Возможно вам так удобнее , но это огромная ошибка которая может разрушить все ваши проекты .
Я сам помню как давно еще писал проекты в одном файле на 1000 и более строк .
Во первых по такому коду очень сложно ориентироваться , поэтому лучше сразу научитесь делать модульную структуру .
Разбейте вашу программу на отдельные маленькие компоненты , где каждый компонент выполняет свою определенную задачу , и не связан с другими компонентами .
Тогда вы сразу знаете вы в каком модуле что у вас лежит , какие там функции и так далее .
Если это модуль-сервер , то вы можете внутри него создать отдельные Python файлы .
Например , файл для создания защищённого соединения , файл для работы с базой данных , который будет после получения данных как-то взаимодействовать с базой , выдавать нужный вам ответ .
Ну и также файл для обработки сообщений .
Уметь писать такие программы это очень важно , потому что без модульной структуры создать нормальную программу , которую вы сможете легко поддерживать , расширять и так далее у вас просто не получится .
Если нужно видео , где я покажу как создать модульную структуру , давайте попробуем набрать 1000 лайков .
А также сделаю видео о том , как я делаю модульную структуру , когда я их распределяю на сущности и так далее .
И далее у нас идёт одиннадцатая ошибка это связывание много кода между собой когда он не может работать отдельно .
То есть когда внутри вашего кода выполняется сразу много разных действий и которые не реализованы в отдельных функциях .
Если вдруг на каком-то этапе будет ошибка , то не выполнится вообще никакой код .
Потому что код связан друг с другом и не может выполняться отдельно .
Такое же было у меня в том проекте , где я писал всё в одном файле .
Так вот у меня вызывалась функция , которая проверяла соответствие значений и потом из себя же другой код запускала .
Потом я получил ошибку .
У меня была функция на 200+ строк .
Я понял , что так делать нельзя , потому что я сидел в отладчике примерно 2 дня и вообще не мог понять , почему здесь ошибка .
И потом до меня дошло , что нужно разделять код на мелкие компоненты , которые не могут вызывать ошибки .
То есть у вас есть маленький компонент , который делает определенную задачу , и вы же его используете далее .
Примерно также реализовано и в Java .
Я смотрел Java код и очень сильно удивлялся , почему под маленький кусочек кода выделяют отдельный метод .
То есть у них даже для того , чтобы просто вернуть значение , выделяется отдельный метод .
Для того , чтобы просто загрузить картинку , выделяется также отдельный метод .
То есть для каждого действия , которое отличается как-то между собой , у них отдельный метод .
Я изначально это не мог понять , но потом понял , что так намного лучше , потому что маленькие компоненты очень легко расширять , они у вас вообще никогда не упадут , потому что там вообще не может произойти ошибка , это одна , две , три строчки кода .
Также представьте , что вы пишите код построчному , у вас есть только один файл и это ваша программа .
И в выданной программе у вас 10 000 строк кода .
Как думаете , где будет проще ориентироваться ?
В этом файле или в файле , где у вас под каждую задачу свой модуль .
В каждом модуле под каждое действие свой файл , внутри которого несколько функций , например на 10 строк кода .
Это сложно объяснить , но попытайтесь просто разделить вашу программу на компоненты .
Вам нужно записать или прочитать что-то из базы ?
Делайте две отдельные функции для этой цели .
Поместите в отдельный модуль , который будет служить чисто для обработки запросов базы , внутри которого уже будет данный функционал .
Во-первых , Вы не будете дублировать одинаковый код по 100 раз , и Вы сможете использовать его повторно , просто обращаясь к модулю .
Во-вторых , если у Вас будет ошибка , намного проще её исправить в одном месте и Вы одной функцией на 10-20 строк кода , чем по всей программе , где Вы продублировали данный код .
А представьте , что будет , если у вас всё это ещё и в одном файле .
Такие мелкие компоненты очень легко контролировать и программа практически не вызывает ошибок .
Чего нельзя сказать про огромный код , где ничего не разделяется на компоненты , где сразу идёт чтение с базы , проверка на запись в базу , потом ещё отправка отчёта и всё прямо в одном месте .
Если вы знаете другие ошибки новичков , не забывайте написать об этом в комментариях .
Также у нас было предыдущее видео , где также были ошибки новичков .
Вы также можете его посмотреть для того , чтобы ещё лучше прокачаться в данном плане .
Давайте попробуем набрать 1000 лайков под данным видео , это очень сильно мотивирует на создание новых видео .
И также если вы впервые на канале , то подписывайтесь , так как у нас очень много полезного контента по Python и другим технологиям .