-
“წერეთ კომენტარები”
-
“უკომენტარო პროგრამა არაფრად არ ღირს”
-
“საერთოდ დაიწყეთ კომენტარებით”
-
“კომენტარები არ უნდა აღწერდეს ცხად პროცესებს”
-
“პროგრამის ფუნქციებისა და ცვლადების სახელების სწორად შერჩევა იგივე თვითდოკუმენტაციაა”
ყველა ეს ფრაზა წარმოადგენს ციტატას სხვადასხვა ავტორების (პროგრამისტების) სტატიებიდან და ისინი დაწერილია მრავალწლიანი გამოცდილების საფუძველზე. დავრწმუნდი რა მათ ხეირიანობაში გადავწყვიტე, რომ ერთ თემაში მომექცია და განმეხილა თითოეული ცალ-ცალკე.
ასეთი, გამოცდილების საფუძველზე მიღებული რჩევები უამრავია, მაგრამ შეიძლება გამოცდილმა პროგრამისტმა იკითხოს: რაში მარგია ისინი თუ კი პროექტზე მუშაობისას პუნქტუალურობისა და პროპესიონალური ჩვევების გამოყენებისათვის დრო არ მრჩებაო. პრინციპში სწორეა, რეალობასთან ახლოა, მაგრამ ჩემს თავზე დავრწმუნდი, რომ ეს არ არის გასამართლებელი საბუთი. სწორედ ამ პრობლემის გადაწყვეტას შევეცადე ამ სტატიაში და თუ როგორ გამომივა, ეს უკვე მკითხველმა განსაჯოს.
მიზანი მარტივია: თითოეული ეს რჩევა შეიძლება გაერთიანდეს ერთ, კერძოდ კი პირველ წინადადებაში: “წერეთ კომენტარები”.
ახლა კი განვიხილოთ ცალ-ცალკე.
“უკომენტარო პროგრამა არაფრად არ ღირს”
დავიწყოთ იქიდან, რომ კომენტარების საჭიროება უკვე დიდი ხანია ცნობილია პროგრამისტებში, განსაკუთრებით იმ დროიდან როდესაც ობიქტურად-ორიენტირებული პროგრამირების პრინციპები ჯერ კიდევ არ იყო რეალიზებული პროგრამირების ენებში და ათასობით სტრიქონიანი პროგრამები იგებოდა ციკლების, ფუნქციების, პროცედურებისა და იმ ტანჯული goto ოპერატორის ხარჯზე. მაგრამ, შემდგომ, პროგრამირებაში “რევოლუციური” გარდაქმნებისდა მიუხედავად კომენტარებმა მაინც არ დაკარგეს თავისი აქტუალურობა, ამის მიზეზის გაგების ერთად-ერთი გზა არის კონკრეტული პროგრამების წერა, ისევე როგორც C++-ის შემქმნელის ბიარნ სტრაუსტრუპის თანახმად “პროგრამირების ენის სწავლის ერთად-ერთი გზა ამ ენაზე პროგრამების წერაა”.
კომენტარები მართლაც აუცილებელია, განსაკუთრებით მაშინ, როცა საქმე გვაქვს საშუალო და დიდ პროექტებთან. ასევე ისეთ პროექტებთან, რომლებიც საჭიროებენ შემდგომ განახლებას, ახალი ფუნქციების დამატებას, ზედაპირულ ცვლილებებს და ა.შ. ამ ჩამონათვალში შეგნებულად არ ვახსენე ტერმინი პროგრამის გადაკეთება, რადგან ეს უშუალოდ ეწინააღმდგება ჩვენი სტატიის მიზანს – საქმისადმი პროფესიონალურ მიდგომას.
კომენტარები ასევე საჭიროა თქვენს მიერ შექმნილი ბიბლიოთეკური ფუნქციების გაფორმებისათვისაც, რათა, თუნდაც ერთი წლის მივიწყებული და მრავალჯერ “ნახმარი” ფუნქციის ტანი, რომელიც მაგალითად, აბრუნებს მოცემულ ფაილში ჩანაწერთა რაოდენობას, რედაქტირების და განახლების მიზნით ნახვის დროს არ მოგვეჩვენოს უცხოდ და ეჭვი არ შეგვეპაროს იმაში, რომ ამ ფუნქციის ტანი წარმოადგენს თუ არა ჩვენს საკუთრებას.
კარგად კომენტირებული პროგრამა გარკვეული დროის შემდეგ კარგადაც იკითხება, აღიქმება, და სწრაფად ახსენებს პროგრამის ავტორს თითოეული პროგრამული ბლოკის დანიშნულებას. ეს კი თავის მხრივ აადვილებს პროგრამაში ცვლილებების შეტანის პროცესს და ზოგავს თქვენს დროს და ენერგიას ანუ როგორც იტყვიან გიადვილებთ სიცოცხლეს.
ხოლო უკომენტარო პროგრამა პროგრამის ავტორისათვისაც კი წარმოადგენს კიდევ ერთ პრობლემას და სხვათაშორის პროდუქტის არასწორი მუშობის და ფუნქციონალურად დაუხვეწელობის მიზეზიც შეიძლება გახდეს. ეს უკანსკნელი უკავშირდება ობიექტურად-ორიენტირებულ სისტემებში კლასების და მეთოდების სახელების სწორად შერჩევის ფენომენს და ამდენად სცილდება ჩვენი სტატიის საზღვრებს.
შევთანხმდეთ, რომ მაგალითები აქ და შემდგომშიც მოყვანილი იქნება C/C++ პროგრამირების ენებიდან. ცხადია, თითქმის იგივე სამართლიანი იქნება სხვა ენებისათვისაც - ყველგან სადაც არის კომენტარების მხარდაჭერა. გარდა ამისა უნდა აღინიშნოს, რომ კომენტარები შეიძლება იყოს რა თქმა უნდა ქართულადაც, თუ ამას ხელს უწყობს შესაბამისი რედაქტორის შესაძლებლობები.
“საერთოდ დაიწყეთ კომენტარებით”
ეს ფრაზა შეიძლება გავიგოთ, როგორც პირდაპირი ასევე გადატანითი მნიშვნელობით. კერძოდ, პირდაპირი გაგება გულისხმობს მაგალითად იმას, რომ, როდესაც ვიწყებთ ქვეპროგრამის(ზოგადობისთვის ვიხმართ ამ ტერმინს) დეკლარაციას, ან მის ტანში მისი რომელიმე ქვებლოკის რეალიზებას ან სხვა რაიმე პროგრამული კოდის აღწერას სასურველია რომ თავიდანვე მოკლედ მიეთითოს ამ კოდის დანიშნულება, მიზანი, შესაძლებლობები, მუშაობის საზღვრები ან სხვა რაიმე მსგავსი ტიპის აღწერა. მაგალითად, დავუშვათ რომ საჭიროა რაღაც რეალური ტიპის მონაცემების დისკიდან წაკითხვა, რაიმე რთული მათემატიკური მეთოდით დამუშავება და შედეგების გარკვეული წესით ეკრანზე გამოტანა:
// Elaboration Data from 1 to 1000 for real values:
void RunElaboration()
{
. . . . . . .
. . . . . . .
//reading from file:
for(int i=1; i<=1000; i++)
{
. . . . . . .
}
//elaboration:
. . . . . . .
//show:
. . . . . . .
}
ახლა რაც შეეხება თვითონ მაგალითს.
პირველი კომენტარი აღწერს თვით ფუნქციის სრულ დანიშნულებას. დანარჩენი სამი კი ალგორითმის კონკრეტული ეტაპების – ქვებლოკების შინაარსს. იგულისხმება რომ თითოეულ კომენტარს მოსდევს მინიმუმ ათ სტრიქონიანი კოდი, ესე იგი საქმე არ გვაქვს პატარა ზომის ქვეპროგრამასთან. თუ რატომ გავუსვით ამას ხაზი, ამაზე ცოტა მოგვიანებით ვილაპარაკებთ.
ახლა რაც შეეხება განსახილველი წესის მეორე, გადატანითი მნიშვნელობით გაგებას.
საქმე იმაშია, რომ როდესაც ვიწყებთ პროგრამული ბლოკის(ქვეპროგრამა, ქვებლოკი და ა.შ.) შედგენას, ალგორითმის მოფიქრებისას პარალელურად უნდა გავითვალისწინოთ ისიც თუ რა სახით მოვახდინოთ მისი კომენტირება, რამდენად საჭიროა თუ ზედმეტია ესა თუ ის კომენტარი, სად უფრო მიზანშეწონილია ამა თუ იმ კომენტარის ჩასმა და ასე შემდეგ. ეს გაადვილებს პროგრამის წერას და მოხსნის მაგალითად გრძელსახელიანი ფუნქციების აუცილებლობას: წინა მაგალითი შეიძლება ასედაც მოგვეყვანა:
void Run_Elaboration_of_data_from_1_to_1000()
{
. . . . . . .
. . . . . . .
}
- ეს სიცხადისათვის; ჩანს, რომ ფუნქცია ძირითად კომენტარს თითქმის არ საჭიროებს. იმედია პრობლემა გასაგებია.
“კომენტარები არ უნდა აღწერდეს ცხად პროცესებს”
ამ ფრაზაში კი თითქმის ყველაფერია ნათქვამი. მაინც რა ცხად პროცეზებზეა ლაპარკი? სიმარტივისათვის განვიხილოთ იგივე მაგალითი:
// Elaboration Data from 1 to 1000 for real values:
void RunElaboration()
{
. . . . . . .
//reading from file:
for(int i=1; i<=1000; i++)
{
ARR[ i ][ 1 ]=GetXFromFile( i ); //reading x value
ARR[ i ][ 2 ]=GetYFromFile( i ); //reading y value
. . . . . . . . .
}
//elaboration:
. . . . . . .
//show:
. . . . . . .
}
ალბათ შენიშნეთ, რომ აქ არაფერია შეცვლილი გარდა კოდის ცოტაოდენი დაკონკრეტებისა და ორიცალი კომენტარისა: “//reading x value” და “//reading y value”. აი სწორედ ასეთი სახის კომენტარებზე ლაპარაკობს ასე თავგამოდებით ეს ჩვენი “აქსიომა”. გასაგებია, რომ ის ოპერაციები რასაც ისინი კომენტირებენ ისედაც ცხადია და მათთვის კომენტარის მიწერა მხოლოდ ართულებს საქმეს და მეტი არაფერი. კერძოდ კი აძნელებს კითხვადობას და გარკვეულწილად ზრდის კოდსაც.
კიდევ ასეთი მაგალითი:
void RUN_main()
{
Init(); //initialization of fields
FillArray(); // filling array
MakeConnection(); //make connection
CheckAvailability();
ExchangeData();
Work();
Done();
}
აქაც თვალნათლივ ჩანს, რომ ეს კოდი არანაირ კომენტირებას არ საჭიროებს, რადგან გამოსაძახებელი ფუნქციები ისედაც ცხადად აღწერენ პროცესების შინაარსს.
ამ უკანასკნელ შემთხვევას ეხება სწორედ შემდეგი წესი:
“პროგრამის ფუნქციებისა და ცვლადების სახელების სწორად შერჩევა იგივე თვითდოკუმენტაციაა”
ვფიქრობ ყველაფერი ისედაც ნათქვამია და დაღეჭილის ხელახლა ღეჭვას არც აქ შევუდგები. უბრალოდ დავძენ ერთს: მე მირჩევნია, რომ ცხადი იყოს პროგრამის ცვლადების და ფუნქციების სახელები, თუნდაც ისინი შეიცავდნენ 20-30 სიმბოლოს და მეტს, ვიდრე ვწერო მოკლე სახელები და სამაგიეროდ კოდი ავავსო კომენტარებით.
სხვათაშორის ცნობილია, რომ სწორედ ამ საკითხში არანაკლები პუნქტუალურობით გამოირჩევიან ჰუმანიტარული და ლიტერატურული განათლების მქონე პროგრამისტები, რომელთაც აქვთ საკმაოდ დიდი სიტყვიერი მარაგი უცხო ენებში, ვიდრე ვთქვათ, მხოლოდ ტექნიკური განათლების მქონე ადამიანები.
უკანასკნელი წესი განსაკუთრებით მნიშვნელოვანია იმათთვის ვინც ინტენსიურად მუშაობს ობიექტურად-ორიენტირებულ სისტემებში და ხშირად უხდება დიდი მოცულობის კლასთა სტრუქტურების აგება.
ამჯერად სულ ეს არის რისი თქმაც მინდოდა.
კომენტარების შესახებ კიდევ ბევრია სალაპარაკო, მაგრამ მე შევეცადე, რომ ძირითადი მომენტები გადმომეცა რაც შეიძლება მოკლედ. იმედია ამ სტატიაში იყო ცოტა მაინც სასარგებლო ინფორმაცია დამწყები პროგრამისტებისათვის.
რეზიუმე
“ წერეთ კომენტარები ! ”
ავტორი: გიორგი ბაწაშვილი (G3B)
დაწვრილებით
აღდგენილია სტატიის საწყისი ვარიანტი