Опрятность создания исходного кода и как это поможет мне в дальнейшем.

Конечно существует множество тем, которые я мог бы выбрать в качестве темы своего индивидуального раздела, связанных с моими увлечениями игры на гитаре или фортепиано, а может и с увлечениями велосипедной ездой или прочими, как я считаю, абсолютно неуместными рассказами в рамках портала магистров ДонНТУ. Таким образом темой моего индивидуального раздела я решил выбрать, казалось бы, давно изъезженную тему опрятности написания программного кода. Но, как оказалось, правила форматирования исходного кода не такая уж и тривиальная тема. Систематичность и правильность форматирования программного кода игнорируются многими программистами. Особенно это касается тех людей, которые всегда работали лишь сами на себя и никогда не работали сообщя с несколькими программистами. А кто же попадает в категорию таких программистов? Конечно подавляющее большинство студентов и самоучек.

Зачем же я вообще поднял эту тему, спросят те, кто, скорее всего, никогда не работал в команде программистов. И этот вопрос логичен и оправдан, ведь главная задача программиста написать качественную программу, которая будет работать и приносить пользу, и не важно, как будет выглядеть её исходный код. Но на практике выходит так, что один программист не в состоянии написать более-менее большой и функциональный продукт за отведенное время. Вот тут-то мы и сталкиваемся с проблемой читабельности исходного кода. Ведь два человека, которые пишут небрежный код и пытаются работать над одним общим проектом тратят уйму времени на то, чтобы понять, что же написал его коллега. А если работает более двух человек, то мы получим просто хаос, на разбор которого тратится драгоценное время и в результате при командной разработки мы работаем еще медленнее чем в одиночку. Да что уж там говорить, даже работая в одиночку и формируя код как попало и не комментируя его, программист не сможет разобраться в собственном коде, открыв его спустя какое-то время (уверен, каждый программист сталкивался с такой проблемой).

Таким образом я плавно подхожу к выводу, напрашивающемуся самому по себе, – нужно придумать для себя определенные правила форматирования кода и всегда придерживаться только их. Начать с банального установления отступа после каждого функционального блока и соблюдения одной из типов расстановки обрамляющих скобок (открывающая скобка на той же строке, что оператор или же – открывающая скобка всегда на новой строке). Далее я опишу и другие советы по форматированию и систематизации исходного кода, но пока что продолжим тематику командной разработки.

Выработав для себя любой удобный стиль форматирования и организации кода старайтесь постоянно придерживаться его. Уже за пару недель (если вы конечно сталкиваетесь с программированием хотя бы 3-4 дня в неделю, иначе понадобиться немного больше времени) вы привыкните к самосозданным правилам и вряд ли станете писать как раньше.

Таким вот образом, после недолгого периода страданий и борьбы с собой вы получаете не только опрятный и легко читабельный код, но и некоторые дивиденды! Все они, конечно же, связаны с трудоустройством. Первое преимущество – все ваши программные творения могут быть потенциальными претендентами на попадание в портфолио и если опытный менеджер попросит предъявить его, то он обратит внимание не только на функциональность, но и на стиль программирования. Второе преимущество даёт о себе знать в том случае, когда вам дадут тестовое задание, которое нужно выполнить чтобы пройти собеседование. Ситуация та же – сдавая сделанное вами тестовое задание, написанное опрятно и читабельно, вы явно расположите к себе проверяющего и с большей вероятностью получите одобрение. Третий плюс от того, что вы привыкли писать свой код опрятно и придерживаетесь одного стиля появится тогда, когда вас примут на работу. Как я писал раньше – большинство серьёзных программных продуктов требуют командной разработки, а это означает что вас заставят придерживаться одного общего стиля форматирования исходного кода. Скорее всего этот общий стиль не будет полностью соответствовать вашему стилю, но ведь вы привыкли к нему однажды, а значит сможете привыкнуть и к новому, и сделаете это гораздо быстрее, чем те, кто никогда не пытался систематизировать свой процесс создания программы.

Советы по ключевым аспектам.

• Установить для себя фиксированный отступ. Чаще всего это либо 4, либо 2 пробела (лично я использую 2 пробела – вполне достаточно для явного визуального выделения иерархии кода). Также желательно выбрать что-то одно – либо табуляции, либо пробелы. Я использую только пробелы. Почему? Во всех редакторах пробел имеет одно и тоже отображение, в то время как табуляция не отличается такой кроссплатформенностью.
• Один перенос между функциями и не более одного переноса подряд в теле документа. Если ставить более одного переноса подряд, то создается впечатление что тут что-то вырезано или недоделано. А также просто сбивает с толку.
• Придерживаться алфавитной сортировки. Старайтесь сортировать по имени ваши функции, имена ассоциативных массивов и константы. Это очень полезная привычка, которая ускоряет вашу работу, особенно при работе с классами или файлами, содержащими в себе десятки функций. Пролистав некоторую часть файла вы легко сориентируетесь по названию функции стоит ли листать дальше или же отмотать назад и понять, есть ли здесь вообще необходимая вам функция, чего нельзя с уверенностью сказать при беспорядочном расположении функций. Аналогичная ситуация и с именованием смещений в ассоциативных массивах, и с объвлением констант.
• Форматирование условий, в которых есть константы. Такой формат мне не привычен, но он очень правильный, т.к. при такой формулировке у вас будет подстраховка средой программирования от ошибки $some=10 (присвоение). Популярная и сложно находимая ошибка.
  
• Использовать константы вместо прямого сравнения. Старайтесь использовать продекларированные константы в вашем коде, вместо простых чисел, строк и т.д. К примеру, вы сравниваете такое выражение if($i_temperature >= 250 ). Что нам говорит такая запись? Что есть некоторое значение переменной $i_temperature и что произойдет если значение нашей переменной станет больше или равно некого числа 250. И нам прийдется задуматься, а порой и серьёзно поломать голову, чтобы понять что это за число и почему именно 250, а не 320... Однако если открыв исходники мы увидим следующе if($i_temperature >= $i_critical ) (где-то выше объявлена переменная $i_critical = 250), то сразу становиться ясно, что если температура больше или равна значению критической, то мы должны что-то предпринять.
  
• Два формата структуры IF ELSE. Если тела всех частей инструкции состоят не более чем из одного выражения, то инструкция без операторных скобок. Если же тело хотя бы одной из частей состоит более чем из одного выражения, то операторные скобки нужно писать во всех блоках.
  
• Использовать префиксы. Для того, чтобы вам было легче разбираться в большем массиве написанного программного кода очень полезно использовать префиксы. К примеру, чтобы не держать в голове «а какого же типа переменная var», которая была объявлена сотню строк ранее, вы можете назвать ее i_var, что будет сигнализировать вам о том, что эта переменная типа integer или s_var – означает что переменная типа string.
• Названия функций. Все названия функций должны быть информативны и содержать в себе глагол. Если функция отвечает этим двум достаточно простым требованиям, то существенно улучшается понимание того, что же конкретная функция должна делать уже до того, как вы успели изучить её содержание.