Оформлення вихідного коду#
Візуальне оформлення вихідного коду значно впливає на його читабельність та легкість розуміння. Цей розділ містить рекомендації щодо представлення вихідного коду, розроблені з метою підвищення його читабельності.
Окрім загальних порад, у розділах, які стосуються конкретних ситуацій, наведено більш спеціалізовані рекомендації. Якщо ви не згодні з певними спеціалізованими порадами, ви можете встановити власний набір правил, які все ще відповідатимуть загальним порадам. Ключовий принцип - послідовність та єдність стилю у всьому проєкті.
Повністю узгоджене форматування складно реалізувати або перевірити вручну. Тому ви можете автоматизувати форматування за допомогою інструменту для форматування коду або включити настанови до шаблону автоматичного створення коду. Деякі з рекомендацій та спеціалізованих порад, що містяться в цьому розділі, не можуть бути реалізовані інструментом форматування, оскільки вони базуються на змісті коду Ada, а не на його структурі. Детальнішу інформацію можна знайти в розділах "Примітки щодо автоматизації".
Форматування коду#
Форматування коду Ada стосується його візуального вигляду та структури, а не його функціональності. Сюди входять такі аспекти, як пробіли, відступи, вирівнювання, поділ коду на частини та довжина рядків. Найважливіше правило - це дотримуватися єдиного стилю як в межах окремої частини коду, так і у всьому проєкті
Горизонтальний інтервал#
настанова#
Використовуйте однаковий інтервал навколо роздільників.
Використовуйте той самий інтервал, що й у звичайній прозі.
конкретизація#
Зокрема, залиште принаймні одне порожнє місце в наступних місцях, як показано в прикладах, наведених у цій книзі. Для вертикального вирівнювання, що рекомендується в подальших рекомендаціях, можливо, буде потрібно більше пробілів.
До і після наступних роздільників і бінарних операторів:
+ - * / &
< = > /= <= >=
:= => | ..
:
<>
Поза лапками для рядкових (") та символьних (') літералів, крім випадків, коли це заборонено.
Зовні, але не всередині, дужок.
Після коми (,) та крапки з комою (;).
Не залишайте порожніх місць у наступних місцях, навіть якщо це суперечить наведеним вище рекомендаціям.
Після знаків плюс (+) і мінус (-) при використанні в якості унарних операторів.
Після виклику функції.
Усередині розділювачів міток (<< >>).
До і після оператора піднесення до степеня (**), апострофа (') і крапки (.)
Між кількома послідовними відкритими або закритими дужками.
Перед комами (,) і крапкою з комою (;).
Якщо зайві дужки опускаються через правила пріоритету операторів, пробіли можна додатково видалити навколо операторів з найвищим пріоритетом у виразі.
приклад#
Default_String : constant String :=
"This is the long string returned by" &
" default. It is broken into multiple" &
" Ada source lines for convenience.";
type Signed_Whole_16 is range -2**15 .. 2**15 - 1;
type Address_Area is array (Natural range <>) of Signed_Whole_16;
Register : Address_Area (16#7FF0# .. 16#7FFF#);
Memory : Address_Area ( 0 .. 16#7FEC#);
Register (Pc) := Register (A);
X := Signed_Whole_16 (Radius * Sin (Angle));
Register (Index) := Memory (Base_Address + Index * Element_Length);
Get (Value => Sensor);
Error_Term := 1.0 - (Cos (Theta)**2 + Sin (Theta)**2);
Z := X**3;
Y := C * X + B;
Volume := Length * Width * Height;
обгрунтування#
Добре використовувати пробіли навколо розділювачів та операторів, оскільки вони зазвичай є короткими послідовностями (один або два символи), які можуть легко загубитися серед довших ключових слів та ідентифікаторів. Пробіли навколо них виділяють їх. Узгодженість у пробілах також допомагає полегшити візуальне сканування вихідного коду.
Однак багато з розділових знаків (коми, крапка з комою, дужки тощо ) звичні як звичайні розділові знаки. Якщо у комп'ютерній програмі вони розставлені інакше, ніж у звичайному тексті, це відволікає увагу. Тому використовуйте ті ж інтервали, що і в тексті (без пробілів перед комами і крапкою з комою, без пробілів всередині круглих дужок і т.д.).
винятки#
Єдиним помітним винятком є двокрапка (:). У мові Ada двокрапку корисно використовувати як табулятор або роздільник стовпців (див. Настанову 2.1.4). У цьому контексті має сенс ставити пробіли до і після двокрапки, а не лише після неї, як у звичайному тексті.
примітки щодо автоматизації#
Настанови в цьому розділі легко застосовувати за допомогою автоматичного форматора коду.
Відступ#
настанова#
Дотримуйтесь послідовності у відступах та вирівнюванні вкладених синтаксичних структур, рядків продовження та вбудованих блоків коду.
Використовуйте різну величину відступів для позначення вкладеності та продовження рядків.
Для відступів використовуйте пробіли, а не символ табуляції (Nissen and Wallis 1984, §2.2).
конкретизація#
Зокрема, рекомендується дотримуватися таких правил відступів, як показано на прикладах у цій книзі. Зверніть увагу, що тут зазначено мінімальний відступ. Для вертикального вирівнювання, рекомендованого в наступних настановах, може знадобитися більше пробілів.
Використовуйте перенесення рядків, як наведено у Довідковому посібнику Ada (1995).
Використовуйте три пробіли як основну одиницю відступу для вкладеності.
Використовуйте два пробіли як основну одиницю відступу для рядків продовження.
Мітка відступає на три пробіли:
begin
<<label>>
<statement>
end;
<long statement with line break>
<trailing part of same statement>
Інструкція if та звичайний цикл:
if <condition> then
<statements>
elsif <condition> then
<statements>
else
<statements>
end if;
<name>:
loop
<statements>
exit when <condition>;
<statements>
end loop <name>;
Цикли з ітераційними схемами for та while:
<name>:
for <scheme> loop
<statements>
end loop <name>;
<name>:
while <condition> loop
<statements>
end loop <name>;
Блок і інструкція вибору, як рекомендовано в довіднику Ada Reference Manual (1995):
<name>:
declare
<declarations>
begin
<statements>
exception
when <choice> =>
<statements>
when others =>
<statements>
end <name>;
case <expression> is
when <choice> =>
<statements>
when <choice> =>
<statements>
when others =>
<statements>
end case; --<comment>
Наступні форми запису інструкції вибору економлять місце порівняно з рекомендаціями Ada Reference Manual (1995), а остання з них потребує дуже коротких списків інструкцій. Що б ви не обрали, будьте послідовними:
case <expression> is
when <choice> =>
<statements>
when <choice> =>
<statements>
when others =>
<statements>
end case;
case <expression> is
when <choice> => <statements>
<statements>
when <choice> => <statements>
when others => <statements>
end case;
Різні форми вибіркового прийняття, а також часові та умовні виклики входу:
select
when <guard> =>
<accept statement>
<statements>
or
<accept statement>
<statements>
or
when <guard> =>
delay <interval>;
<statements>
or
when <guard> =>
terminate;
else
<statements>
end select;
select
<entry call>;
<statements>
or
delay <interval>;
<statements>
end select;
select
<entry call>;
<statements>
else
<statements>
end select;
select
<triggering alternative>
then abort
<abortable part>
end select;
Інструкція прийняття:
accept <specification> do
<statements>
end <name>;
separate (<parent unit>)
<proper body>
Відокремлена програмна одиниця:
separate (<parent unit>)
<proper body>
end <name>;
Власні тіла програмних одиниць:
procedure <specification> is
<declarations>
begin
<statements>
exception
when <choice> =>
<statements>
end <name>;
function <specification>
return <type name> is
<declarations>
begin
<statements>
exception
when <choice> =>
<statements>
end <name>;
package body <name> is
<declarations>
begin
<statements>
exception
when <choice>=>
<statements>
end <name>;
task body <name> is
<declarations>
begin
<statements>
exception
when <choice>=>
<statements>
end <name>;
Специфікації контексту до одиниць компіляції розташовують у вигляді таблиці. Формальні параметри не затуляють саму шаблонну одиницю компіляції. Специфікації функцій, пакетів та задач використовують стандартні відступи:
with <name>; use <name>;
with <name>;
with <name>;
<compilation unit>
generic
<formal parameters>
<compilation unit>
function <specification>
return <type>;
package <name> is
<declarations>
private
<declarations>
end <name>;
task type <name> is
<entry declarations>
end <name>;
Розгортання шаблонних одиниць та відступ для записів:
procedure <name> is
new <generic name> <actuals>
function <name> is
new <generic name> <actuals>
package <name> is
new <generic name> <actuals>
type ... is
record
<component list>
case <discriminant name> is
when <choice> =>
<component list>
when <choice> =>
<component list>
end case;
end record;
Відступ для специфікації представлення запису:
for <name> use
record <mod clause>
<component clause>
end record;
Мічені типи та розширення типів:
type ... is tagged
record
<component list>
end record;
type ... is new ... with
record
<component list>
end record;
приклад#
Default_String : constant String :=
"This is the long string returned by" &
" default. It is broken into multiple" &
" Ada source lines for convenience.";
...
if Input_Found then
Count_Characters;
else --not Input_Found
Reset_State;
Character_Total :=
First_Part_Total * First_Part_Scale_Factor +
Second_Part_Total * Second_Part_Scale_Factor +
Default_String'Length + Delimiter_Size;
end if;
end loop;
обгрунтування#
Відступи покращують читабельність коду, оскільки дають вам візуальний індикатор структури програми. Рівні вкладеності чітко ідентифікуються за допомогою відступів, а перше та останнє ключові слова в конструкції можна візуально співставити.
Хоча існує багато дискусій щодо кількості пробілів для відступів, причиною відступів є зрозумілість коду. Той факт, що код має однакові відступи, є більш важливим, ніж кількість пробілів, що використовуються для відступів.
Крім того, у Довідковому посібнику з Ada (1995, §1.1.4) зазначено, що макет, показаний у прикладах і синтаксичних правилах посібника, є рекомендованим макетом коду, який слід використовувати для програм на Ada: "Правила синтаксису, що описують структуровані конструкції, подано у формі, яка відповідає рекомендованій абзацній розмітці.... Для частин синтаксичного правила використовуються різні рядки, якщо відповідні частини конструкції, що описується правилом, повинні знаходитися на різних рядках.... Рекомендується, щоб усі відступи були кратними базовому кроку відступу (кількість пробілів для базового кроку не визначено)."
Важливо робити відступи для рядків продовження інакше, ніж для вкладених структурованих конструкції, щоб візуально їх розрізняти. Це запобігає ускладненню сприйняття структури коду під час його перегляду.
Розміщення специфікації контексту на окремих рядках полегшує супровід; зміна специфікації контексту є менш схильною до помилок.
Відступ за допомогою пробілів забезпечують кращу переносимість, ніж відступ за допомогою табуляції, оскільки символи табуляції по-різному відображаються на різних терміналах і принтерах.
винятки#
Якщо ви використовуєте шрифт змінної ширини, табуляція вирівнюється краще, ніж пробіли. Однак, залежно від налаштувань табуляції, рядки з послідовними відступами можуть мати дуже малу довжину.
примітки щодо автоматизації#
Настанови в цьому розділі легко застосовувати за допомогою автоматичного форматора коду.
Вирівнювання операторів#
настанова#
Вирівняйте оператори по вертикалі, щоб підкреслити структуру коду та його логічний зміст.
приклад#
if Slot_A >= Slot_B then
Temporary := Slot_A;
Slot_A := Slot_B;
Slot_B := Temporary;
end if;
----------------------------------------------------------------
Numerator := B**2 - 4.0 * A * C;
Denominator := 2.0 * A;
Solution_1 := (B + Square_Root(Numerator)) / Denominator;
Solution_2 := (B - Square_Root(Numerator)) / Denominator;
----------------------------------------------------------------
X := A * B +
C * D +
E * F;
Y := (A * B + C) + (2.0 * D - E) - -- basic equation
3.5; -- account for error factor
обгрунтування#
Вирівнювання допомагає краще розгледіти розташування операторів і, таким чином, візуально акцентує увагу на діях коду.
Використання рядків і інтервалів у довгих виразах може підкреслити окремі складові, пріоритет операторів та іншу семантику. Це також може залишити місце для коментарів у виразі.
винятки#
Якщо вертикальне вирівнювання інструкцій призводить до того, що інструкція розбивається на два рядки, особливо якщо розрив відбувається у невідповідному місці, можливо, краще послабити настанову щодо вирівнювання.
примітки щодо автоматизації#
Останній приклад вище демонструє своєрідне "семантичне вирівнювання", яке зазвичай не застосовується і навіть не зберігається автоматичними форматерами коду. Якщо ви розбиваєте вираз на смислові частини і розміщуєте кожну з них в окремому рядку, остерігайтеся подальшого використання форматера коду. Ймовірно, він перенесе весь вираз в один рядок і збере всі коментарі в кінці. Втім, деякі форматори досить розумні, щоб залишати переведення рядка недоторканим, коли рядок містить коментар. Хороший форматер визнає, що останній приклад вище не порушує настанови, і тому збереже його в тому вигляді, в якому він був написаний.
Узгодження оголошень#
настанова#
Використовуйте вертикальне вирівнювання для покращення читабельності оголошень.
Вказуйте максимум одне оголошення в рядку.
Відступайте всі оголошення в одній декларативній частині на одному рівні.
конкретизація#
Для оголошень, не розділених порожніми рядками, дотримуйтесь цих правил вирівнювання:
Вирівняйте роздільники двокрапки.
Вирівняйте роздільник ініціалізації :=.
Якщо використовуються кінцеві коментарі, вирівняйте роздільник коментарів.
Коли оголошення переповнює рядок, розірвіть рядок і додайте рівень відступу для тих рядків, які обгортаються. Найкраще розривати рядки у таких місцях (1) роздільник коментарів; (2) роздільник ініціалізації; (3) роздільник двокрапки.
Для оголошень типу перерахування, які не вміщуються в один рядок, розміщуйте кожен літерал в окремому рядку, використовуючи наступний рівень відступу. За необхідності, семантично пов'язані літерали можна розташувати по рядках або стовпчиках, щоб сформувати таблицю.
приклад#
Змінні та константи можна оформити у вигляді таблиці з колонками, розділеними символами :, :=, та --.
Prompt_Column : constant := 40;
Question_Mark : constant String := " ? "; -- prompt on error input
Prompt_String : constant String := " ==> ";
Якщо в результаті рядки виходять надто довгими, їх можна розташувати на окремих рядках з відповідним рівнем відступу для кожної частини:
subtype User_Response_Text_Frame is String (1 .. 72);
-- If the declaration needed a comment, it would fit here.
Input_Line_Buffer : User_Response_Text_Frame
:= Prompt_String &
String'(1 .. User_Response_Text_Frame'Length -
Prompt_String'Length => ' ');
Оголошення літералів перечислення можуть бути перераховані в одному або декількох стовпчиках як:
type Op_Codes_In_Column is
(Push,
Pop,
Add,
Subtract,
Multiply,
Divide,
Subroutine_Call,
Subroutine_Return,
Branch,
Branch_On_Zero,
Branch_On_Negative);
або для економії місця:
type Op_Codes_Multiple_Columns is
(Push, Pop, Add,
Subtract, Multiply, Divide,
Subroutine_Call, Subroutine_Return, Branch,
Branch_On_Zero, Branch_On_Negative);
або, щоб підкреслити споріднені групи цінностей:
type Op_Codes_In_Table is
(Push, Pop,
Add, Subtract, Multiply, Divide,
Subroutine_Call, Subroutine_Return,
Branch, Branch_On_Zero, Branch_On_Negative);
обгрунтування#
У багатьох стандартах програмування є вимога оформлювати імена, типи, початкові значення та значення у вигляді таблиць в коментарях до заголовків модулів. Ці коментарі є надлишковими і можуть стати неузгоджені з кодом. Вирівнювання самих оголошень у табличному вигляді (див. приклади вище) забезпечує ідентичну інформацію як для компілятора, так і для читача; змушує використовувати максимум одне оголошення у рядку; і полегшує супровід, надаючи місце для ініціалізації та необхідних коментарів. Оформлення оголошень у вигляді таблиці сприяє кращій читабельності, не дозволяючи іменам загубитися серед інших елементів. Це стосується всіх оголошень: типів, підтипів, об'єктів, виключень, іменованих чисел тощо.
примітки щодо автоматизації#
Більшість рекомендацій у цьому розділі легко виконати за допомогою автоматичного форматувальника коду. Єдиний виняток - останній приклад перечислюваного типу, який розміщено у рядках відповідно до семантики літералів перечислення. Автоматичний форматер коду не зможе цього зробити і, ймовірно, перемістить літерали перечислення у різні рядки. Однак інструменти, які перевіряють тільки на порушення рекомендацій, повинні приймати табличну форму оголошення типу перечислення.
Більше про вирівнювання#
настанова#
Вирівняйте режими параметрів та дужки по вертикалі.
конкретизація#
Зокрема, рекомендується, щоб ви:
У кожному рядку розміщуйте по одній формальній специфікації параметрів.
Вирівняйте по вертикалі назви параметрів, двокрапки, зарезервоване слово in, зарезервоване слово out та підтипи параметрів.
Першу специфікацію параметра слід розміщувати у тому ж рядку, що й назву підпрограми або запису. Якщо будь-які підтипи параметрів виходять за межі довжини рядка, розмістіть першу специфікацію параметра з нового рядка з таким самим відступом, як і для рядка продовження.
приклад#
procedure Display_Menu (Title : in String;
Options : in Menus;
Choice : out Alpha_Numerics);
Наступні два приклади демонструють альтернативні варіанти застосування цієї настанови:
procedure Display_Menu_On_Primary_Window
(Title : in String;
Options : in Menus;
Choice : out Alpha_Numerics);
або:
procedure Display_Menu_On_Screen (
Title : in String;
Options : in Menus;
Choice : out Alpha_Numerics
);
Вирівнювання виразів у дужоках робить складні реляційні вирази більш зрозумілими:
if not (First_Character in Alpha_Numerics and then
Valid_Option(First_Character)) then
обгрунтування#
Таке вирівнювання полегшує читабельність і зрозумілість, і його легко досягти за умови автоматизованої підтримки. Вирівнювання режимів параметрів надає ефект таблиці зі стовпчиками для назви параметра, режиму, підтипу і, за необхідності, коментарів до параметра. Вертикальне вирівнювання параметрів у підпрограмах у межах одного блоку компіляції ще більше покращує читабельність.
нотатки#
Для розташування підпрограм доступні різні варіанти. У другому прикладі вище вирівняно всі назви підпрограм і параметри у програмі. Недоліком цього способу є зайвий рядок, якщо назви підпрограм короткі і виглядають незграбно, якщо є лише один параметр.
Третій приклад - це формат, який зазвичай використовується для зменшення обсягу редагування, необхідного при додаванні, видаленні або переупорядкуванні рядків параметрів. Дужки не потрібно переносити з рядка в рядок. Однак останній рядок параметрів є єдиним без крапки з комою.
винятки#
Коли операторна функція має два або більше формальних параметрів одного типу, зручніше оголошувати параметри в одному однорядковому списку, ніж розділяти список формальних параметрів на декілька специфікацій формальних параметрів.
type Color_Scheme is (Red, Purple, Blue, Green, Yellow, White, Black, Brown, Gray, Pink);
function "&" (Left, Right : Color_Scheme) return Color_Scheme;
примітки щодо автоматизації#
Більшість рекомендацій у цьому розділі легко виконати за допомогою автоматичного форматувальника коду. Єдиний виняток - останній приклад, який показує вертикальне вирівнювання круглих дужок для виділення членів виразу. Цього важко досягти за допомогою автоматичного форматувальника коду, якщо тільки відповідні члени виразу не можуть бути визначені строго через операторний пріоритет.
Порожні рядки#
настанова#
Використовуйте порожні рядки для розділення логічних блоків коду, що робить його більш зрозумілим (NASA 1987).
приклад#
if ... then
for ... loop
...
end loop;
end if;
У цьому прикладі різні типи оголошень відокремлено порожніми рядками:
type Employee_Record is
record
Legal_Name : Name;
Date_Of_Birth : Date;
Date_Of_Hire : Date;
Salary : Money;
end record;
type Day is
(Monday, Tuesday, Wednesday, Thursday, Friday,
Saturday, Sunday);
subtype Weekday is Day range Monday .. Friday;
subtype Weekend is Day range Saturday .. Sunday;
обгрунтування#
Коли порожні рядки використовуються продумано і послідовно, ділянки пов'язаного коду стають більш помітними для читачів.
примітки щодо автоматизації#
Автоматичні форматувальники не дуже добре дотримуються цього принципу, оскільки рішення про те, куди вставляти порожні рядки, є семантичним. Втім, багато форматерів мають можливість залишати наявні порожні рядки недоторканими. Таким чином, ви можете вручну вставити рядки і не втратити ефект при запуску такого форматера.
Поділ коду на частини#
настанова#
Виділіть верхню частину кожного пакета або специфікації задачи, верхню частину тіла кожного програмного блоку та рядок, який закриває кожен програмний блок.
конкретизація#
Зокрема, рекомендується наступне:
Використовуйте преамбули файлів, заголовки специфікацій та заголовки тіла, щоб виділити ці структури, як рекомендовано у Настанові 3.3.
Використовуйте лінію з тире, починаючи з того ж стовпчика, що й поточний відступ, щоб виділити визначення вкладених одиниць, вбудованих у декларативну частину. Вставляйте лінію тире безпосередньо перед визначенням і відразу після нього.
Якщо дві пунктирні лінії є суміжними, опустити довшу з них.
приклад#
with Basic_Types;
package body SPC_Numeric_Types is
---------------------------------------------------------------------
function Max
(Left : in Basic_Types.Tiny_Integer;
Right : in Basic_Types.Tiny_Integer)
return Basic_Types.Tiny_Integer is
begin
if Right < Left then
return Left;
else
return Right;
end if;
end Max;
---------------------------------------------------------------------
function Min
(Left : in Basic_Types.Tiny_Integer;
Right : in Basic_Types.Tiny_Integer)
return Basic_Types.Tiny_Integer is
begin
if Left < Right then
return Left;
else
return Right;
end if;
end Min;
---------------------------------------------------------------------
use Basic_Types;
begin -- SPC_Numeric_Types
Max_Tiny_Integer := Min(System_Max, Local_Max);
Min_Tiny_Integer := Max(System_Min, Local_Min);
-- ...
end SPC_Numeric_Types;
обгрунтування#
Легко не помітити частини програмних блоків, які не видно на поточній сторінці або екрані. Довжина сторінок у презентаційному обладнанні та програмному забезпеченні може бути різною. Чітко позначивши логічні межі програмної одиниці (наприклад, пунктирною лінією), ви даєте змогу читачеві швидко перевірити, чи видно весь програмний блок. Таке розбиття на сторінки також полегшує швидке сканування великого файлу в пошуках певної програмної одиниці.
винятки#
Ця настанова не розглядає розміщення коду на фізичній "сторінці", оскільки розміри таких сторінок дуже різняться, і немає єдиної настанови, яка б підходила для цього.
примітки щодо автоматизації#
Настанови в цьому розділі легко застосовувати за допомогою автоматичного форматора коду.
Кількість інструкції у рядку#
настанова#
Починайте кожну інструкцію з нового рядка.
Пишіть не більше однієї простої інструкції в рядку.
Розділяйте складені інструкції на кілька рядків.
приклад#
Використовуйте:
if End_Of_File then
Close_File;
else
Get_Next_Record;
end if;
замість:
if End_Of_File then Close_File; else Get_Next_Record; end if;
винятковий випадок:
Put("A="); Natural_IO.Put(A); New_Line;
Put("B="); Natural_IO.Put(B); New_Line;
Put("C="); Natural_IO.Put(C); New_Line;
обгрунтування#
Окрема інструкція в кожному рядку покращує здатність читача знаходити інструкції і допомагає запобігти пропуску інструкцій. Аналогічно, структура складногї інструкції стає зрозумілішою, коли його частини розташовані на окремих рядках.
винятки#
Якщо інструкція довша за місце, що залишилося у рядку, продовжуйте її на наступному рядку. Ця настанова стосується оголошень, спеціфікації контексту та параметрів підпрограм.
Згідно з довідником Ada (1995, §1.1.4), "Інші розриви рядка краще після крапки з комою".
примітки щодо автоматизації#
Вказівки цього розділу легко виконати за допомогою автоматичного форматора коду, за винятком останнього прикладу, в якому показано семантичне групування кількох інструкції в одному рядку.
винятки#
Приклад інструкцій Put та New_Line показує виправданий виняток. Таке групування тісно пов'язаних інструкцій в одному рядку робить зрозумілим структурний зв'язок між групами.
Довжина рядка вихідного коду#
настанова#
Дотримуйтесь обмеження на максимальну довжину рядка вихідного коду (Nissen and Wallis 1984, §2.3).
конкретизація#
Зокрема, рекомендується наступне:
Обмежте довжину рядка вихідного коду до 72 символів.
обгрунтування#
Під час перенесення коду на мові Ada з однієї системи на іншу можуть виникати обмеження на розмір рядків вихідного коду, можливо, з однієї з таких причин: деякі операційні системи можуть не підтримувати записи змінної довжини для стрічкового вводу/виводу, або деякі принтери та термінали підтримують 80-символьну ширину рядка без переведення рядка на новий рядок. Див. додаткове обґрунтування у примітці до Настанови 7.1.2.
Вихідний код іноді потрібно публікувати з різних причин, а папір Letter не такий пробачливий, як комп'ютерний лістинг з точки зору кількості корисних стовпців.
Крім того, існують людські обмеження щодо ширини поля зору для розуміння на рівні, необхідному для читання вихідного коду. Ці обмеження приблизно відповідають діапазону від 70 до 80 стовпчиків.
винятки#
Альтернативним варіантом є обмеження довжини вихідного коду до 79 символів. Обмеження у 79 символів відрізняє код від 72-символьного обмеження мови FORTRAN. Це також дозволяє уникнути проблем з терміналами, де символ в останньому стовпчику може бути надрукований неправильно.
примітки щодо автоматизації#
Настанови в цьому розділі легко застосовувати за допомогою автоматичного форматора коду.
Підсумок#
форматування коду#
Використовуйте однаковий інтервал навколо роздільників.
Використовуйте той самий інтервал, що й у звичайній прозі.
Відступи та вирівнювання вкладених структур керування, рядків продовження та вбудованих блоків послідовно.
Розрізняють відступи для вкладених керуючих структур і для рядків продовження.
Для відступів використовуйте пробіли, а не символ табуляції (Nissen and Wallis 1984, §2.2).
Вирівняйте інструкції по вертикалі, щоб підкреслити локальну структуру та семантику програми.
Використовуйте вертикальне вирівнювання для покращення читабельності оголошень.
Вказуйте максимум одне оголошення в рядку.
Відступайте всі оголошення в одній декларативній частині на одному рівні.
Вирівняйте режими параметрів та дужки по вертикалі.
Використовуйте порожні рядки для групування логічно пов'язаних рядків тексту (NASA 1987).
Виділіть верхню частину кожного пакета або специфікації задачи, верхню частину тіла кожного програмного блоку та рядок завершення кожного програмного блоку.
Починайте кожну інструкцію з нового рядка.
Пишіть не більше одного простої інструкції в рядку.
Розбиття складених інструкцій на декілька рядків.
Дотримуйтесь обмеження на максимальну довжину рядка вихідного коду (Nissen and Wallis 1984, §2.3).