Вы когда-нибудь оглядывались на старый код, который вы написали, когда впервые начали программировать? У меня, это оставило выражение замешательства на моем лице. Конечно, код может работать, но он выглядит как что-то, что вы нашли под сиденьем автобуса. Как и в случае с той штукой, которую вы нашли под сиденьем автобуса, никто не хочет трогать ваш код, они просто не знают, что он делает.
Итак, вот мои десять советов о том, как писать более чистый код, с примерами. Я буду использовать Python для примеров, не волнуйтесь, если вы не знаете Python, так как это не сложный код.
Ниже показана мерзкая какашка, от которой глаза болят, когда я смотрю на нее. Я не буду говорить вам, что он делает, но мы будем постепенно применять правила к этим функциям и превращать их в чистый код.
Вы догадались, что делает код?
1. Функции должны делать одну вещь
Это, безусловно, мой любимый совет, когда я впервые пытался поддерживать гигиену своего кода. Если подумать, у небольших функций есть некоторые дополнительные преимущества.
Кудрявый: Ты знаешь, в чем секрет жизни?
Кудрявый: Это. [поднимает один палец]
Митч: Твой палец?
Кудрявый: Одно. Только одно. Ты придерживаешься этого, а остальное ни хрена не значит.
Митч: Но что такое «одна вещь»?
Керли: [улыбается] Вот что вы должны выяснить.
Функции должны делать одно и делать одно. Получив эту функцию, вы можете использовать ее столько раз, сколько захотите. Это также обеспечивает согласованность вашего кода. Если бы у вас было 10 разных функций, делающих одно и то же, и если бы в одной была ошибка, вполне вероятно, что и в других тоже была бы ошибка.
Меньшие функции имеют и другие преимущества, я считаю, что их гораздо проще тестировать. Я считаю, что мне придется изменять их меньше в будущем. Но когда мне нужно изменить их, их проще изменить. Меньшие функции легче читать и повторно использовать в будущем. Наконец, функцию, которая делает это, намного проще назвать.
Давайте разделим этот беспорядок функции.
Хотя теперь программа разбита на логические части, по-прежнему трудно сказать, что происходит, потому что имена очень плохие.
2. Давать хорошие имена вашим переменным, функциям, методам и классам
Я бы предположил, что на данный момент большинство читателей могут понять, что делает Программа. Какая разница, когда ты правильно называешь вещи. Вот хороший контрольный список для того, чтобы дать имя чему-то.
Имя должно быть максимально описательным.
Имена должны быть максимально описательными. За ними должно стоять намерение. Например, total_downloaded_mb намного лучше, чем downloaded. Ваш код — не поэма, интерпретация читателей не должна решать, что делают переменные.
Имена не должны содержать свой тип.
Если вы указываете тип переменной в имени переменной, а это не соответствует стандарту кодирования вашей компании, то вы просто излишне запутываете свой код.
Я привел пример на C, потому что люди не делают этого в языках с утиным типом.
Имена должны уменьшить потребность в комментариях.
Мы поговорим о комментариях более подробно позже, но. Хорошо названные переменные будут описывать, что делает ваш код, не загромождая его комментариями.
Обе указанные выше функции будут работать с одинаковой скоростью. Но один из них короче и легче читается.
Избегайте таких имен, как «temp1
Это не нуждается в объяснении, вы знаете, кто вы!
Имя должно быть как можно короче.
(За исключением счетчиков циклов)
Имена должны быть максимально короткими и максимально описательными. Я думаю, что этот пункт имеет много личных предпочтений. Пишите, какое имя вам больше нравится.
1. down 2. downloaded 3. downloaded_mb 4. tot_downloaded_mb 5. total_downloaded_mb 6. total_downloaded_in_megabytes
Еще одно замечание: никогда не используйте o или i в качестве переменных-счетчиков, потому что они слишком похожи на 0 и 1.
Если вы выбрали четыре… вы мне нравитесь.
3. Комментируйте только тогда, когда это необходимо
Код должен говорить сам за себя. Если вам нужно прокомментировать это, потратьте это время, чтобы дать лучшие имена переменных. Если вам все еще нужно прокомментировать это, надеюсь, ваш комментарий будет меньше, чем в прошлый раз.
Однако я согласен с комментариями «TODO:». Причина, по которой я с ними согласен, заключается в том, что ваш код не должен выпускаться вместе с ними. Пока вы держите их в курсе, они могут использовать полный инструмент сервера.
Я также согласен с комментариями «Внимание:». Это потому, что вы можете предоставить другим разработчикам полезную информацию о функциональности, которая может быть не очевидна при первом чтении кода.
4. Упростите утверждения
Обратите внимание на строку 26-28? Я упростил одно, но не другое. Чрезмерное упрощение сложных операторов может сделать их трудными для чтения и, следовательно, менее понятными.
Строка номер 2 просто меняет значение в точке x на значение в точке y. это короткая рука для письма.
temp = y y = x x = temp
Но я бы предпочел увидеть длинную версию, а не строку номер 6. Это потому, что строка номер 6 слишком сложна и, вероятно, нуждается в комментариях, чтобы сопровождать ее.
5. Нет повторений
Если вы делаете одно и то же несколько раз, просто напишите для этого функцию. Имя функции будет действовать как комментарий, описывающий, что делает этот код. Кроме того, у него есть дополнительное преимущество: если у вас есть ошибка в коде, вам не нужно вносить несколько изменений.
Ваш код должен читаться как книга
Функции должны следовать в хронологическом порядке :)
