Отправляет email-рассылки с помощью сервиса Sendsay

Новости Школы Программирования

Рассылка закрыта

При закрытии подписчики были переданы в рассылку "Обзор инструментов SEO-оптимизатора и методов продвижения" на которую и рекомендуем вам подписаться.

Вы можете найти рассылки сходной тематики в Каталоге рассылок.

  Март 2010   →
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
Автор
Школа Программирования

Статистика

195 подписчиков
0 за неделю
←   Все выпуски   →

Новости Школы Программирования - 5 правил и 1 пожелание по оформлению текста программы


О том, зачем нам вообще культура кода, и что мы под ней подразумеваем, было описано в этой статье. Теперь перейдем к конкретным правилам, пока что самым простым. Здесь мы опишем правила, не связанные с какой-либо конкретной нотацией или языком. Если думаете, что данная тема не очень принципиальна, то сильно ошибаетесь. Именно визуальная ясность позволяет проще разбираться в уже написанном коде, а это принципиально важно при разработке относительно серьезного продукта.

На что следует обращать внимание

  • Длина строки не должна превышать 80 символов. Помню ещё на первом курсе наш первый преподаватель по программированию задавал нам неопределенный вопрос «Скооолько?», и мы как стадо баранов ему «вооосемьдесят»)) Да, эту цифру мы знали хорошо. С нас требовали, чтобы строчки не превышали этой длинны, то есть чтобы помещались на экране монитора. Обычно приходится переносить либо вызовы функций с большим количеством аргументов, либо какие-нибудь сложные условия в конструкциях типа if. Но переносить надо обязательно, так, чтобы весь код был виден без прокручивания экрана по горизонтали.
  • Используйте табуляцию вместо пробелов. Желательно пользоваться именно табом, вместо пробелов. Это и быстрее (табуляция обычно соответствует нескольким пробелам), и удобней для редактирования, когда нужно, например, сдвинуть код влево. Во многих средах программирования в тулбаре есть кнопки для сдвига влево или вправо блоков кода. Достаточно выделить нужный кусок кода и нажать на соответствующий значок.
  • Следите за правильным количеством отступов внутри всех конструкций. Количество табуляций перед кодом должно соответствовать его вложенности. Многие среды программирования сейчас автоматически выравнивают код, но не все, так что следить нужно самому.
  • Функция должна помещаться на экран. Это конечно в идеале, но очень желательно. Если размер функции составляет более двух экранов – это явный признак того, что её имеет смысл разделить на несколько частей. Когда начинаешь программировать какую-то задачу, часто бывает, что нет желания отвлекаться на всякие мелочи, например, вынести в отдельную функцию запись логов и т.п. В итоге каждая функция исходного кода помимо решения своих основных задач, содержит ещё кучу строк левой функциональности, которой просто здесь не место. Помню на третьем курсе, я оптимизировал свой курсач по машинной графике путем удаления четырехсот строк кода, честное слово!) Это к тому, что лучше поздно, чем никогда) Но разумней уделить этому внимание сразу. Стоит отметить, что бывают исключения. Например, если в функции есть оператор switch, то она может быть достаточно громоздкой.
  • Используйте «говорящие» названия функций и переменных. Откажитесь от переменных типа kkk, или функций вроде gdfui(), лучше введите длинное название getDoubleFromUnsignedInt(), зато сразу будет ясно, что происходит. При определенном размере программы использование не говорящих функций и переменных вообще сделает невозможным какую-либо дальнейшую разработку. Один парень, абитуриент, показывал нам программу на ассемблере, изобилующую переменными kkk, mrstb, g, _g. Прога на ассемблере была огромная, как он разбирался во всей своей писанине для меня до сих пор остается загадкой (но парень был очень умным, надо сказать:).
  • Не используйте в качестве имен функций русские слова, написанные транслитом. Это лично мое пожелание. Я убежден, что названия типа risuemKrug() некрасивы, в отличие от drawCircle(), например. Названия с использованием английских слов будут нормально восприняты любым программистом, в отличие от использования русиш нэйминг. Даже если вы не предполагаете, что кто-либо ещё будет смотреть ваш код, всё равно следуйте этому правилу, почему – напишу в конце статьи.

Резюме

Нарушение любого из описанных выше правил сразу бросается в глаза при просмотре чужого кода. Надо ли говорить, что не соблюдение этого минимума формирует негативное мнение об авторе кода. Но важно не мнение окружающих, а ваша собственная эффективность при разработке программ. Если вы не читали первую вводную статью из этой серии, то очень рекомендую. Потому что в ней описано, почему правил нужно придерживаться постоянно, и не делить программы на халтурные и нормальные. Если коротко, то иначе всё вами написанное будет само собой превращаться в халтуру. Описанные выше правила – это самая вершина айсберга. Для каждого конкретного языка программирования существуют отдельные нотации, которые содержат много всего полезного, что можно взять на вооружение, но это - тема отдельной статьи. Пока же предлагаю следовать этим простым рекомендациям всегда и везде. Удачи!)
В избранное