Стил програмирања

Стил програмирања је скуп правила или смерница који се користе приликом писања изворног кода за рачунарски програм. Често се тврди да  одређен програмски стил може помоћи програмерима да читају и разумеју изворни код у складу са стилом, и тако да се избегне увођење грешака.

Класичан рад на предмету је Елементи Програмског Стила, написан у 1970., и илустрован са примерима из Фортран и PL/I језика преовладава у то време.

Стил програмирања користи се у одређеном програму и може се извести из кодирајућих конвенција предузећа или других рачунарских организација, као и склоности аутора кода. Стилови програмирања су често дизајнирани за одређени програмски језик (или језичке): стил сматра да оно што је добро у C изворном коду не може бити прикладно за Бејсик изворни код, и тако даље. Међутим, нека правила најчешће се примењују на многе језике.

Елементи доброг стила

Добар стил је субјективна ствар, и тешко је дефинисана. Међутим, постоје неколико елемената заједнички за велики број програмских стилова. Питања се најчешће сматрају као део програмског стила укључујћи распоред изворног кода, укључујући и увлачење; употреба белог простора око оператера и кључне речи; капитализација или на други начин кључних речи и имена варијабли; стил и правопис корисничких дефинисаних идентификатора, као што су функције, процедуре и имена променљивих; и употреба и стил коментара.

Изглед кода 

Стилови програмирања обично се баве визуелним изгледом изворног кода, са циљем лакшег читања. Софтвер је дуго био доступан да аутоматски форматира изворни код, остављајући кодере да се концентришу на именовања, логику и више технике. Као практичну тачку, користите рачунар за форматирање изворног кода што штеди време, а могуће је да их спроведу компаније широм стандарда без расправе.

Увлачење

Стилови увлачења помажу у идентификовању контроле протока и блокова кода. У неким програмским језицима удубљење служи да се ограничавају логички блокови кода; исправно удубљење у овим случајевима је више од ствари стила. У другим језицима увлачења и белог простора не утиче на функцију, иако логично и конзистентно удубљење чини код више читљивим. Упореди:

if (сати < 24 && минути< 60 && секунде < 60) {
    return тачно;
} else {
    return нетачно;
}

или

if (сати < 24 && минути < 60 && секунде < 60)
{
    return тачно;
}
else
{
    return нетачно;
}

са нечим као што је

if ( сати < 24
   && минути < 60
   && секунде < 60
)
{return тачно
;} else
{return нетачно
;}

Прва два примера су вероватно много лакша за читање јер су увучени у постојећем путу (а "виси став" стил). Овај удубљени стил је посебно користан када се ради о вишеструким конструкцијама. Имајте на уму, међутим, да овај пример је исто једноставан:

return (сати < 24 && минути < 60 && секунде < 60);

ModuLiq

 Упоредите све горе наведено са:

if (сати < 24 && минути < 60 && секунде < 60)
return тачно;

else
return нетачно;

Луа

Луа не користи традиционалне витичасте или обичне  заграде. ако/иначе изјаве само захтевају ваш израз да буду праћене од  тада, и затварају своју ако / иначе изјаву са крај.

if сати < 24 и минути < 60 исекунде < 60 then
    return тачно
else
    return нетачно
end

Увлачење није обавезно. и,или,не се користе између тачно/нетачно изјава. Они су тачно/нетачно изјаве, као

print(није тачно)

што би значило лажна.

Пајтон

Пајтон користи увлачење да укаже контролне структуре, тако да су потребна исправна удубљење. На овај начин, потреба за заграде са заградама (т.ј. { и }) се елиминише. На другу руку копирање и лепљење пајтон кода може довести до проблема, јер ниво увлачења његовог дупликат кода не може бити исти као ниво утискивања, тренутне линије. Таква обликовање може да буде заморно да урадите ручно, али неки текст едитори и IDEs имају функције да то ураде аутоматски. Постоје проблеми када Пајтон код постаје неупотребљив када је постављен на форуму или веб страницу која уклања бели простор, мада се овај проблем може избећи, где је могуће да се приложи код у белом простору-конзервирање ознаке као што су "<pre> ... </pre>" (за HTML), "[код]" ... "[/код]" (за bbcode), итд.

if сати < 24 и минути < 60 и секунде < 60:
    return тачно
else:
    return нетачно

Приметите да Пајтон не користи витичасте, али редовно двотачке (нпр. иначе:).

Многи Пајтон програмери имају тенденцију да прате заједнички договорен стил познат као ПЕП8.Постоје алати дизајнирани за аутоматизацију ПЕП8 поштовања.

Хаскел

Хаскел слично има правило које омогућава удубљење дефинисаних блокова. Међутим, за разлику од Пајтона, Хаскел једноставно користи белине на овај начин као облик синтаксних шећера-експлицитне заграде и зарез  се могу (и повремене су) користи уместо тога.

Вертикално поравнање

Често је корисно да се ускладе слични елементи вертикално, да типо-генерисани  багови буду више очигледни. Упореди:

