Правила хорошого тону при оформленні текстів программ

Є багато різних дисциплін, в яких на практичних / лабораторних заняттях студентам потрібно написати ту або іншу програму на  мовою програмування. І студенти роблять це за принципом "абыкакнитьработало", абсолютно ігноруючи елементарні правила оформлення текстів своїх програм. На зауваження викладачів, як правило, не реагують, особливо на молодших курсах. До випускного курсу розумнішають, починають розуміти. Втім, геть емоції.  Вихідний текст програми - це, за великим рахунком, такий же текст, як вірші, оповідання, web-сторінка. Подивіться на цей же абзац, тільки трохи пошкоджений:

Есть    много разных дисциплин   , в кот           орых на  практических/лабораторных заня                                         тиях   студен там нужно напис ать ту или                                 иную програ                                 --мму на том или ином языке                    программирования        .            И делают они это   ,          согласно нашим наблюдениям, по пр          инципу "                               аб               ы какнить раб               отало", совершенно игнорируя элемент            арные правила офо                          рмления текстов св                          оих програ                мм. На замечания пре под авателей      ,  как правило, не     реаг ируют ,особе         нно на младших                      курсах.К пят ому курсу ум неют,нач инают понимать.Впр о чем, дол_ой эмоции. Итак,тексты программ.              Исходный            текст про       граммыэто      ,по.  большому счету,такойже текст,как стихо     тво     рение,р     ассказ, web   -  страничка. Посмотрите на это  т же абзац, только               слегка п               окоре         женный:

Чи Не правда, читати і РОЗУМІТИ таке не дуже зручно і приємно? Ну так от нам, викладачам, теж дуже незручно читати і РОЗУМІТИ Ваші програми, написані у стилі "як руки на клаву лягли", особливо з екрану, і особливо-особливо-особливо, коли Ви, зневірившись знайти помилку, за якої Ваша програма не працює, звертаєтеся за допомогою до нас. "Ой, а подивіться, чому у мене тут ця не працює?". Буває таке? Буває. А я скажу, що частково причиною помилки може бути як раз те, що програма абсолютно потворно відформатована і Ви просто НЕ БАЧИТЕ безглуздий ляпи типу "там не стоїть дужка".

Так ось, Шановні студенти! Якщо Ви хочете трохи полегшити життя собі та викладачам, то Ви ПОВИННІ форматувати вихідні тексти Ваших програм так, як викладено нижче. А викладачам я настійно раджу ВІДМОВЛЯТИСЯ від пошуків помилок у програмах, якщо вони не задовольняють нижеприводимым вимогам.

Як відомо, людям властиво помилятися. Особливо це вірно щодо програмістів. Практично будь-який написаний вами текст програми буде містити помилки і значна частина часу буде йти на їх пошук і виправлення.

Тим не менш, практично всі досвідчені програмісти пишуть красивий, розумний і зрозумілий код, а отже, це дійсно важливий момент в навчанні програмування. І дуже бажано до гарного тону написання коду програм звикати відразу. Звідси випливає уявлення про стиль програмування. Існують певні правила написання програм, дотримання яких дозволяє зменшити вірогідність появи помилок. Програми (особливо такі прості, як вам доведеться писати на початковому етапі) можуть правильно працювати і при порушенні цих правил, проте все ж слід дотримуватися їх. Додатковий час і зусилля, які будуть на це витрачено, окупляться згодом. Саме візуальна ясність дозволяє простіше розбиратися в коді, написаному а це принципово важливо при розробці щодо серйозного продукту.

Дотримання цих правил робить візуально очевидною логічну структуру вашої програми. Створення скільки-небудь складної програми без цього виявляється неможливим. Для того, щоб ваша програма виглядала гарно, зовсім не потрібно творчості, як художнику! Навпаки, будь-який творчетсво в оформленні створює шедеври типу першого прикладу в цій статті. Існують жорсткі правила, які потрібно дотримуватися, тоді ваш код буде легко читатися будь-яким програмістом.

