синтактична захар
Книга: Да се създаде компилатор!
синтактична захар
ДИСКУСИЯ Всичко това поставя въпроса за "синтактична захар". структури, които са били добавени към езика, а не защото те са необходими, но тъй като те правят програмата изглеждат точно за програмист. В крайна сметка, е добре да има една малка, проста компилатор, но от него, че ще бъде от голяма полза, ако в резултат на езика е било кодирано или сложно програмиране. Идва на ум е език нататък. Ако добавим и възможността за език, който направи програмата по-лесно за четене и разбиране, а ако тези функции предотвратяване на програмиста от грешките, тогава ние ще го направим. Особено, ако тези структури не добавят твърде много сложност на езика или на компилатора.
Като пример може да се разглежда и запетая, но има и много други, като например «ТОГАВА» в IF, «DO» изявление в изявление на време или твърдение на «ПРОГРАМА» който отстранява от малки. Нито един от тези символи не добавя много за синтаксиса на езика. компилаторът мога да разбера какво се случва без тях. Но някои хора смятат, че по разбираемо на програмата и тя може да бъде много важно.
Има две школи по тази тема, която е добре представена с две от най-популярните езици C и Паскал.
Според минималистичен цялата тази захар трябва да се изхвърли. Те твърдят, че това ще претовари езика и увеличава броя на натиснатите клавиши, което трябва да направи програмист. Може би по-важното е, че всеки допълнителен знак или ключова дума е в капана, който се намира в очакване на невнимателен програмист. Ако не се вземат предвид означението си го пропуснете или да го направи правописна грешка, компилаторът ще получаваш. Затова тези хора твърдят, че най-добрият подход - да се избегнат такива неща. Тези хора предпочитат езика на тип С, която има най-малко излишни думи и препинателни знаци.
Разликите са добре представени от тези два езика. Най-често се чува жалбата за C - той е твърде прощава. Когато направите грешка в C, бъги код често е друг валиден дизайн C. Така че компилаторът просто щастливо продължава да събира и ви оставя да се намери грешки по време на отстраняване на грешки. Предполагам, че затова дебъгерите са толкова популярни сред програмистите.
От друга страна, ако съставя програма в Pascal, можете да сте напълно сигурни, че програмата ще направи това, което й каже. Ако има грешка по време на работа, то е възможно да се изработи грешка.
Най-добрият пример за полезна захар е директно с точка и запетая. Помислете кодовия фрагмент:
Тъй като няма оператор, свързващ означение "Б" с останалата част от израз, компилаторът ще се заключи, че изразът завършва с ') "и" б "- това е началото на нова одобрение. Но да предположим, че аз просто пропусна предназначение оператора, а в действителност искаше да каже:
В този случай, компилаторът ще генерира грешка, добре, но това няма да е много смислено, тъй като тя ще се очаква да подпише "=", след като "Б", които в действителност не би трябвало да има.
Ако, обратно, аз ще поставя точка и запетая след "Б", а след това не може да остане съмнения, които, предполагам, завършва изявлението. Синтактичен захар, като по този начин Тя може да служи много полезна цел чрез предоставяне на допълнителна предпазна мрежа, която ние оставаме на прав път.
Аз съм някъде по средата между тези два подхода. Прекланям се от предимствата на Паскал перспектива. Ще бъда много щастлив да открие своите грешки по време на компилация, а не по време на изпълнение. Но аз също мразя да просто да хвърлят думи без видима причина в COBOL. Досега съм постоянно изхвърлен повечето от захар целувка на Паскал / малки. Но аз със сигурност не се чувствам силно чувство за всеки метод, и аз също да видите значението на разпространението на малко количество захар е само за допълнителна предпазна мрежа, която той дава. Ако ви харесва този последен подход, тези неща са лесни за да добавите. Само не забравяйте, че като точка и запетая, всяка лъжица захар - това е нещо, което би могло да доведе до грешка при компилирането, ако нейното бездействие.