$претраживање = низ('a', 'b', 'c', 'd', 'e');
$замена = низ('foo', 'bar', 'baz', 'quux');

// Други пример:

$вредност = 0;
$другавредност = 1;
$јошједанавредност = 2;

са:

$претраживање = низ('a', 'b', 'c', 'd', 'e');
$замена = низ('foo', 'bar', 'baz', 'quux');

// Други пример:

$вредност = 0;
$другавредност = 1;
$јошједанавредност = 2;

Овај други пример чини две ствари интуитивно јасно а нису били јасни у бившој:

• потрага и замена термина су повезане и поклапају се: оне нису дискретне променљиве;
• постоји још један термин за претрагу него постоје услови за замену. Ако је ово грешка, сада је већа вероватноћа да ће се приметити.

Међутим, имајте на уму да постоје аргументи против вертикалног поравнања:

• Интер линија лажних зависности; табеларно форматирање ствара зависност преко линија. На пример, ако идентификатор са дугогодишњим именом се дода табеларном распореду, ширина колона ће можда морати да се повећа да га прими. Ово приморава већу промену у изворном коду него што је потребно, а суштинска промена може бити изгубљена у буци. Ово је штетно за контролну ревизију где инспекција разлике између верзија је од суштинског значаја.
• Кртости; ако програмер неуредно форматира табелу приликом промене, можда легитимно са претходне тачке у виду, резултат постаје хаос који се погоршава са даљим таквим променама.Једноставно рефакторисање операција, као што су претрага и замена, могу да сломе форматирање.
• Отпорност на модификацији; табеларно форматирање захтева више напора да се одржи. Ово може одложити програмера да направи повољне промене, као што је додавање, исправљање и побољшање име идентификатора, јер ће упропастити форматирање.
• Ослањање на једнпросторни фонт; табеларно форматирање претпоставља да је уредник користио фиксне ширине. Многи савремени уредници кодова подржавају пропорционалне фонтове, а програмер можда више воли да користи пропорционални фонт за читљивост.
• Алат зависност; неки од напора одржавања равнотеже могу се ублажити алатима (нпр едитор изворног кода који подржава еластичне табстопове), иако то ствара зависност од таквих алата.

На пример, ако се операција једноставног рефакторисања  врши на коду изнад, преименовање варијабли "$ замена" у "$ р" и "$ другавредност" у "$ а", добијени код ће изгледати овако:

$претраживање = низ('a', 'b', 'c', 'd', 'e');
$r = низ('foo', 'bar', 'baz', 'quux');

// Други пример:

$вредност = 0;
$a = 1;
$јошједанавредност = 2;

Секвенцијално форматирање оригинала ће и даље изгледати добро после такве промене:

$претраживање = низ('a', 'b', 'c', 'd', 'e');
$r = низ('foo', 'bar', 'baz', 'quux');

// Други пример:
 
$вредност = 0;
$a = 1;
$јошједанавредност = 2;

Простори

У оним ситуацијама када је потребно мало белог простора  граматика већине језика слободног формата је неупућена у износу који се појављује. Стил се односи на бели простор и најчешће користи за побољшање читљивости. Тренутно не постоје познате чврсте чињенице (Закључци из студије) да стилови белог простора имају најбољу читљивост.

На пример, упоредите следеће синтаксичке еквивалент примере C кода:

int i;
for(i=0;i<10;++i){
    printf("%d",i*i+i);
}

наспрам

int i;
for (i=0; i<10; ++i) {
    printf("%d", i*i+i);
}

наспрам

int i;
for (i = 0; i < 10; ++i) {
    printf("%d", i * i + i);
}

Таб

Коришћење таб картице да створи празан простор представља конкретна питања, када се узме није довољно брига јер  локација табеларног приказивања тачке може бити различита у зависности од алата који се користи, па чак и преференције корисника.

Као пример, један програмер преферира таб размак  четири пута и  његов сет алата је подесио на овај начин, и користи то да обликујете своју шифру.

int ix; // Индекс за скенирање низа
long sum; // Акумулатор за суму

Други програмер преферира таб  осам пута, а његов сет алата је подешен на овај начин. Када испитује своју шифру, може бити тешко за читање.

int ix; // Индекс за скенирање низа
long sum; // Акумулатор за суму

Једно широко коришћено решење за овај проблем може да укључи забрану коришћења картица за усклађивање или правила о томе како мора бити постављен таб. Имајте на уму да таб ради у реду, под условом да се доследно користи, ограничено на логичана увлачења, а не користи за поравнање: 

class MyClass {
	int foobar(int qux, // први параметар
	 int quux); // други параметар
	int foobar2(int qux, // први параметар
	 int quux, // други параметар
	 int quuux); // трећи параметар
};

Види још

• Шифриране конвенције
• Увлачење стил
• MISRA C
• Именовање конвенције (програмирање)

Спољашње везе

• Source Code Formatters at DMOZ