Здравствуйте! В этом видео мы поговорим с вами о культуре программирования. Бескультурный программист, культурный программист — чем они отличаются? Внешним видом или чем-то другим? В чем состоит эта культура? Это культура создания кода, неважно, как программист выглядит, важно то, какой код он создает. И принципиально здесь следующее: код пишется один раз, а читается много раз. Поэтому, более того, он читается не вами, поэтому очень важно, критически важно повысить readability, читабельность программного кода. Понимаете? Кажется, что мы программируем для компьютера, мы программируем компьютер, но программный код, который мы создаем, все-таки для человека. Он должен быть человекоудобным. Итак, для этого в языке Python существует стиль кода, если в других языках есть много разных вариантов, стилей, то в Python есть универсальный UTF-8. И мы с вами сегодня пройдемся по нему детально. Внешний вид кода — это пробелы в выражениях и инструкциях, комментарии, также правила имён и еще общие замечания. В этом видео мы коснемся только первых трех пунктов. Внешний вид кода. Первое. Кодировка должна быть только юникод, при этом, кстати, сами идентификаторы переменных функций, да и комментарии тоже должны быть ASCII. Такое вот максимально обще правило, чтобы точно все было прочитанное понятно. Далее. Никогда не смешивайте табуляцию и пробелы. Если Python 2 относился к этому терпимо, то в Python третьей версии — это категорически недопустимо. Либо табуляция, либо пробелы, причем желательно, пробелы, по четыре пробелы на отступ. Далее. Максимальную длину строки желательно ограничить. До сих пор много устройств, у которых 80 символов — это предельная ширина. 79 знаков — максимальная ширина. При этом можно воспользоваться теми скобками, которые уже есть в выражении, если вы вызываете функцию, у вас длинный список параметров, возьмите после какого-то параметра, переведите каретку и у вас интерпретатор автоматически увидит — скобки правой нет — и начнет продолжать читать выражение со следующей строки. Можно воспользоваться обратным слэшем, если просто выражение, в котором плюсы-минусы умножения нет скобок, пожалуйста, ставим слеш, правда, желательно, чтобы перенос шел после бинарного оператора, а не перед ним. Если выражение у вас в принципе длинное, а скобок в нем нету, а вы не хотите ставить в нем обратно слеш, это и есть в этом причина, можно взять и обнять его круглыми скобками. Например, если у вас длинный условный оператор, в котором у вас "или", "и", "не", правда, для этого существуют и другие методы, которые мы пройдем в следующей уже части курса. Далее. Ставьте пробелы. Почему ставить пробел это хорошо? Код без пробелов скомканный и нечитаемый. Мы разберемся, где ставить пробелы. Во-первых, окружайте ровно одним пробелом оператора присваивания. Это касается "равно", "плюс равно" и так далее. Оператора сравнения, опять же, любое "равно", "не равно", "больше либо равно" и так далее. Логические операторы. Вот этот энтузиазм "Ставьте пробел" он иногда сталкивается со следующим, что пробелов ставят много, не по одному пробелу слева-справа, а сразу много и пытаются выровнять оператора в одной строке с операторами в другой. Особенно часто с оператором присваивания. "Х равно", "Y равно" и выравнивают по "равно". Ни в коем случае. Строго по одному пробелу. Это выравнивание излишне. Кстати, арифметические операторы тоже требует пробелов, но не так строго. Иногда бывает в операции умножения, в операции деления пробелы слева-справа ставить неудобно, просто из-за читаемости целого арифметического выражения. Оно группирует члены. Избегайте пробелов в следующих ситуациях: сразу после или перед скобками, неважно какими, перед запятой, перед точкой запятой, перед двоеточием пробел не ставится. Перед открывающейся скобкой при вызове функции. Это бывает просто болезнь, люди хотят имя функции — пробел — скобка. Не надо. Перед открывающейся скобкой, после которой следует индекс или срез, та же болезнь, только с квадратными скобками. Дальше пустые строки. Пустые строки очень сильно повышают читабельность кода. Во-первых, они логически отделяют куски функции друг от друга. Функция одна, идет исходный код, но вы можете просто взять и сделать разрыв, сразу понятно, один кусочек закончился, пошел другой. Дальше. Методы класса. Их надо отделять одной пустой строкой друг от друга, иначе они будут просто сливаться в единую кашу. Конечно, сами классы или функции верхнего уровня тоже надо отделять друг от друга дополнительной пустой строкой, то есть получается, что две пустые строки. За счет этого у вас класс, в котором есть методы, он не сливается с другим классом, не кажется, что это всего лишь продолжение предыдущего класса или функции верхнего уровня. Теперь о комментариях. Первый, наиболее важный пункт — не надо комментировать очевидное. Не надо. Там, где написано "Х равно Х плюс один", не надо "Х увеличивается на единицу". Второе. Комментарии должны быть актуальными. Лучше отсутствие комментария, чем плохой, устаревший, неправильный комментарий. Дальше. Желательно использовать блочные комментарии. Смотрите, у вас есть исходный код, который что-то делает, вы над ним объясняете его смысл. Собственно, что происходит. При этом вам нужно использовать предложения или фразы на английском языке, эти предложения или фразы должны быть с отступом, который соответствует отступу кода ниже. Дальше, встрочные комментарии, то есть короче, комментарий, который на той же строке, где и инструкция. Делаете хотя бы два пробела после инструкции перед тем, как начинать комментарий и после решетки тоже один пробел перед началом фразы или предложения. И еще, опять же, иногда комментарий не нужен. Лучше заменить его документ строкой, это более высокий уровень пояснения кода, более высокий уровень повышения читабельности. Язык комментариев. Очень важно писать комментарии на английском языке, это действительно важно. Вы можете быть уверенными, что ваш программный код никогда никто не откроет будучи носителем другой языковой культуры. Вы написали какую-нибудь программу под свободной лицензией, кто будет ее поддерживать? Вы думаете, что русские? А, может быть, какой-нибудь индус, или китаец, или кореец? Английский язык является международным языком для программистов. Пишите, пожалуйста, на английском и пишите грамотно, пишите грамотно. Если все нации будут так поступать, то мы сможем читать комментарии. Код будет действительно читабельным. Дальше. Первое слово фразы или предложения пишем с большой буквы, в конце ставим точку. Логично, да? Правда, если фраза или предложение короткое, то точку ставить необязательно. Дальше. Если у вас комментарий представляет из себя несколько предложений, то предложения друг от друга отделяйте двумя белыми, то есть после точки два пробела. Не касается ситуации, когда у вас предложение заканчивается на строке и у вас точка в конце строки, тогда висячие два пробела можно их, конечно, не ставить. Конечно, на этом разговор о стиле не заканчивается и в следующем видео вы узнаете, как правильно именовать функции, переменные и все другие объекты и дополнительные замечания будут.
