Код конвенция

от Уикипедия, свободната енциклопедия

Конвенция за кода или код конвенция се нарича набор от насоки за конкретен език за програмиране, които препоръчват стил на писане на програмен код, добри практики и методи за всички аспекти от писането на конкретния програмен език. Тези конвенции обикновено обхващат организация на файловата структура, индентация, писане на коментари, деклариране на променливи и изрази, конвенции при именуването, принципи на програмирането и други. Това са насоки за качествен програмен код. Препоръчително за програмистите е да се придържат към тези конвенции и насоки с цел подобряване четимостта на написания от тях програмен код и за да улеснят неговата поддръжка. Конвенциите могат да бъдат официално оформени в документация под вид на правила, които следва да бъдат спазвани от цял екип или компания или могат да бъдат неформални, като например описващи обичайните практики на писане на код на отделен член на екипа.

Софтуерна поддръжка[редактиране | редактиране на кода]

Най-често посочваната причина за спазването на код конвенциите е намаляването на разходите за софтуерна поддръжка. Sun Microsystems посочват следната обосновка при представянето на своите код конвенции за езика Java[1]:

  • 40% до 80% от разходите за даден софтуерен продукт отиват за поддръжка.
  • Рядко софтуерен продукт се поддържа от първоначалния си създател през целия си жизнен цикъл.
  • Код конвенциите подобряват четимостта и позволяват на инженерите да разберат кода по-бързо и по-добре.
  • Ако предлагате на пазара свой код, трябва да се уверите, че той е добре оформен и чист.

Софтуерно инженерство[редактиране | редактиране на кода]

Софтуерното инженерство е процесът, при който се специфицира и изгражда един софтуерен проект. Той е от съществено значение за успеха на проекта и изиграва ключова роля в изграждането на по-мащабни проекти. Този процес е в основата на всички практики за писане на програмен код и допринася за успешното му завършване. Качественото софтуерно инженерство минимизира разходите по веригата и максимизира шансовете за успех на проекта.

Спецификация на проекта[редактиране | редактиране на кода]

За нуждите на спецификацията на проекта трябва да бъдат изготвена следната документация:

  1. Основна задача (на английски: project brief). Главните точки от проекта се описват накратко (това не е част от официалния документопоток).
  2. Спецификация на изискванията. Детайлно се определя какви са целта и основните функции на проекта в серия от документи. Всички следващи документи се оформят на базата на тези.
  3. Дизайн на проекта. Това е официалният документ, описващ структурата на проекта. В него се определят модулите и компонентите на проекта, както и техните интерфейси и взаимна обвързаност. При създаването на този документ софтуерният инженер трябва да се съобрази с всички аспекти на проекта – технически, качествени, управленски, логистични и търговски. Това включва необходимото време и разходи за разработката, поддръжката, използването на софтуера, обмена на информация. Тук е включена и архитектурата, но и доста по-широк кръг от въпроси.
  4. Тестова спецификация. В този документ се определят всички тестове, които следва да бъдат извършени и какви резултати се очакват. Често тези тестове са автоматизирани.
  5. Резултати от тестовете.

Този набор от документи се нарича документопоток. Всеки следващ документ е тясно обвързан с предходния и в крайна сметка тестовата спецификация трябва да отразява 1:1 спецификацията на изискванията. Документопотокът е двупосочен – спецификациите вървят надолу, а резултатите нагоре.

Качество[редактиране | редактиране на кода]

Проверката на софтуера често изисква четене на изходен код. Тази дейност е преди всичко свързана с откриването на бъгове. По принцип, преди подлагането на даден код на проверка, той се чете само от автора му. Когато кодът е писан при спазване на правилата, проверяващият е улеснен да го разбере и асимилира и да подобри ефикасността на откриването на недостатъци.

Спазването на правилата улеснява поддръжката дори и за оригиналния автор. Няма никаква гаранция, че дълго време след написването му програмистът ще си спомня защо дадено парче код е написано по определен начин. Последователното ползване на шпации (на английски: whitespace) подобрява четливостта и намалява необходимото време за разбиране на програмата.

Стандарти при писане на код[редактиране | редактиране на кода]

Тъй като код конвенциите са дефинирани с цел създаването на качествен код, след като бъдат официално приети от екипа, те се превръщат в кодови стандарти. Специфичният стил, независимо от това дали е възприет добре или не, не води задължително до създаването на добър код, а става стандарт само тогава, когато цели именно писането на висококачествен код. Затова като стандарти се налагат стилове, отличаващи се с голяма логика във всички аспекти на дизайна.

Намаляване на сложността[редактиране | редактиране на кода]

Управлението на сложността е сложен процес. Основен принцип по време на развитието на проекта е да се задава един важен въпрос „Използва ли проектът възможно най-малко код за изпълнението си?“ Ако отговорът е отрицателен, това означава, че са били положени ненужно много усилия, както и ненужни разходи. В основата на всеки проект стои правилото „Keep it Simple“ – прост, но ефективен код. Сложността в един проект може да се наблюдава на ниво „дизайн“ – как точно е проектиран – и на ниво „развитие“ – какъв код е използван. Ако кодът е опростен, тогава и сложността ще бъде малка. Много често тази практика е изразена в запазването на „човешкия“ код – директен, но и разбираем. Така се ражда оптимален, лесен за четене и следване код. Колкото по-сложен е кодът, толкова по-големи са шансовете да присъстват бъгове и толкова по-малки са шансовете за откриването им.

Рефакториране[редактиране | редактиране на кода]

Рефакторирането е дейност по поддръжката на софтуера, при която изходният код се променя с цел подобряване четимостта или подобряване на структурата му. Софтуерът често се рефакторира с цел да се сведе в съответствие със стандартите, одобрени от екипа след първоначалното му пускане. Чести рефакторни практики са промяна на имена на променливите, преименуване на методи, преместване на методи и цели класове, разбиване на големи методи или функции на малки.

Популярни конвенции[редактиране | редактиране на кода]

Уикикниги
Уикикниги
В Уикикниги има на разположение:

Съществуват многобройни код конвенции; виж Coding Style за обсъждане и примери. Предмет на код конвенции са най-често следните области:

Източници[редактиране | редактиране на кода]

  Тази страница частично или изцяло представлява превод на страницата Coding conventions в Уикипедия на английски. Оригиналният текст, както и този превод, са защитени от Лиценза „Криейтив Комънс – Признание – Споделяне на споделеното“, а за съдържание, създадено преди юни 2009 година – от Лиценза за свободна документация на ГНУ. Прегледайте историята на редакциите на оригиналната страница, както и на преводната страница, за да видите списъка на съавторите. ​

ВАЖНО: Този шаблон се отнася единствено до авторските права върху съдържанието на статията. Добавянето му не отменя изискването да се посочват конкретни източници на твърденията, които да бъдат благонадеждни.​