Презентація вихідного коду#
Фізичне розташування вихідного тексту на сторінці або екрані має значний вплив на його читабельність. Цей розділ містить настанови щодо представлення вихідного коду, призначені для того, щоб зробити його більш читабельним.
На додаток до загальних рекомендацій, у розділах, присвячених конкретним випадкам, подано конкретні рекомендації. Якщо ви не згодні з конкретними рекомендаціями, ви можете прийняти свій власний набір правил, які все ще відповідають загальним рекомендаціям. Перш за все, будьте послідовними у всьому вашому проекті.
Повністю узгодженої верстки важко досягти або перевірити вручну. Тому ви можете автоматизувати верстку за допомогою інструменту для параметризованого форматування коду або включити настанови в шаблон автоматичного кодування. Деякі з настанов і конкретних рекомендацій, представлених у цій главі, не можуть бути застосовані за допомогою інструменту форматування, оскільки вони базуються на семантиці а не синтаксисі коду 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).