Վրիպածին շարահյուսություն՝ շարահյուսություն, որը ստեղծում է վրիպելու հավանականություն։

Վրիպակներ ասելով նկատի ունեմ ծրագրավորման bug-երը։ Ծրագրավորման լեզուներում կան շարահյուսորեն թույլատրված կառուցվածքներ, որոնք սակայն վրիպածին են։ Մի երկու օրինակ ցույց տամ, որոնց վրա մտածելիս հանգեցի այս մտքին։

Օրինակ առաջին՝ SQL

Այս օրինակում երկու խնդիր կա, առաջին խնդիրը այն է, որ “other field”-ը երկու բառից է կազմված հետևաբար պիտի ներառվի ապաթարցի նշանների մեջ։ Երկրորդ խնդիրը այն է, որ order բառը sql-ում ռեզերվ արված բառ է, հետևաբար այն նույնպես պիտի ներառվի ապաթարցների մեջ։

Մի փոքր ձևափոխելով կարող ենք ստանալ շարահյուսորեն ճիշտ, սակայն դեռևս վրիպածին կոդ

Ինչու՞ եմ ասում, որ սա դեռ վրիպածին է, այն պատճառով, որ սովորողները պիտի մի քանի կանոն հիշեն միայն մի կանոնի փոխարեն։ Լեզվի հետ առաջին ծանոթույթյան ժամանակ անհրաժեշտ է բացատրել ու ասել ամենաընդհանուր կանոնը, որը կփոքրացնի վրիպակների առաջացման հավանականությունը։

Միակ կանոնը, որը պետք է ասել, դա այն է․ որ դաշտերի և աղյուսակների աննունները “ՄԻՇՏ” պիտի դրվեն ապաթարցի նշանների մեջ, սա իհարկե ՍՈՒՏ է, սակայն կարծում եմ մանկավարժորեն անհրաժեշտ սուտ է ։)

Ֆորմատավորումն էլ կարևոր է, ավելի հեշտ է կարդալ ու հասկանալ ամեն տողում մեկ դաշտ գրելաձևը, քան մեկ տողում իրար հետևից գրած բոլոր դաշտերը։ Վերջին օրինակում էլի մի բան էլ կա, որը նույնպես փոքրացնում է վրիպակների հավանականությունը, դա դաշտերի սկզբում՝ այլ ոչ վերջում դրված ստորակետներն են, տողը ջնջելիս, կամ մեկնաբանություն դարձնելիս չի խախտվում արտահայտության շարահյուսությունը։

python լեզվի առավելություններից մեկն էլ այն է, որ ֆորմատավորումը շարահյուսության մի մասն է ։)

Օրինակ երկրորդ՝ javascript

Ջավասքրիփթում նույնպես կան վրիպածին կառուցվածքներ և “շարահյուսություններ”։ Նայենք հետևյալ օրինակը։

Այս երկու կառուցվածքները շարահյուսորեն ճիշտ են կազմված։ Սակայն կարծում եմ, որ սրանք նույնպես վրիպածին են։ Սրանք կարող են ընկալվել որպես հրամանների շարք, այնինչ իրականում սրանք կառուցվածքների մասնավոր դեպքեր են, կառուցվածքի ներսում մեկ հրաման ունենալու պարագաներում։ Կառուցվածքների ձևավոր փակագծերը պիտի դրվեն միշտ։ Այս կոդը մանկավարժորեն արդարացված չէ, որովհետև for-ը, if-ը, while-ը և մյուսները միշտ պիտի ընկալվեն ոչ թե որպես հրամաններ, այլ որպես կառուցվածքներ։

Պրեզենտացիաներում և օրինակներում միշտ պետք է գրել հետևյալ կերպ։

Այսպիսի մտքեր, հավանաբար սա դեռ սկիզբն է, հետագայում էլի նմանատիպ օրինակներ կհավաքվեն․․․

Դբա Լավը 😉

ՀԳ։ Ծրագրավորում դասավանդողներս պիտի լինենք ծրագրավորման լեզվի և մարդկանց մտքի միջև միջնորդներ, պիտի հեշտացնենք այլ ոչ ՝ բարդացնենք ընկալումը։ Տենց ․․․

ՀԳ2։ Իհարկե լինում են դեպքեր, երբ անհրաժեշտ է վրիպակ կամ տրամաբանական սխալներ գրել կոդի մեջ , որը ուսանողները պիտի վրիպազերծեն (debug) սա այլ բանի մասին է, սա այն դեպքն է, որ պետք չէ իզուր տեղը բարդացնել գաղափարների ընկալումը և դրանք կիրառելու պրակտիկան։

ՀԳ3։ Գրելիս հիշեցի, որ Մերֆիի սկզբունքի ձևակերպումներից մեկը հնչում է հետևյալ կերպ․ “եթե մի բան կարելի է սխալ անել, ապա կգտնվի մեկը ով դա սխալ կանի” ։Ճ