Під оформленням ми будемо розуміти розміщення симоволов, які не впливають на виконання програми, але визначають зовнішній вигляд вихідного коду. Це табуляції, пробіли та переклади рядків. Текст програми - це те, що розробник бачить перед очима більшу частину свого робочого часу. Дуже важливо, щоб ви отримували задоволення від цього видовища, а для цього в коді повинні панувати чистота і порядок.

Отже, почнемо. Перш за все, дозвольте нагадати, що стандартний розмір екрану - 80x25 символів (знакомісць). Це не чиясь примха, саме такі розміри найбільш комфортні для сприйняття. 80 символів у рядку максимум, якщо більше, читати незручно.  Тепер приступимо безпосередньо до правил оформлення вихідних текстів програм. Найпростіше, але при цьому дуже важливе стилістичне правило описує те, як треба розташовувати текст програми. Отже, слід діяти наступним чином:

Правило #0, про коментарі

Перше, про що хотілося б сказати, це, звичайно ж, коментарі. У тих місцях, де виконуються будь-які складні дії, потрібно вставляти коментарі, щоб ви самі ж через час змогли пригадати, як реалізували ту чи іншу частину алгоритму. Та й іншим програмістам, при перегляді вашого коду, все буде зрозуміло. Також, якщо ви працюєте в консолі, то потрібно обов'язково виводити підказку для користувача про те, що від нього вимагається і про те, що програма виводить.

Правило #1, про кількість операторів в рядку

1. Кількість операторів на рядку повинно бути дорівнює 1.

Невірно: a = b; do while (0);  printf("dah-bah-dee\n");

Правильно: a = b;

 do while (0);

 printf("dah-bah-dee\n");

2. Слово var пишеться на окремому рядку.

Наступні за ним описания змінних починаються з нового рядка. При цьому для всіх оголошень робиться відступ ліворуч. Змінні різних типів описуються на різних рядках. Правильно: var {Слово var на окремому рядку без відступу зліва} x, y: real; {Описания змінних з нового рядка. Відступ ліворуч} i: integer; {Змінна іншого типу на окремому рядку, з тим же відступом} 3. Після знаків пунктуації завжди ставиться пробіл.

Одне з простих правил говорить, що після знаків пунктуації завжди ставиться пробіл. Не слід нехтувати цим правилом і при написанні програм. Пробіл завжди слід ставити після коми та пробілів (як у наведеному вище прикладі).

4. Слова begin і end

Слова begin і end, що обмежують розділ операторів пишуться без відступу. Весь же текст програми між ними знову пишеться з відступом в ліво. 5. Умовний оператор

Умовний оператор записується наступним чином: begin ... {Перший рядок з відступом вліво} if <умова> then {слів begin з тим же відступом, що й слово if} begin  <Оператори 1>{Відступ у двічі більше, ніж у if і begin} {end обов'язково з тим же відступом, що і відповідний begin} end 

else begin  <Оператори 2>{Відступ на два пробіл більше, ніж у if і begin} end; Приклад НЕправильного оформлення: {Змінні на тому ж рядку, що і var} var x, y: real; begin readln(x, y); {Оператор на тому ж рядку, що і if} if x > y then writeln('Max(x, y) = x',) else  {begin з відступом щодо if}  begin  writeln('Max(x, y) = ', y);  end; {readln без відступу} readln; end.

Всередині умовного оператора можуть розташовуватися люби інші оператори, у тому числі і інші умовні оператори. Те, що знаходиться всередині них, пишеться з ще більшим відступом.

Наприклад: {Змінні на тому ж рядку, що і var} begin readln(x, y, z); if x > y then begin  if x > z then  begin  {writeln з ще більшим відступом}  writeln(x);  end; end; end. Загальна ідея така: відступи показують підпорядкованість (вкладеність) структур у вашій програмі. Текст всередині розділу операторів - робимо відступ, всередині оператора умовного - ще більший відступ, усередині ще одного оператора умовного - ще більший відступ і т. д.

Правило #2, про горизонтальні відступи

Перша і, мабуть, найважливіше правило - це відступи, а точніше горизонтальні відступи. У нас в університеті навіть відмовлялися приймати листинги програм, у яких немає відступів, або вони зроблені не правильно. Навіщо потрібні відступи ми розглянемо на наступному прикладі