Для большинства программистов эта статья не станет чем-то новым, ранее неизвестным. Об этом пишут все, кому не лень, и почти в каждой книге о программирования для начинающих вы найдёте упоминание о хорошем стиле программирования.
И всё же я решил внести и свою лепту в этот вопрос. Потому что довольно часто мне приходится работать с чужим кодом, и не только от новичков. И я вижу, что 90% программистов пренебрегают качеством оформления кода.
Да, кто-то думает об оптимизации по скорости, кто-то об оптимизации по размеру. Многие стремятся сделать хороший пользовательский интерфейс. Но почему-то почти никто не уделяет внимания оформлению самого кода.
В итоге смотришь изнутри чужие программы, и думаешь, ну как же так, блин? Иногда видно, что программу делал опытный человек, поскольку видишь какие-то вещи, которые ранее и сам не знал. Но почему же всё написано как курица лапой, и без единого комментария?
Ну ладно, хватит жалоб. Переходим к сути.
Хорошая программа должна:
- Правильно работать
- Эффективно работать
- Быть надёжной
- Быть удобной и понятной для пользователя
- Быть читабельной (я имею ввиду исходные коды)
- Быть удобной для внесения изменений
- Быть хорошо документированной
Я постарался расположить эти свойства в порядке убывания важности. Разумеется, самое важное свойство программы - это правильная работа. Однако это не значит, что остальными надо пренебрегать. В некоторых случаях (для относительно простых программ) можно отказаться лишь от документирования. Но и здесь надо делать краткие описания хотя бы в комментариях.
Про необходимость обдумывания (проектирования) программы я здесь не говорю. Прямого отношения к стилю это не имеет.
А вот что касается хорошего стиля, то здесь надо понимать, что это не только хорошо для тех, кто будет разбираться с вашими исходникам после вас, но это хорошо и для вас.
Потому что хороший стиль программирования уменьшает количество ошибок, делает логику программы более прозрачной и облегчает её понимание другими программистами. Это важно, если вы работаете в команде или если есть вероятность того, что с вашей программой в будущем будет работать другой. И даже если вы не собираетесь передавать свою программу третьим лицам, вам же самим будет очень трудно в ней разобраться через полгода.
Так что позволю себе дать несколько советов, которые я слышал от других и к которым я пришёл на практике.
- Пишите комментарии. Миллион раз вы это слышали. Но я почему-то уверен, что многие из вас не следуют этому совету. Это не значит, что комментировать надо все строки программы. Но хотя бы краткое описание каждой программной единицы (подпрограммы, модуля, структуры данных, класса и т.п.) надо делать.
- Давайте переменным, объектам, подпрограммам и т.п. осмысленные имена. Да, можно назвать функцию MyFun или вообще F. И в некоторых случаях это допустимо. Но в большинстве случаев переменная, функция и т.п. должны иметь понятные имена. Например, GetUserName(), MaterialTemperature. Чтобы встретив их в каком-нибудь 110-м модуле вашей программы, вы примерно понимали, что эта функция делает и для чего эта переменная предназначена.
- Разделяйте блоки кода пустыми строками. Режет глаз исходный текст, где весь код идёт сплошным потоком. Это очень трудно читать и воспринимать. Прокручивая такой текст, часто сложно в спешке определить, где кончается одна подпрограмма и начинается другая. В итоге приходится крутить текст вверх-вниз, теряя время и проклиная программиста, который всё это написал.
- Избегайте недокументированных функций. Не стоит использовать функции, константы, классы и т.п., которые есть по факту, но отсутствуют в официальной документации или в стандарте. Даже если сегодня на вашем компьютере это работает. Потому что это может привести к неприятностям, связанным с совместимостью в будущем (или на другом компьютере).
- Делайте отступы блоков кода. Это прям болезнь всех программистов. Наверно потому создатель Python и ввёл в язык отступы вместо скобок, чтобы заставить программистов эти отступы делать. Ну правда, невозможно уже читать код, где всё сливается в одну строку, и где непонятно, когда заканчивается очередной if/for/case и начинается следующий блок.
Понимаю, что тем, кто и так придерживается хорошего стиля, эти советы не нужны. А те, кто НЕ придерживается, скорее всего и сейчас пошлют меня нахрен, даже не дочитав статью. Но попытаться-то я хотя бы должен был )))
На этом всё. Подписывайтесь на канал или подключайтесь к Телеграм-каналу, чтобы ничего не пропустить.