ပိုေကာင္းတဲ့ ပရုိဂရမ္မာ – ၄

အပိုင္း ၁ သင္ခန္းစာ ၃  ကုဒ္ေလွ်ာ့ေရးပါ

“အနည္းဆုံးသုံးစြဲျခင္းျဖင့္ အရာရာျပည့္စုံလုံေလာက္ပါေစ” – Jules Verne

 

ဒီေခတ္ျကီးမွာ ကုဒ္ေတြအရမ္းမ်ားလြန္းေနတယ္ ဒါဟာ ၀မ္းနည္းစရာေကာင္းေပမဲ့ မွန္ကန္တဲ့အေျကာင္းအခ်က္ပါ။

က်ဳပ္ကားအင္ဂ်င္ကို ကြန္ပ်ဴတာနဲ႕ထိန္းခ်ဳပ္ထားတယ္ဆိုတဲ့အခ်က္ကို က်ဳပ္လက္ခံႏုိင္တယ္။

မိုက္ခရိုေ၀့မီးဖိုထဲမွာ ေဆာ့၀ဲက ခ်က္တဲ့အလုပ္လုပ္တယ္ဆိုတာလည္း သိသာပါတယ္။

ဇီ၀ေဗဒနည္းနဲ႕ျပဳျပင္ထားတဲ့ သခြားသီးထဲမွာ မိုက္ခရိုကြန္ထရိုလာ တခုျမွဳပ္ထားတယ္ဆိုရင္ေတာင္ က်ဳပ္မအံ့ျသဘူး။

ေကာင္းပါၿပီေလ ဒါေတြကို က်ဳပ္ေရးျကီးခြင္က်ယ္ထည့္ေျပာေနတာမဟုတ္ပါဘူး။

က်ဳပ္စိတ္ပူမိတာက မလိုအပ္ပဲမ်ားျပားေနတဲ့ ကုဒ္ေတြကိုပါ။

မလိုအပ္ပဲ ကုဒ္ေတြအလြန္မ်ားေနတာ ေတြ႕ရတယ္။

ေပါင္းပင္ေတြလိုပဲ ဒီဆိုးရြားလွတဲ့ကုဒ္စာေျကာင္းမ်ားစြာဟာ

သိမ္းဆည္းစရာအဖိုးတန္ (storage bytes) ေနရာေတြကို ပိတ္ဆို႕ေစႏုိင္တယ္။

Source control စနစ္ ရဲ့ မွတ္တမ္းမွတ္ရာေတြကို ပိုရွဳပ္ေထြးေစႏိုင္တယ္။

ေဆာ့၀ဲတည္ေဆာက္ျခင္းလမ္းေျကာင္းမွာလည္း အဟန္႕အတားျဖစ္ေစႏိုင္တယ္။

အဖိုးတန္ကုဒ္သိမ္းလို႕ရမယ့္ေနရာေတြကိုလည္း ျဖဳန္းပစ္တယ္။

သူတို႕နားက ေကာင္းတဲ့ကုဒ္ေတြကိုလည္း ပိတ္ဆို႕ေစႏိုင္တယ္။

 

ဘာေျကာင့္မ်ား မလိုအပ္ပဲ ကုဒ္ေတြ မ်ားျပားေနရပါလိမ့္။

 

တခ်ိဳ႕လူေတြက သူတို႕ရဲ့ကိုယ္ပုိင္အသံကို ျပန္ျကားခ်င္ျကတယ္။

သင္သူတို႕နဲ႕ဆုံလည္း သူတို႕က ပါးစပ္ေပါက္ပိတ္မသြားဘူး။

ဒီလူေတြဟာ ပါတီေတြမွာ သင္မဆုံခ်င္တဲ့လူေတြေပါ့။

တခ်ိဳ႕လူေတြျကေတာ့ သူတို႕ကုဒ္ကို သူတို႕အလြန္ႏွစ္သက္ျကျပန္တယ္။

ဒီေတာ့သူတုိ႕က ကုဒ္မ်ားစြာမလိုအပ္ပဲ ေရးျကတယ္။

 

ေနာက္ျဖစ္ႏိုင္တာကေတာ့ သူတို႕က တစ္ေန႕ကုဒ္အေျကာင္းေရ ေထာင္နဲ႕ခ်ီေရးမွ တိုးတက္တယ္လို႕ အကဲျဖတ္တတ္တဲ့ အယူလြဲမန္ေနဂ်ာလက္ေအာက္မွာ လုပ္ရတဲ့ ပရုိဂရမ္မာေတြျဖစ္ႏိုင္လို႕ပါပဲ။

 

ကုဒ္ေတြအမ်ားျကီးေရးတယ္ဆိုတာနဲ႕ပဲ သင္ေဆာ့၀ဲေတြအမ်ားျကီးအလုပ္လုပ္တယ္လို႕ ေျပာ၍မရပါ။

တကယ္ေတာ့ တခ်ိဳ႕ကုဒ္ေတြက သင့္ေဆာ့၀ဲကို မေကာင္းတဲ့အက်ိဳးေက်းဇူး သက္ေရာက္ေစႏိုင္တယ္။

ေဆာ့၀ဲသြားမယ့္လမ္းေျကာင္းကို ပိတ္ေစႏုိင္တယ္။

အမွားေတြျဖစ္ေစႏုိင္တယ္။

ေဆာ့၀ဲအရည္အေသြးကို နိမ့္က်ေစႏိုင္တယ္။

 

မွတ္ရန္ ။ ။ ကုဒ္ေလွ်ာ့ေရးျခင္းျဖင့္ ေဆာ့၀ဲပိုအလုပ္လုပ္ႏုိင္ပါတယ္။

 

က်ဳပ္ရဲ့ေဆာ့၀ဲအရည္အေသြးျမွင့္တင္ျခင္းေတြထဲက အေကာင္းဆုံးလုပ္ေဆာင္မွဳတခုကေတာ့ ကုဒ္ေတြကို ဖယ္ရွားျခင္းျဖစ္ပါတယ္။

က်ဳပ္ေကာင္းေကာင္းမွတ္မိေနတာတခုကေတာ့ ေဆာ့၀ဲစနစ္တခုကေန ကုဒ္အေျကာင္းေရ ေထာင္ေပါင္းမ်ားစြာကို ကုဒ္ဆယ္ေျကာင္းေလာက္နဲ႕ အစားထိုးလိုက္ႏုိင္တာပါပဲ။

က်ဳပ္အတြက္ေတာ့ ေက်နပ္စရာေကာင္းတဲ့ခံစားခ်က္ပါပဲ။

သင္တို႕လည္း တခါတေလစမ္းျကည့္သင့္တယ္။

ဘာေျကာင့္ သတိထားသင့္လဲ

ဘာေျကာင့္ ကုဒ္ေတြမ်ားလြန္းတာဟာ စိတ္အေႏွာင့္အယွက္ျဖစ္ယုံမကပဲ ဆုိးရြားလွတာလဲ။

မလိုအပ္တဲ့ကုဒ္ေတြက အဆုိးတကာ့အဆိုးဆုံးျဖစ္ရတဲ့အေျကာင္းမ်ားစြာ ရွိပါတယ္။

ဒီထဲကတခ်ိဳ႕ကေတာ့

  • ကုဒ္အသစ္တေျကာင္းေရးျခင္းဟာ လူ႕အသက္တစ္ေခ်ာင္းစတင္ေမြးဖြားလိုက္သလိုပါပဲ။ ေဆာ့၀ဲထုတ္ကုန္သစ္အျဖစ္မေရာက္ရွိခင္ ေဆာ့၀ဲလူ႕အဖြဲ႕အစည္းအတြက္ အသုံး၀င္ၿပီး အဖိုးတန္ျဖစ္လာေအာင္ ကေလးတစ္ေယာက္ကို ျပဳစုေစာင့္ေရွာက္သလို ဂရုစိုက္ေပးမွရပါမယ္။

 

သင့္ေဆာ့၀ဲစနစ္ရဲ့ ဘ၀သက္တမ္းတေလွ်ာက္မွာ ဒီကုဒ္တစ္ေျကာင္းကို သင္ထိန္းသိမ္းျပဳျပင္ဖို႕ လိုအပ္လာပါလိမ့္မယ္။ ကုဒ္တေျကာင္းအတြက္ ျပင္စရိတ္နည္းနည္းက်ပါလိမ့္မယ္။ သင္ကုဒ္မ်ားမ်ားေရးေလ ျပင္စရိတ္ပိုမ်ားေလပါပဲ။ ကုဒ္တေျကာင္းက အခ်ိန္ျကာျကာပိုအသက္ရွင္ေလ သူ႕အတြက္ထိန္းသိမ္းစရိတ္ပိုမ်ားေလပါပဲ။ က်ဳပ္တို႕ကို ေဒ၀ါလီခံရေစဖို႕မျဖစ္ခင္ မလိုအပ္တဲ့ကုဒ္ေတြကို အဆုံးသတ္ပစ္ဖို႕လိုအပ္တာ ရွင္းပါတယ္။

  • ကုဒ္ေတြပိုမ်ားလာေလေလ ပိုဖတ္ရေလေလ ပိုနားလည္စရာမ်ားလာေလေလပါပဲ။ ဒါနဲ႕ပဲ က်ဳပ္တို႕ရဲ့ ပရိုဂရမ္ကို နားလည္သေဘာေပါက္ဖို႕ ပိုခက္လာေရာ။ မလိုအပ္တဲ့ကုဒ္အပို္ေတြဟာ function တခုရဲ့ ရည္ရြယ္ခ်က္ကို ဖုံးကြယ္ပစ္ႏုိင္တယ္။ ဆင္တူသလိုရွိေနတဲ့ကုဒ္ေတြမွာ ငယ္ေပမယ့္ အေရးျကီးတဲ့ကြဲျပားခ်က္ေတြကိုလည္း ဖုံးကြယ္ပစ္ႏုိင္တယ္။
  • ကုဒ္ပိုမ်ားလာေလေလ ျပင္ဖို႕လိုလာရင္ ျပင္စရာပိုမ်ားလာေလ့ရွိတာမို႕ ပရိုဂရမ္ကို ျပင္ဖို႕ ပိုခက္ခဲလာပါလိမ့္မယ္။
  • ကုဒ္ေတြက ခ်ိဳ႕ယြင္းခ်က္(bugs) ေတြကို ကြယ္၀ွက္ထားေပးႏုိင္တယ္။ ကုဒ္ေတြပိုမ်ားလာေလေလ ခ်ဳိ႕ယြင္းခ်က္ေတြ ပုန္းခိုစရာေနရာပိုမ်ားလာေလေလပါပဲ။
  • ခြ်တ္စြပ္တူတဲ့ကုဒ္ေတြက ပိုလို႕ေတာင္ ဒုကၡေပးႏုိင္ပါတယ္။ ေကာ္ပီကူးထားတဲ့တစ္ေနရာက ကုဒ္ေတြရဲ့ခ်ိဳ႕ယြင္းခ်က္ကို သင္ျပဳျပင္လိုက္ေပမယ့္ သင္မသိပဲ ထပ္ရွိေနေသးတဲ့ ေနာက္ထပ္၃၂ ေနရာေလာက္က လုံး၀တူညီတဲ့ခ်ိဳ႕ယြင္းခ်က္ေတြကို ရွိေနပါလိမ့္မယ္။

 

မလိုအပ္တဲ့ကုဒ္ေတြဟာ ဥာဏ္နီဥာဏ္နက္တတ္ပါတယ္။ မသုံးပဲထားတဲ့ အစိတ္အပိုင္း(components) ေတြ၊ အသက္မဲ့ေနတဲ့ကုဒ္ေတြ၊ အဓိပါၸယ္မရွိတဲ့ မွတ္ခ်က္(comments) ေတြ၊ မလိုအပ္ပဲ စကားလုံးေတြမ်ားျပားလြန္းတာေတြ စသျဖင့္ မလိုအပ္တဲ့ကုဒ္ပိုေတြဟာ အသြင္မ်ိဳးစုံနဲ႕ရွိတတ္ပါတယ္။

 

ပ်ာယာခတ္ logic(ေတြးေခၚျခင္း)မ်ား

ရည္ရြယ္ခ်က္မဲ့ေနတဲ့ကုဒ္ေတြကို ရိုးရိုးရွင္းရွင္းဥပမာေပးရရင္ မလိုအပ္တဲ့ မွန္မမွန္စစ္ေဆးျခင္းေတြပါပဲ။

ပ်ာယာခတ္ေအာင္ေရးထားတဲ့ logic ေတြဟာ ပ်ာယာခတ္ေနတဲ့စိတ္ကို ကိုယ္စားျပဳတယ္။

Logic တည္ေဆာက္ပုံေတြကို ေသခ်ာနားမလည္လို႕လည္း ျဖစ္ႏိုင္တယ္။

 

 

01

လို႕ေရးထားတဲ့ဟာကုိ

02

လို႕ လိုတိုရွင္းေရးႏိုင္ပါတယ္။

 

ဒီလိုေရးလိုက္ေတာ့ ပိုၿပီး က်စ္လစ္တဲ့အျပင္ ပိုဖတ္ရလြယ္လို႕ နားလည္ဖို႕ပိုလြယ္ကူလာတယ္။

အဂၤလိပ္စာေျကာင္းတေျကာင္းနဲ႕တူလို႕ ဖတ္ရတဲ့လူေတြကိုလည္း ကူညီရာေရာက္တယ္။

Compiler ကလည္း ဒီလိုေရးလို႕ စိတ္လုံး၀မဆိုးဘူးဆိုတာ သင္သိပါသလား။

 

ထို႕နည္းတူစြာ စကားလုံးေဖာင္းပြေနတဲ့ ေအာက္က စစ္ေဆးခ်က္ကို

 

03

ေအာက္ကအတိုင္းေျပာင္းေရးလိုက္ရင္ ပိုေကာင္းမွာပါ

04

ဒီဥပမာေတြက ရိုးရိုးရွင္းရွင္းေဖာ္ျပထားတာပါ။

အျပင္ေလာကမွာေတာ့ ဒီထက္ပိုရွဳပ္ေထြးတဲ့ စစ္ေဆးျခင္းတည္ေဆာက္ပုံေတြကို က်ဳပ္တို႕ ျမင္ေတြ႕ဘူးမွာပါ။

ရိုးရိုးရွင္းရွင္းေလးကို ရွဳပ္ေထြးေအာင္လုပ္ပစ္ႏုိင္တဲ့ ပရိုဂရမ္မာတစ္ေယာက္ရဲ့ အစြမ္းအစကုိ ေလွ်ာ့မတြက္ပါနဲ႕။

တကယ့္အျပင္ေလာကမွာ ဒီထက္ပိုရွုပ္ေထြးနက္နဲတာေတြက ဒီလိုပုံစံမ်ိဳးေလးေတြ

 

05

ဒါကို တေျကာင္းတည္းနဲ႕ျပတ္ေအာင္ ဒီလိုေရးလို႕ရပါတယ္

06

 

ေ၀့လည္ေျကာင္ပတ္မလုပ္ပဲနဲ႕ ေျပာခ်င္တာကုိ တိုတိုတုတ္တုတ္နဲ႕ ရွင္းရွင္းလင္းလင္းေျပာပါ။

သင္သုံးတဲ့ ပရိုဂရမ္ဘာသာစကားဘယ္လိုအလုပ္လုပ္သလဲသိေအာင္ လုပ္ဖို႕ မရွက္ပါနဲ႕။

ပရိုဂရမ္မွာေရးထားတဲ့ေဖာ္ျပခ်က္ ( expression ) ေတြဟာ ဘယ္လိုအစဥ္အတိုင္းအလုပ္လုပ္တယ္ဆိုတာ သိေအာင္လုပ္ထားၿပီး အက်ိဳးရွိရွိအသုံးခ်ျခင္းျဖင့္ မလိုအပ္တဲ့ logic ေတြ အမ်ားျကီးကို ေလွ်ာ့ခ်ေပးႏုိင္တယ္။

ဥပမာအားျဖင့္

 

07

လို႕ေရးထားတာကုိ

 

08

ရိုးရွင္းစြာ ျပန္ျပင္ေရးႏိုင္ပါတယ္။

 

မွတ္ရန္။။ ကုဒ္ေတြကို တိုတိုနဲ႕ ရွင္းရွင္းေရးသားေဖာ္ျပပါ။ မလိုအပ္ပဲ ေကြ့ေကာက္ေ၀့၀ိုက္ ေရးသားျခင္းမ်ိဳး ေရွာင္ျကဥ္ပါ။

 

ထပ္ေနတဲ့ကုဒ္မ်ား

မလိုအပ္ပဲကုဒ္ေတြထပ္ေနတာ ဆိုးလွပါတယ္။

ကုဒ္ေတြကို cut-and-paste လုပ္ၿပီး ပရုိဂရမ္ေရးသားမွဳမ်ိဳး ၊ ထပ္ကာထပ္ကာေရးမိေနတဲ့ကုဒ္ေတြကို function တခုခြဲထုတ္ၿပီးေရးလိုက္ဖို႕ အပ်င္းထူတဲ့ ပရုိဂရမ္မာေတြက တစ္ေနရာက တစ္ေနရာကို စာအားလုံး copy ကူးၿပီး ေရးသားမွဳမ်ိဳးကေန ကုဒ္ထပ္တာေတြ အမ်ားဆုံးေတြ႕ရတတ္ပါတယ္။

နည္းနည္းေလးျပင္ၿပီး တျခားေနရာကို ကူးယူေရးသားျခင္းက စည္းကမ္းပိုေဖာက္ဖ်က္ပါတယ္။

 

ကုဒ္ေတြကို သင္ကူးယူၿပီး ေရးလိုက္တဲ့အခါ ထပ္ေနတဲ့ကုဒ္တည္ေဆာက္ပုံကိုပါကူးတာျဖစ္တဲ့အတြက္ သင္ဟာ ရွိၿပီးသား ခ်ိဳ႕ယြင္းခ်က္(bugs) ေတြကို ကူးယူမိၿပီးသားျဖစ္သြားပါတယ္။

တေနရာက ခ်ိဳ႕ယြင္းခ်က္ေတြကို သင္ျပဳျပင္လိုက္ေပမယ့္ ေနာက္တေန႕မွာ ေနာက္တေနရာက ခြ်ပ္စြပ္တူတဲ့ခ်ိဳ႕ယြင္းခ်က္ေတြက သင့္ကို ဒုကၡေပးေနဦးမွာပါ။

ေနရာတုိင္းမွာထပ္ကာထပ္ကာပါေနမယ့္ကုဒ္ေတြကို function တခုအေနနဲ႕ ထုတ္ေရးပါ။

ဆင္တူေနတဲ့အပိုဒ္မ်ားၿပီး နည္းနည္းေလးသာ ကြဲျပားမွဳရွိခဲ့ရင္ ကြဲျပားတာေတြကို function ထဲသို႕ parameter တခုေပးပို႕ၿပီး ေရးသားပါ။

 

မွတ္ရန္။ ။ ကုဒ္ေတြကို အပုိဒ္လိုက္ ကူးမေရးပါနဲ႕။ ဘုံ function တခုအျဖစ္ ထုတ္ေရးပါ။ ကြဲျပားမွဳေလးေတြအတြက္ parameter သုံးၿပီး ေဖာ္ျပေရးသားပါ။

 

DRY နည္းလို႕ လူသိမ်ားတဲ့ နည္းတခုရွိပါတယ္ ။ အရွည္က Don’t Repeat Yourself ပါ။ ထပ္ကာတလဲမလုပ္ပါနဲ႕။ မလိုတာေတြမပါတဲ့အျပင္ မထပ္တဲ့ကုဒ္မ်ိဳးကို ရည္ရြယ္ေရးသားပါ။ ဆင္တူတဲ့ကုဒ္ေတြကို မွ်ေ၀သုံးလို႕ရတဲ့ function တခုအျဖစ္ ေရးသားျခင္းအားျဖင့္ ကုဒ္ေတြဟာ ပိုမိုခ်ိတ္ဆက္လာတာကို သတိထားပါ။

မွ်ေ၀သုံးရတဲ့ တေနရာထဲကို မွီခိုရသလိုျဖစ္လာၿပီး ထိုေနရာကို ျပင္လိုက္ရင္ တျခားေခၚသုံးထားတဲ့ေနရာေတြကိုပါ ျပင္ဆင္ဖို႕ လိုအပ္လာမွာျဖစ္ပါတယ္။

ပုံမွန္ကေတာ့ ဒီလိုျပင္ဆင္ရတာ အဆင္ေျပေပမယ့္ အၿမဲတမ္းေတာ့ ဒီလိုျဖစ္ခ်င္မွာမဟုတ္ပါဘူး ေရရွည္မွာ ကူးေရးတာထက္ ပိုျပသနာတက္ႏိုင္လို႕ တာ၀န္သိသိ ေရးသားပါ။

 

ကုဒ္ေတြထပ္ေနရတာ အားလုံးဟာ တမင္တကာလုပ္လို႕ ပရိုဂရမ္မာေတြရဲ့အမွားေျကာင့္မုိ႕လို႕ပဲ မဟုတ္ပါဘူး။

မရည္ရြယ္ပဲ ထပ္သြားတာေတြလည္း ရွိတတ္ပါတယ္။

သူမ်ားေရးၿပီးသားရွိတာကိုမသိပဲ ျပန္တီထြင္ေနတာမ်ိဳးလည္း ရွိတတ္ပါတယ္။

အဆင္သင့္အသုံးခ်ႏိုင္တဲ့ third party library တခုရွိတာကို မသိပါပဲ function အသစ္တခုတည္ေဆာက္ေရးသားေနတာမ်ိဳးေျကာင့္လည္း ျဖစ္ႏို္င္ပါတယ္။

ဒါက တကယ္ဆိုးပါတယ္ ဘာလို႕လဲဆိုေတာ့ ရွိၿပီးသား library တခုက ပိုမွန္ႏို္င္ၿပီး ပိုစမ္းထားမ်ိဳးျဖစ္ႏိုင္လို႕ပါ။

အမ်ားသုံး library ေတြကို သုံးျခင္းအားျဖင့္ သင့္ရဲ့အားထုတ္မွဳေတြကို သက္သာေစမယ့္အျပင္ ျဖစ္ႏုိင္ေခ်ရွိတဲ့အမွားေတြကို ေရွာင္ရွားႏုိ္င္ပါတယ္။

 

အႏုစိတ္ထပ္ေနတာမ်ိဳးလည္း ရွိႏုိင္ပါတယ္။ ဥပမာ

 

09

if တခုတည္းနဲ႕စစ္ၿပီး သုံးေျကာင္းလုံးကို အတြင္းထဲမွာထားလိုက္ျခင္းျဖင့္ ပိုသပ္ရပ္စြာေရးႏိုင္ပါတယ္။

 

loop မ်ားစြာပတ္ေနတာကိုလည္း loop တခုထဲသုံးၿပီး ပတ္ႏိုင္ပါတယ္။ ဥပမာ

10

ေရးတာမ်ိဳးကို

 

11

အျဖစ္ေရးတာက ပိုဖတ္ရလြယ္ၿပီး ပိုနားလည္ဖို႕လြယ္တဲ့အျပင္ loop တျကိမ္ပတ္ရသက္သာသြားလို႕ ပိုျမန္လာပါတယ္။

ဒီလိုထပ္ေနတဲ့ စစ္ေဆးမွဳမ်ိဳးကို ေသခ်ာစဥ္းစားျကည့္ပါ။

 

12

သင္က ဒီလိုမ်ိဳးျဖစ္ေအာင္ တမင္တကာေရးမွာမဟုတ္ပါဘူး။ ဒါေပမဲ့ ျကိိမ္ဖန္မ်ားစြာ ျပဳျပင္ထိန္းသိမ္းမွဳလုပ္ထားတဲ့ ကုဒ္ေတြဟာ ဒီလိုပုံစံမ်ိဳး အဆုံးသတ္သြားေလ့ရွိပါတယ္။

 

မွတ္ရန္။ ။ ထပ္ေနတာေတြေတြ႕ရင္ သင္ဖယ္ရွားလိုက္ပါ။

 

က်ဳပ္မျကာေသးခင္ကပဲ device driver တခုေရးထားတာကို အမွားရွာေပးတုန္း ကုဒ္ထဲမွာ အေရးျကီးတဲ့ loop ႏွစ္ခုကို ေတြ႕ရပါတယ္။

ေသခ်ာစစ္ျကည့္လိုက္ေတာ့ loop ႏွစ္ခုဟာ လုံး၀နည္းပါတူေနၿပီး သူတို႕ထဲကို ေပးပို႕လိုက္တဲ့ data type ေပၚမူတည္ၿပီး အနည္းငယ္မွ်သာကြဲျပားျခားနားတာ ေတြ႕ရပါတယ္။

ကုဒ္အေျကာင္းေရေပါင္း သုံးရာေလာက္ရွိတဲ့ loop ထဲမွာ ဒီလိုထပ္ေနတာကို သတိထားမိဖို႕ မလြယ္လွပါဘူး။

တကယ္ကို ေကြ႕ေကာက္ ရွဳပ္ေထြးလွပါတယ္။

Loop တခုခ်င္းဆီမွာ မတူတဲ့ ခ်ိဳ႕ယြင္းခ်က္ (bugs) ေတြျပင္ထားလို႕ ကုဒ္ေတြက အလႊာလိုက္ကြာသလို ကြာလာၿပီး အင္မတန္ခန္႕မွန္းရခက္လာပါတယ္။

နည္းနည္းေလာက္အားစိုက္ၿပီး Loop ႏွစ္ခုကို တခုထဲျဖစ္ေအာင္ ေပါင္းေရးလိုက္တာ ျပသနာတ၀က္ေလာက္ေလ်ာ့ပါးသြားေစၿပီး က်ဳပ္အတြက္လည္း တေနရာထဲကို အာရုံစုိက္ၿပီး အမွားရွာႏုိင္လာပါတယ္။

 

ေသဆုံးသြားတဲ့ကုဒ္ေတြ

သင္မျပဳျပင္ပဲထားရင္ သင့္ကုဒ္ေတြဟာ ပုပ္ေဆြးသြားႏိုင္ပါတယ္။ ကုဒ္ေတြ ေသေတာင္ေသသြားႏုိင္တယ္။ ေသေနတဲ့ကုဒ္ဆိုတာ ဘယ္ေတာ့မွေခၚမသုံးတဲ့ကုဒ္ ပရိုဂရမ္က ဘယ္ေတာ့မွ မေရာက္ရွိႏိုင္တဲ့ကုဒ္ေတြပါ။ သူတို႕မွာ အသက္မရွိေတာ့ဘူး။ သင့္ကုဒ္ကို အသက္ရွင္ေအာင္လုပ္ပါ။

ေအာက္က ဥပမာေတြက ေသဆုံးသြားတဲ့ကုဒ္ေတြပါ။ အမွတ္တမဲ့ျကည့္ယုံနဲ႕သတိထားမိမွာမဟုတ္ပါ။

 

13

ေနာက္ထပ္ဥပမာတခုက

 

 

14

တျခားေသဆုံးေနတဲ့ကုဒ္ေတြကေတာ့

  • ဘယ္ေတာ့မွေခၚမသုံးတဲ့ function ေတြ
  • ေျကျငာထားၿပီး ဘယ္ေသာအခါမွ ေခၚမသုံးတဲ့ variable ေတြ
  • Function ထဲကို parameter တခုအျဖစ္ပို႕ေပးလိုက္ေပမယ့္ အဲ့ parameter ကို ဘယ္ေတာ့မွ ေခၚမသုံးမိတာမ်ိဳးျဖစ္သြားတဲ့ parameter ေတြ
  • ေျကျငာထားေပမယ့္ ဘယ္ေတာ့မွ ေခၚမသုံးတဲ့ Enums, structs, classes, or interfaces ေတြ

 

မွတ္ခ်က္မ်ား (Comments)

စိတ္မေကာင္းစရာကေတာ့ ဒီကမၻာျကီးက ဆိုးရြားတဲ့ မွတ္ခ်က္ေတြနဲ႕ ပေဟဠိဆန္ေနျကတာပါ။

ကုဒ္ editor တခုထဲမွာ မွတ္ခ်က္ေတြကို ေက်ာ္ခြၿပီးဖတ္ေနရတာမ်ိဳး သင္ျကဳံဘူးမွာပါ။

တခ်ိဳ႕ကုမၸဏီျကီးေတြရဲ့ ကုဒ္စံသတ္မွတ္ခ်က္က ဦးေႏွာက္ပ်က္သြားေစေလာက္မယ့္ မွတ္ခ်က္ေတြ သိန္းသန္းခ်ီေရးပါမွ ေကာင္းတယ္လို႕ သတ္မွတ္တာမ်ိဳးပါ။ တကယ္ကူညီရာမေရာက္ပါဘူး။

ေကာင္းတဲ့ကုဒ္က မွတ္ခ်က္ေတြ တထမ္းတပိုးနဲ႕ အေထာက္အကူျပဳတာမ်ိဳး မလိုအပ္ပါဘူး။

ေကာင္းတဲ့ကုဒ္ဆိုတာ ဘယ္လိုအလုပ္လုပ္ဆိုတာကို ရွင္းျပေနစရာမလိုပါဘူး။

Variable ေတြ function ေတြ class ေတြရဲ့ နာမည္ေတြကို ေသခ်ာဂရုတစိုက္ နာမည္ေပးျခင္း ကုဒ္ေတြရဲ့ တည္ေဆာက္ပုံေကာင္းေအာင္လုပ္ထားျခင္းျဖင့္ သင့္ကုဒ္က လုံး၀ရွင္းရွင္းလင္းလင္းရွိမွာပါ။

အထက္စာေျကာင္းပါ အေျကာငး္အရာအခ်က္အလက္ေတြကို မွတ္ခ်က္ထဲ ထပ္ထည့္ဖို႕ မလိုအပ္ပါဘူး။

တျခားထပ္ေနတာေတြလိုပဲ ကုဒ္မွာရွင္းေနတာေတြကို မွတ္ခ်က္ထဲမွာထပ္မံေဖာ္ျပျခင္းျဖင့္ ကုဒ္ျပင္ရင္ မွတ္ခ်က္ပါျပင္ရမွာကို မျပင္မိတဲ့အခါ ပိုအႏၲရာယ္မ်ားပါတယ္။

အရူးထေရးတဲ့ မွတ္ခ်က္ေတြဟာ သိမ္းရမယ့္ bytes ပမာဏကိုပါ ျဖဳန္းတီးရေရာက္ပါတယ္။ ေအာက္ပါဥပမာကိုျကည့္ပါ (I တစ္တိုးတာ ပရိုဂရမ္မာတိုင္းသိပါတယ္ မွတ္ခ်က္ေပးဖို႕ မလိုအပ္ပါဘူး။)

15

ေနာက္ဥပမာတခုကိုျကည့္ပါ။ (မွတ္ခ်က္ေပးဖို႕မလိုေအာင္ ရွင္းပါတယ္)

16

တခ်ိဳ႕ ရွုပ္ေထြးတဲ့ algorithm ေတြ ကုဒ္အပိုင္းေတြ ေလာက္ပဲ မွတ္ခ်က္ေပးၿပီး ရွင္းျပဖို႕ လိုအပ္ပါတယ္။

သင္ေရးထားတဲ့ ကုဒ္အပိုင္းက မွတ္ခ်က္မ်ားစြာလိုအပ္ၿပီဆိုရင္ function တခုကို နာမည္ေကာင္းမြန္စြာေပးၿပီး ထို function အတြင္း လိုအပ္တဲ့ Logic ေတြ ခြဲထုတ္ေရးသားျဖင္းျဖင့္ ေျဖရွင္းျကည့္ပါ။

 

မွတ္ရန္။။ သင္ေပးလိုက္တဲ့မွတ္ခ်က္အေျကာင္းတုိင္းက ကုဒ္ရဲ့ တန္ဖိုးကုို ျမင့္တက္ပါေစ။ ကုဒ္ေတြက ဘယ္လိုအလုပ္လဲ ဘာလုပ္လဲ သူ႕ဘာသူေျပာျပႏိုင္ပါတယ္။ မွတ္ခ်က္ကေတာ့ ဘာေျကာင့္လုပ္ရလဲဆိုတာ ရွင္းျပသင့္ပါတယ္။ ကုဒ္ဖတ္တဲ့သူအတြက္ တကယ္ကို ဘာေျကာင့္လုပ္လဲ မရွင္းလင္းမွသာ မွတ္ခ်က္ထည့္သင့္ပါတယ္။

 

ကုဒ္အေဟာင္းေတြကို တကယ္မဖယ္ရွားပဲ မွတ္ခ်က္အျဖစ္နဲ႕ ပိတ္လိုက္တာမ်ိဳး အေတြ႕ရမ်ားပါတယ္။

အဲ့လိုမလုပ္ပါနဲ႕။ ကုဒ္ေတြကို တကယ္ဖ်က္ပစ္ဖို႕ မ၀ံ့ရဲတဲ့လူတေယာက္က လုပ္သြားတာမ်ိဳးပါ။ ဒါမွမဟုတ္ ကုဒ္က ဘာလုပ္လဲေကာင္းေကာငး္နားမလည္ေတာ့ ေနာင္မ်ားျပန္လိုမလားဆိုတဲ့ အေတြးနဲ႕ လုပ္သြားတာမ်ိဳးပါ။

ကုဒ္ေတြ တကယ္မလိုေတာ့ရင္ လုံး၀ဖ်က္ပစ္လိုက္ပါ။ သင္ျပန္လိုခ်င္လည္း သင့္ရဲ့ source control system (ကုဒ္ေတြအေျပာင္းအလဲမ်ားကို သိမ္းေပးေသာ စနစ္) ကေနျပန္ယူလို႕ရသားပဲ။

 

မွတ္ရန္။ ။ ကုဒ္ေတြကို မွတ္ခ်က္အျဖစ္ ပိတ္လိုက္ၿပီး ဖယ္ရွားတာမ်ိဳး ေရွာင္ျကဥ္ပါ။ ဖတ္မယ့္သူေတြကို ပိုရွုပ္ေစႏုိင္ပါတယ္။

 

ကုဒ္ေတြ အရင္က ဘာလုပ္ခဲ့ဘူးတယ္ဆိုတဲ့မွတ္ခ်က္မ်ိဳးမေရးပါနဲ႕ ခုအေရးမပါေတာ့ဘူးေလ။

ကုဒ္ေတြရဲ့ အဆုံးသတ္မွာ ဒါက အဆုံးလို႕ မွတ္ခ်က္ေရးတာမ်ိဳးမလုပ္ပါနဲ႕ ကုဒ္ေတြရဲ့ ဖြဲ႕စည္းပုံကေန ဒါကို အလြယ္တကူသိႏိုင္ပါတယ္။

 

စကားလုံးေဖာင္းပြျခင္း

ကုဒ္အေတာ္မ်ားမ်ားဟာ မလိုအပ္ပဲ စကားမ်ားျကပါတယ္။

အရိုးရွင္းဆုံးဥပမာတခုေပးရရင္

 

17

အေတာ္ကို စာလုံးေတြမ်ားၿပီး ဘာဆိုလိုလည္း နားလည္ရခက္တာမ်ိဳးပါ။ ဒါကို ဒီလိုလြယ္လြယ္ေလးျပင္ေရးလို႕ရပါတယ္။

18

သင္သုံးတဲ့ ပရုိဂရမ္းမင္းဘာသာစကားကသာ ခြင့္ျပုရင္ သုံးခုနည္းကို သုံးဖို႕ မတြန္႕ဆုတ္ပါနဲ႕။ သုံးခုနည္းဆိုတာ

( (၁။ ဘာျဖစ္လဲစစ္ေဆးမယ္) ? ၂။ မွန္တယ္ဆို ဒီအပိုင္းလုပ္မယ္ : ၃။ မွားတယ္ဆိုဒီအပိုင္းလုပ္မယ္ )

ဒီနည္းကို သုံးျခင္းျဖင့္ သင့္ကုဒ္ေတြ ရွဳပ္ပြထေနတာကို ေလ်ာ့နည္းသြားေစမွာပါ။

 

ေအာက္ကေရးထားတဲ့အရွဳပ္ထုပ္ကို

19

ဒီလိုျပင္ေရးလိုက္ပါ

20

 

C Programming စတုိင္မ်ိဳး (variable ေတြကို ဟိုးထိပ္ဆုံးမွာပဲေျကညာထားဖို႕ လိုအပ္တာမ်ိဳး) ေရးသားပုံမ်ိဳးဟာ အတိတ္မွာက်န္ခဲ့ပါၿပီ။

ကမၻာျကီးက ေရြ႕လ်ားလာခဲ့ၿပီးပါၿပီ သင့္ကုဒ္ေတြကိုလည္း ေရြ႕လ်ားလိုက္ပါ။

ေအာက္ပါေရးသားျခင္းမ်ိဳးေရွာင္ျကဥ္ပါ။

21

Variable ေျကညာတာနဲ႕ ေခၚသုံးတာကုိ နည္းကပ္စြာထားရွိပါ။ ကုဒ္ေတြကို နားလည္ေအာင္အားစိုက္ရတာ ပိုေလ်ာ့နည္းသြားၿပီး ဘာမွမထည့္သြင္းရေသးတဲ့ variable မ်ိဳးသုံးမိတဲ့အမွားမ်ိဳးကိုလည္း ေလ်ာ့နည္းေစမွာပါ။

တခါတရံ variable ေတြကို အက်ိဳးမရွိေျကညာတတ္ပါတယ္။ ဥပမာ

 

22

ဒီလိုျပန္ေရးလိုက္ရင္ စာလုံးပိုနည္းမယ့္အျပင္ ပိုရွင္းလင္းေစမွာပါ။

23

ကုဒ္ဒီဇိုင္းအမွား

မလိုအပ္တဲ့ကုဒ္ေတြတည္ရွိေနတာဟာ ေအာက္ေျခ ကုဒ္အလႊာအမွားေတြေျကာင့္ ထိန္းသိမ္းမွုအမွားေျကာင့္ ျကည့္ပဲမဟုတ္ပါဘူး

အေပၚယံဒီဇိုင္းစဆြဲကတည္းက အမွားေျကာင့္လည္း ျဖစ္ေပၚႏိုင္ပါတယ္။

ဒီဇိုင္းအမွားေျကာင့္ အစိတ္အပိုင္းမ်ားျကားထဲမွာ မလိုအပ္တဲ့ ဆက္သြယ္ေရးလမ္းေျကာင္းမ်ားစြာ ေပၚေပါက္ေစႏုိင္ပါတယ္။

တိက်တဲ့အေျကာင္းျပခ်က္မရွိပဲ data စုစည္းေပးရတဲ့ကုဒ္ေတြ မ်ားျပားလာႏိုင္ပါတယ္။

ေနာက္ထပ္ data ျဖတ္သန္းမွဳေတြပိုျဖစ္လာေလေလ ခ်ိဳ႕ယြင္းတဲ့လမ္းေျကာင္းကိုေရာက္ရွိဖို႕ ျဖစ္ႏုိင္ေခ်ပိုမ်ားလာေလေလပါပဲ။

 

အခ်ိန္ျကာလာတာနဲ႕အမွ် ကုဒ္အစိတ္အပိုင္းေတြထပ္လာၿပီး သူတို႕ရဲ့နဂိုအသုံးကေန လုံး၀ျခားနားတဲ့အသုံးသို႕ ေျပာင္းလဲလာၿပီး မသုံးတဲ့ကုဒ္အပိုင္းေတြ ပိုမ်ားလာႏိုင္ပါတယ္။

ဒီလိုျဖစ္လာရင္ မသုံးတဲ့အပိုင္းေတြ ဖ်က္ပစ္ဖို႕ မေျကာက္ရြ႕ံပါနဲ႕။

လိုအပ္လာရင္ အိုေဟာင္းေနတဲ့အစိတ္အပုိင္းကို ပိုရွင္းလင္းတဲ့အသစ္နဲ႕ ေျပာင္းပစ္လိုက္ပါ။

 

ဒီဇိုင္းစဆြဲကတည္းက အဆင္သင့္ယူသုံးႏုိင္တဲ့ library ေတြက သင့္ပရိုဂရမ္းမင္းအခက္အခဲကို ေျဖရွင္းေပးႏုိင္လား ထည့္သြင္းစဥ္းစားထားပါ။

ဒီလို library ေတြကို အသုံးခ်ျခင္းျဖင့္ မလိုအပ္တဲ့ကုဒ္ေပါင္းမ်ားစြာ သင့္ဘာသင္ေရးဖို႕လိုတာမ်ိဳးကို ေရွာင္ရွားႏိုင္မွာပါ။

အပိုဆုအေနနဲ႕ လူသုံးမ်ားေက်ာ္ျကားတဲ့ library ေတြက ပိုအျကမ္းခံ ပိုအသစ္ထပ္ထည့္ရလြယ္ ပိုအသုံးျပုလို႕ေကာင္းႏုိင္ပါတယ္။

 

Whitespace

မေျကာက္ပါနဲ႕။ က်ဳပ္က whitespace ( spaces ေတြ tabs ေတြ newlines ေတြ) ကို တိုက္ခိုက္ဖို႕ မဟုတ္ပါဘူး။

Whitespace က ေကာင္းပါတယ္။ အသုံးျပဳဖို႕ မေျကာက္ပါနဲ႕။

ကဗ်ာဖြဲ႕ရင္ အျဖတ္အေတာက္ညီသလို Whitespace ကို ခ်င့္ခ်င့္ခ်ိန္ခ်ိန္အသုံးျပဳရင္ က်ဳပ္တို႕ကုဒ္ေတြ ပိုျကည့္ေကာင္းမွာပါ။

Whitespace သုံးဖို႕ မလိုအပ္ဘူးလို႕ ဆိုလိုတာမဟုတ္ပါ။ ဒါေပမယ့္ တခါတေလ အလြန္အျကဴးအသုံးျပဳရင္ ဥပမာ function ေတြျကားထဲမွာ အေျကာင္းႏွစ္ဆယ္ေလာက္ newlines စာေျကာင္းလြတ္ေတြျခားေနရင္ သိပ္လြန္သြားၿပီ။

 

ဒီလိုပါပဲ လက္သည္းကြင္းေတြသုံးတာလည္း သတိထားပါ။ လိုအပ္လို႕သုံးရင္ logic က ဘာကိုဆိုလိုလည္းဆိုတာ ပိုမိုရွင္းလင္းေစႏုိင္ေပမယ့္ သုံးတာမ်ားလြန္းရင္ မလိုအပ္ပဲ ပိုရွဳပ္ေထြးေစႏုိင္ပါတယ္။

 

ဒီေတာ့ က်ဳပ္တို႕ဘာလုပ္သင့္ပါသလဲ

မွ်မွ်တတေျပာရရင္ ဘယ္သူမွပုံပန္းမက်မလိုအပ္တဲ့ကုဒ္ေတြ မေရးခ်င္ပါဘူး။

လူအခ်ိဳ႕ပဲ သဘာ၀မက်တဲ့ ထပ္ေနတဲ့ အက်ိဳးမရွိတဲ့ကုဒ္ေတြကို တမင္တကာေရးခ်င္ျကပါတယ္။ (သို႕ေပမယ့္ ကုဒ္ေကာင္းေကာင္းေရးဖို႕ အားမစိုက္ပဲ အလြယ္လမ္းပဲလိုက္ေနတဲ့ အပ်င္းထူတဲ့ ပရိုဂရမ္မာေတြလည္း ရွိျကတယ္)

မ်ားေသာအားျဖင့္ ဒီလိုကုဒ္ျပသနာေတြကို အေတြ႕ရမ်ားတာက ကုဒ္အိုကုဒ္ေဟာင္းေတြမွာပါ။ ဒီကုဒ္အိုကုဒ္ေဟာင္းေတြကို ႏွစ္ကာလမ်ားစြာ လူေပါင္းမ်ားစြာက ျပင္ျက ထပ္ထည့္ျက စမ္းသပ္ျကနဲ႕ ကုဒ္ျပသနာေတြေပၚေပါက္လာရတာပါ။

 

ဒီေတာ့ က်ဳပ္တို႕ဘာလုပ္သင့္လဲ။

က်ဳပ္တို႕ တာ၀န္သိရပါမယ္။

မလိုအပ္တဲ့ကုဒ္ေတြကို မေရးပါနဲ႕။

တကယ္လို႕ သင္က ကုဒ္အိုကုဒ္ေဟာင္းေတြနဲ႕ အလုပ္လုပ္ရမယ္ဆို ဒီမွာေဖာ္ျပခဲ့တဲ့ သတိေပးခ်က္ေတြကို အမွတ္ရပါ။

ေတာ္လွန္ေရးစပါ။

Whitespace ေတြကို ျပန္လည္သိမ္းယူပါ။

ရွုပ္ပြထေအာင္ မေရးပါနဲ႕။

ရွင္းလင္းစြာေရးပါ။

တရားမွ်တခ်ိန္ခြင္လွ်ာညီမွ်ပါေစ။

 

၀က္ေတြက မစင္ျကားမွာပဲေနတယ္။

ပရိုဂရမ္မာေတြက ေနဖို႕မလိုပါဘူး။

ကိစၥျပီးလွ်င္ေရေလာင္းပါ။

ကုဒ္အစအနေတြသင္ထိေတြ႕လိုက္ၿပီဆိုတာနဲ႕ မလိုတာေတြဖယ္ရွားပစ္ပါ။

 

မွတ္ရန္။ ။ သင့္ရဲ့ကုဒ္ေတြကို သင္မေတြ႕ခင္ကထက္ ပိုေကာင္းေအာင္ လုပ္ထားခဲ့ပါ။ ပိုတာေတြ မလိုတာေတြကို သင္ေတြ႕တာနဲ႕ ဖယ္ရွားပစ္ပါ။

 

ကုဒ္ေတြ မလိုတာေတြဖယ္ပစ္တာစတဲ့ ကုဒ္သန္႕ရွင္းေရးလုပ္တာကို တျခားလုပ္ငန္းပိုင္းကုဒ္ျပင္တာေတြနဲ႕ မေရာပဲလုပ္ဖို႕လိုတယ္ဆိုတဲ့ အျကံေပးခ်က္ကို ရယူပါ။

ဒီလိုလုပ္ျခင္းျဖင့္ သင့္ရဲ့ source control system ကိုလည္း ပိုၿပီး ရွင္းလင္းေစမွာပါ။

ကုဒ္ရွင္းတာနဲ႕ လုပ္ငန္းပိုင္းကုဒ္ျပင္တာကို ေရာလိုက္ရင္ နားလည္ဖို႕ ခက္ခဲလာမွာပါ။

တကယ္လို႕ ခ်ိဳ႕ယြင္းခ်က္ (bugs) ေတြေပၚလာခဲ့ရင္ သင့္ရဲ့ကုဒ္ရွင္းလင္းေရးေျကာင့္လား လုပ္ငန္းပိုင္းကုဒ္ျပင္ဆင္မွဳ ေျကာင့္လား ေ၀ခြဲမရပဲ လုပ္ရကိုင္ရခက္ခဲနိုင္ပါတယ္။

 

နိဂုံးခ်ုပ္

ေဆာ့၀ဲတခုဘာလုပ္ငန္းေဆာင္တာေတြ လုပ္ေဆာင္ႏုိင္တယ္ဆိုတာ ကုဒ္ဘယ္ႏွစ္ေျကာင္းပါလဲ သင့္စနစ္ထဲမွာ ကုဒ္အစိတ္အပိုင္းဘယ္ႏွစ္ခုထိပါ၀င္သလဲဆိုတာေတြနဲ႕ မဆက္စပ္ပါဘူး။

ကုဒ္အေျကာင္းေရမ်ားမ်ားေရးတုိင္း ပိုုလုပ္ႏုိ္င္တဲ့ေဆာ့၀ဲလို႕ ေျပာရခက္ပါတယ္။

ဒါေျကာင့္ မလိုရင္ မေရးပါနဲ႕။

နည္းနည္းနဲ႕ေကာင္းေကာင္းေရးၿပီး တျခားေပ်ာ္စရာလုပ္ေဆာင္မွဳကိုသာ ရွာေဖြပါေလ။

 

ေမးခြန္းမ်ား

၁. သင္ေဖာ္ျပခ်က္ေတြကို လိုရင္းတိုရွင္းကုဒ္နဲ႕ေရးႏုိင္ပါသလား။ သင့္လုိတိုရွင္းကုဒ္က နားလည္ဖို႕ ပိုခက္ေနလား။

၂. သုံးခုနည္းနဲ႕ ေရးလို႕ ပိုရွင္းလာလား ပိုရွဳပ္သြားလား။ ဘာလို႕လဲ။

၃. က်ဳပ္တို႕ cut-and-paste တေနရာက တေနရာကို ကူးေရးေနတာမ်ိဳး ေရွာင္သင့္ပါတယ္။ function တခုအေနနဲ႕ ခြဲထုတ္မေရးႏုိင္ရေအာင္ ကုဒ္ေတြက ဘယ္ေလာက္ကြဲျပားျခားနားမွဳေတြ ရွိေနပါသလဲ။

၄. ေသဆုံးေနတဲ့ကုဒ္ေတြကို သင္ဘယ္လိုေတြ႕ရွိႏုိင္ပါသလဲ။

၅. တခ်ိဳ႕ကုဒ္စံႏွဳန္းသတ္မွတ္ခ်က္ေတြက မွတ္ခ်က္မ်ားမ်ားပါမွ ေကာင္းတဲ့စံသတ္မွတ္ေလ့ရွိတယ္။ ဒါတကယ္အသုံး၀င္ရဲ့လား။ ဒါမွမဟုတ္ ဒီလိုစံမ်ိဳးလိုက္နာတာဟာ မလိုအပ္ပဲ မွတ္ခ်က္ေတြ မ်ားျပားလာတာမ်ိဳးျဖစ္ေစႏိုင္ပါသလား။

 


Unicode

အပိုင်း ၁ သင်ခန်းစာ ၃  ကုဒ်လျှော့ရေးပါ

“အနည်းဆုံးသုံးစွဲခြင်းဖြင့် အရာရာပြည့်စုံလုံလောက်ပါစေ” – Jules Verne

 

ဒီခေတ်ကြီးမှာ ကုဒ်တွေအရမ်းများလွန်းနေတယ် ဒါဟာ ၀မ်းနည်းစရာကောင်းပေမဲ့ မှန်ကန်တဲ့အကြောင်းအချက်ပါ။

ကျုပ်ကားအင်ဂျင်ကို ကွန်ပျူတာနဲ့ထိန်းချုပ်ထားတယ်ဆိုတဲ့အချက်ကို ကျုပ်လက်ခံနိုင်တယ်။

မိုက်ခရိုဝေ့မီးဖိုထဲမှာ ဆော့ဝဲက ချက်တဲ့အလုပ်လုပ်တယ်ဆိုတာလည်း သိသာပါတယ်။

ဇီဝဗေဒနည်းနဲ့ပြုပြင်ထားတဲ့ သခွားသီးထဲမှာ မိုက်ခရိုကွန်ထရိုလာ တခုမြှုပ်ထားတယ်ဆိုရင်တောင် ကျုပ်မအံ့သြဘူး။

ကောင်းပါပြီလေ ဒါတွေကို ကျုပ်ရေးကြီးခွင်ကျယ်ထည့်ပြောနေတာမဟုတ်ပါဘူး။

ကျုပ်စိတ်ပူမိတာက မလိုအပ်ပဲများပြားနေတဲ့ ကုဒ်တွေကိုပါ။

 

မလိုအပ်ပဲ ကုဒ်တွေအလွန်များနေတာ တွေ့ရတယ်။

ပေါင်းပင်တွေလိုပဲ ဒီဆိုးရွားလှတဲ့ကုဒ်စာကြောင်းများစွာဟာ

သိမ်းဆည်းစရာအဖိုးတန် (storage bytes) နေရာတွေကို ပိတ်ဆို့စေနိုင်တယ်။

Source control စနစ် ရဲ့ မှတ်တမ်းမှတ်ရာတွေကို ပိုရှုပ်ထွေးစေနိုင်တယ်။

ဆော့ဝဲတည်ဆောက်ခြင်းလမ်းကြောင်းမှာလည်း အဟန့်အတားဖြစ်စေနိုင်တယ်။

အဖိုးတန်ကုဒ်သိမ်းလို့ရမယ့်နေရာတွေကိုလည်း ဖြုန်းပစ်တယ်။

သူတို့နားက ကောင်းတဲ့ကုဒ်တွေကိုလည်း ပိတ်ဆို့စေနိုင်တယ်။

 

ဘာကြောင့်များ မလိုအပ်ပဲ ကုဒ်တွေ များပြားနေရပါလိမ့်။

 

တချို့လူတွေက သူတို့ရဲ့ကိုယ်ပိုင်အသံကို ပြန်ကြားချင်ကြတယ်။

သင်သူတို့နဲ့ဆုံလည်း သူတို့က ပါးစပ်ပေါက်ပိတ်မသွားဘူး။

ဒီလူတွေဟာ ပါတီတွေမှာ သင်မဆုံချင်တဲ့လူတွေပေါ့။

တချို့လူတွေကြတော့ သူတို့ကုဒ်ကို သူတို့အလွန်နှစ်သက်ကြပြန်တယ်။

ဒီတော့သူတို့က ကုဒ်များစွာမလိုအပ်ပဲ ရေးကြတယ်။

 

နောက်ဖြစ်နိုင်တာကတော့ သူတို့က တစ်နေ့ကုဒ်အကြောင်းရေ ထောင်နဲ့ချီရေးမှ တိုးတက်တယ်လို့ အကဲဖြတ်တတ်တဲ့ အယူလွဲမန်နေဂျာလက်အောက်မှာ လုပ်ရတဲ့ ပရိုဂရမ်မာတွေဖြစ်နိုင်လို့ပါပဲ။

 

ကုဒ်တွေအများကြီးရေးတယ်ဆိုတာနဲ့ပဲ သင်ဆော့ဝဲတွေအများကြီးအလုပ်လုပ်တယ်လို့ ပြော၍မရပါ။

တကယ်တော့ တချို့ကုဒ်တွေက သင့်ဆော့ဝဲကို မကောင်းတဲ့အကျိုးကျေးဇူး သက်ရောက်စေနိုင်တယ်။

ဆော့ဝဲသွားမယ့်လမ်းကြောင်းကို ပိတ်စေနိုင်တယ်။

အမှားတွေဖြစ်စေနိုင်တယ်။

ဆော့ဝဲအရည်အသွေးကို နိမ့်ကျစေနိုင်တယ်။

 

မှတ်ရန် ။ ။ ကုဒ်လျှော့ရေးခြင်းဖြင့် ဆော့ဝဲပိုအလုပ်လုပ်နိုင်ပါတယ်။

 

ကျုပ်ရဲ့ဆော့ဝဲအရည်အသွေးမြှင့်တင်ခြင်းတွေထဲက အကောင်းဆုံးလုပ်ဆောင်မှုတခုကတော့ ကုဒ်တွေကို ဖယ်ရှားခြင်းဖြစ်ပါတယ်။

ကျုပ်ကောင်းကောင်းမှတ်မိနေတာတခုကတော့ ဆော့ဝဲစနစ်တခုကနေ ကုဒ်အကြောင်းရေ ထောင်ပေါင်းများစွာကို ကုဒ်ဆယ်ကြောင်းလောက်နဲ့ အစားထိုးလိုက်နိုင်တာပါပဲ။

ကျုပ်အတွက်တော့ ကျေနပ်စရာကောင်းတဲ့ခံစားချက်ပါပဲ။

သင်တို့လည်း တခါတလေစမ်းကြည့်သင့်တယ်။

ဘာကြောင့် သတိထားသင့်လဲ

ဘာကြောင့် ကုဒ်တွေများလွန်းတာဟာ စိတ်အနှောင့်အယှက်ဖြစ်ယုံမကပဲ ဆိုးရွားလှတာလဲ။

မလိုအပ်တဲ့ကုဒ်တွေက အဆိုးတကာ့အဆိုးဆုံးဖြစ်ရတဲ့အကြောင်းများစွာ ရှိပါတယ်။

ဒီထဲကတချို့ကတော့

ကုဒ်အသစ်တကြောင်းရေးခြင်းဟာ လူ့အသက်တစ်ချောင်းစတင်မွေးဖွားလိုက်သလိုပါပဲ။ ဆော့ဝဲထုတ်ကုန်သစ်အဖြစ်မရောက်ရှိခင် ဆော့ဝဲလူ့အဖွဲ့အစည်းအတွက် အသုံးဝင်ပြီး အဖိုးတန်ဖြစ်လာအောင် ကလေးတစ်ယောက်ကို ပြုစုစောင့်ရှောက်သလို ဂရုစိုက်ပေးမှရပါမယ်။
သင့်ဆော့ဝဲစနစ်ရဲ့ ဘဝသက်တမ်းတလျှောက်မှာ ဒီကုဒ်တစ်ကြောင်းကို သင်ထိန်းသိမ်းပြုပြင်ဖို့ လိုအပ်လာပါလိမ့်မယ်။ ကုဒ်တကြောင်းအတွက် ပြင်စရိတ်နည်းနည်းကျပါလိမ့်မယ်။ သင်ကုဒ်များများရေးလေ ပြင်စရိတ်ပိုများလေပါပဲ။ ကုဒ်တကြောင်းက အချိန်ကြာကြာပိုအသက်ရှင်လေ သူ့အတွက်ထိန်းသိမ်းစရိတ်ပိုများလေပါပဲ။ ကျုပ်တို့ကို ဒေဝါလီခံရစေဖို့မဖြစ်ခင် မလိုအပ်တဲ့ကုဒ်တွေကို အဆုံးသတ်ပစ်ဖို့လိုအပ်တာ ရှင်းပါတယ်။

ကုဒ်တွေပိုများလာလေလေ ပိုဖတ်ရလေလေ ပိုနားလည်စရာများလာလေလေပါပဲ။ ဒါနဲ့ပဲ ကျုပ်တို့ရဲ့ ပရိုဂရမ်ကို နားလည်သဘောပေါက်ဖို့ ပိုခက်လာရော။ မလိုအပ်တဲ့ကုဒ်အပို်တွေဟာ function တခုရဲ့ ရည်ရွယ်ချက်ကို ဖုံးကွယ်ပစ်နိုင်တယ်။ ဆင်တူသလိုရှိနေတဲ့ကုဒ်တွေမှာ ငယ်ပေမယ့် အရေးကြီးတဲ့ကွဲပြားချက်တွေကိုလည်း ဖုံးကွယ်ပစ်နိုင်တယ်။
ကုဒ်ပိုများလာလေလေ ပြင်ဖို့လိုလာရင် ပြင်စရာပိုများလာလေ့ရှိတာမို့ ပရိုဂရမ်ကို ပြင်ဖို့ ပိုခက်ခဲလာပါလိမ့်မယ်။
ကုဒ်တွေက ချို့ယွင်းချက်(bugs) တွေကို ကွယ်ဝှက်ထားပေးနိုင်တယ်။ ကုဒ်တွေပိုများလာလေလေ ချို့ယွင်းချက်တွေ ပုန်းခိုစရာနေရာပိုများလာလေလေပါပဲ။
ချွတ်စွပ်တူတဲ့ကုဒ်တွေက ပိုလို့တောင် ဒုက္ခပေးနိုင်ပါတယ်။ ကော်ပီကူးထားတဲ့တစ်နေရာက ကုဒ်တွေရဲ့ချို့ယွင်းချက်ကို သင်ပြုပြင်လိုက်ပေမယ့် သင်မသိပဲ ထပ်ရှိနေသေးတဲ့ နောက်ထပ်၃၂ နေရာလောက်က လုံးဝတူညီတဲ့ချို့ယွင်းချက်တွေကို ရှိနေပါလိမ့်မယ်။

 

မလိုအပ်တဲ့ကုဒ်တွေဟာ ဉာဏ်နီဉာဏ်နက်တတ်ပါတယ်။ မသုံးပဲထားတဲ့ အစိတ်အပိုင်း(components) တွေ၊ အသက်မဲ့နေတဲ့ကုဒ်တွေ၊ အဓိပါ္ပယ်မရှိတဲ့ မှတ်ချက်(comments) တွေ၊ မလိုအပ်ပဲ စကားလုံးတွေများပြားလွန်းတာတွေ စသဖြင့် မလိုအပ်တဲ့ကုဒ်ပိုတွေဟာ အသွင်မျိုးစုံနဲ့ရှိတတ်ပါတယ်။

 

ပျာယာခတ် logic(တွေးခေါ်ခြင်း)များ

ရည်ရွယ်ချက်မဲ့နေတဲ့ကုဒ်တွေကို ရိုးရိုးရှင်းရှင်းဥပမာပေးရရင် မလိုအပ်တဲ့ မှန်မမှန်စစ်ဆေးခြင်းတွေပါပဲ။

ပျာယာခတ်အောင်ရေးထားတဲ့ logic တွေဟာ ပျာယာခတ်နေတဲ့စိတ်ကို ကိုယ်စားပြုတယ်။

Logic တည်ဆောက်ပုံတွေကို သေချာနားမလည်လို့လည်း ဖြစ်နိုင်တယ်။

 

01

လို့ရေးထားတဲ့ဟာကို

 

02

လို့ လိုတိုရှင်းရေးနိုင်ပါတယ်။

 

ဒီလိုရေးလိုက်တော့ ပိုပြီး ကျစ်လစ်တဲ့အပြင် ပိုဖတ်ရလွယ်လို့ နားလည်ဖို့ပိုလွယ်ကူလာတယ်။

အင်္ဂလိပ်စာကြောင်းတကြောင်းနဲ့တူလို့ ဖတ်ရတဲ့လူတွေကိုလည်း ကူညီရာရောက်တယ်။

Compiler ကလည်း ဒီလိုရေးလို့ စိတ်လုံးဝမဆိုးဘူးဆိုတာ သင်သိပါသလား။

 

ထို့နည်းတူစွာ စကားလုံးဖောင်းပွနေတဲ့ အောက်က စစ်ဆေးချက်ကို

 

03

အောက်ကအတိုင်းပြောင်းရေးလိုက်ရင် ပိုကောင်းမှာပါ

04

ဒီဥပမာတွေက ရိုးရိုးရှင်းရှင်းဖော်ပြထားတာပါ။

အပြင်လောကမှာတော့ ဒီထက်ပိုရှုပ်ထွေးတဲ့ စစ်ဆေးခြင်းတည်ဆောက်ပုံတွေကို ကျုပ်တို့ မြင်တွေ့ဘူးမှာပါ။

ရိုးရိုးရှင်းရှင်းလေးကို ရှုပ်ထွေးအောင်လုပ်ပစ်နိုင်တဲ့ ပရိုဂရမ်မာတစ်ယောက်ရဲ့ အစွမ်းအစကို လျှော့မတွက်ပါနဲ့။

တကယ့်အပြင်လောကမှာ ဒီထက်ပိုရှုပ်ထွေးနက်နဲတာတွေက ဒီလိုပုံစံမျိုးလေးတွေ

 

05

ဒါကို တကြောင်းတည်းနဲ့ပြတ်အောင် ဒီလိုရေးလို့ရပါတယ်

06

ဝေ့လည်ကြောင်ပတ်မလုပ်ပဲနဲ့ ပြောချင်တာကို တိုတိုတုတ်တုတ်နဲ့ ရှင်းရှင်းလင်းလင်းပြောပါ။

သင်သုံးတဲ့ ပရိုဂရမ်ဘာသာစကားဘယ်လိုအလုပ်လုပ်သလဲသိအောင် လုပ်ဖို့ မရှက်ပါနဲ့။

ပရိုဂရမ်မှာရေးထားတဲ့ဖော်ပြချက် ( expression ) တွေဟာ ဘယ်လိုအစဉ်အတိုင်းအလုပ်လုပ်တယ်ဆိုတာ သိအောင်လုပ်ထားပြီး အကျိုးရှိရှိအသုံးချခြင်းဖြင့် မလိုအပ်တဲ့ logic တွေ အများကြီးကို လျှော့ချပေးနိုင်တယ်။

ဥပမာအားဖြင့်

 

07

လို့ရေးထားတာကို

08

ရိုးရှင်းစွာ ပြန်ပြင်ရေးနိုင်ပါတယ်။

 

မှတ်ရန်။။ ကုဒ်တွေကို တိုတိုနဲ့ ရှင်းရှင်းရေးသားဖော်ပြပါ။ မလိုအပ်ပဲ ကွေ့ကောက်ဝေ့ဝိုက် ရေးသားခြင်းမျိုး ရှောင်ကြဉ်ပါ။

 

ထပ်နေတဲ့ကုဒ်များ

မလိုအပ်ပဲကုဒ်တွေထပ်နေတာ ဆိုးလှပါတယ်။

ကုဒ်တွေကို cut-and-paste လုပ်ပြီး ပရိုဂရမ်ရေးသားမှုမျိုး ၊ ထပ်ကာထပ်ကာရေးမိနေတဲ့ကုဒ်တွေကို function တခုခွဲထုတ်ပြီးရေးလိုက်ဖို့ အပျင်းထူတဲ့ ပရိုဂရမ်မာတွေက တစ်နေရာက တစ်နေရာကို စာအားလုံး copy ကူးပြီး ရေးသားမှုမျိုးကနေ ကုဒ်ထပ်တာတွေ အများဆုံးတွေ့ရတတ်ပါတယ်။

နည်းနည်းလေးပြင်ပြီး တခြားနေရာကို ကူးယူရေးသားခြင်းက စည်းကမ်းပိုဖောက်ဖျက်ပါတယ်။

 

ကုဒ်တွေကို သင်ကူးယူပြီး ရေးလိုက်တဲ့အခါ ထပ်နေတဲ့ကုဒ်တည်ဆောက်ပုံကိုပါကူးတာဖြစ်တဲ့အတွက် သင်ဟာ ရှိပြီးသား ချို့ယွင်းချက်(bugs) တွေကို ကူးယူမိပြီးသားဖြစ်သွားပါတယ်။

တနေရာက ချို့ယွင်းချက်တွေကို သင်ပြုပြင်လိုက်ပေမယ့် နောက်တနေ့မှာ နောက်တနေရာက ချွပ်စွပ်တူတဲ့ချို့ယွင်းချက်တွေက သင့်ကို ဒုက္ခပေးနေဦးမှာပါ။

နေရာတိုင်းမှာထပ်ကာထပ်ကာပါနေမယ့်ကုဒ်တွေကို function တခုအနေနဲ့ ထုတ်ရေးပါ။

ဆင်တူနေတဲ့အပိုဒ်များပြီး နည်းနည်းလေးသာ ကွဲပြားမှုရှိခဲ့ရင် ကွဲပြားတာတွေကို function ထဲသို့ parameter တခုပေးပို့ပြီး ရေးသားပါ။

 

မှတ်ရန်။ ။ ကုဒ်တွေကို အပိုဒ်လိုက် ကူးမရေးပါနဲ့။ ဘုံ function တခုအဖြစ် ထုတ်ရေးပါ။ ကွဲပြားမှုလေးတွေအတွက် parameter သုံးပြီး ဖော်ပြရေးသားပါ။

 

DRY နည်းလို့ လူသိများတဲ့ နည်းတခုရှိပါတယ် ။ အရှည်က Don’t Repeat Yourself ပါ။ ထပ်ကာတလဲမလုပ်ပါနဲ့။ မလိုတာတွေမပါတဲ့အပြင် မထပ်တဲ့ကုဒ်မျိုးကို ရည်ရွယ်ရေးသားပါ။ ဆင်တူတဲ့ကုဒ်တွေကို မျှဝေသုံးလို့ရတဲ့ function တခုအဖြစ် ရေးသားခြင်းအားဖြင့် ကုဒ်တွေဟာ ပိုမိုချိတ်ဆက်လာတာကို သတိထားပါ။

မျှဝေသုံးရတဲ့ တနေရာထဲကို မှီခိုရသလိုဖြစ်လာပြီး ထိုနေရာကို ပြင်လိုက်ရင် တခြားခေါ်သုံးထားတဲ့နေရာတွေကိုပါ ပြင်ဆင်ဖို့ လိုအပ်လာမှာဖြစ်ပါတယ်။

ပုံမှန်ကတော့ ဒီလိုပြင်ဆင်ရတာ အဆင်ပြေပေမယ့် အမြဲတမ်းတော့ ဒီလိုဖြစ်ချင်မှာမဟုတ်ပါဘူး ရေရှည်မှာ ကူးရေးတာထက် ပိုပြသနာတက်နိုင်လို့ တာဝန်သိသိ ရေးသားပါ။

 

ကုဒ်တွေထပ်နေရတာ အားလုံးဟာ တမင်တကာလုပ်လို့ ပရိုဂရမ်မာတွေရဲ့အမှားကြောင့်မို့လို့ပဲ မဟုတ်ပါဘူး။

မရည်ရွယ်ပဲ ထပ်သွားတာတွေလည်း ရှိတတ်ပါတယ်။

သူများရေးပြီးသားရှိတာကိုမသိပဲ ပြန်တီထွင်နေတာမျိုးလည်း ရှိတတ်ပါတယ်။

အဆင်သင့်အသုံးချနိုင်တဲ့ third party library တခုရှိတာကို မသိပါပဲ function အသစ်တခုတည်ဆောက်ရေးသားနေတာမျိုးကြောင့်လည်း ဖြစ်နို်င်ပါတယ်။

ဒါက တကယ်ဆိုးပါတယ် ဘာလို့လဲဆိုတော့ ရှိပြီးသား library တခုက ပိုမှန်နို်င်ပြီး ပိုစမ်းထားမျိုးဖြစ်နိုင်လို့ပါ။

အများသုံး library တွေကို သုံးခြင်းအားဖြင့် သင့်ရဲ့အားထုတ်မှုတွေကို သက်သာစေမယ့်အပြင် ဖြစ်နိုင်ချေရှိတဲ့အမှားတွေကို ရှောင်ရှားနို်င်ပါတယ်။

 

အနုစိတ်ထပ်နေတာမျိုးလည်း ရှိနိုင်ပါတယ်။ ဥပမာ

09

if တခုတည်းနဲ့စစ်ပြီး သုံးကြောင်းလုံးကို အတွင်းထဲမှာထားလိုက်ခြင်းဖြင့် ပိုသပ်ရပ်စွာရေးနိုင်ပါတယ်။

 

loop များစွာပတ်နေတာကိုလည်း loop တခုထဲသုံးပြီး ပတ်နိုင်ပါတယ်။ ဥပမာ

10

ရေးတာမျိုးကို

 

11

အဖြစ်ရေးတာက ပိုဖတ်ရလွယ်ပြီး ပိုနားလည်ဖို့လွယ်တဲ့အပြင် loop တကြိမ်ပတ်ရသက်သာသွားလို့ ပိုမြန်လာပါတယ်။

ဒီလိုထပ်နေတဲ့ စစ်ဆေးမှုမျိုးကို သေချာစဉ်းစားကြည့်ပါ။

 

12

 

သင်က ဒီလိုမျိုးဖြစ်အောင် တမင်တကာရေးမှာမဟုတ်ပါဘူး။ ဒါပေမဲ့ ကြိိမ်ဖန်များစွာ ပြုပြင်ထိန်းသိမ်းမှုလုပ်ထားတဲ့ ကုဒ်တွေဟာ ဒီလိုပုံစံမျိုး အဆုံးသတ်သွားလေ့ရှိပါတယ်။

 

မှတ်ရန်။ ။ ထပ်နေတာတွေတွေ့ရင် သင်ဖယ်ရှားလိုက်ပါ။

 

ကျုပ်မကြာသေးခင်ကပဲ device driver တခုရေးထားတာကို အမှားရှာပေးတုန်း ကုဒ်ထဲမှာ အရေးကြီးတဲ့ loop နှစ်ခုကို တွေ့ရပါတယ်။

သေချာစစ်ကြည့်လိုက်တော့ loop နှစ်ခုဟာ လုံးဝနည်းပါတူနေပြီး သူတို့ထဲကို ပေးပို့လိုက်တဲ့ data type ပေါ်မူတည်ပြီး အနည်းငယ်မျှသာကွဲပြားခြားနားတာ တွေ့ရပါတယ်။

ကုဒ်အကြောင်းရေပေါင်း သုံးရာလောက်ရှိတဲ့ loop ထဲမှာ ဒီလိုထပ်နေတာကို သတိထားမိဖို့ မလွယ်လှပါဘူး။

တကယ်ကို ကွေ့ကောက် ရှုပ်ထွေးလှပါတယ်။

Loop တခုချင်းဆီမှာ မတူတဲ့ ချို့ယွင်းချက် (bugs) တွေပြင်ထားလို့ ကုဒ်တွေက အလွှာလိုက်ကွာသလို ကွာလာပြီး အင်မတန်ခန့်မှန်းရခက်လာပါတယ်။

နည်းနည်းလောက်အားစိုက်ပြီး Loop နှစ်ခုကို တခုထဲဖြစ်အောင် ပေါင်းရေးလိုက်တာ ပြသနာတဝက်လောက်လျော့ပါးသွားစေပြီး ကျုပ်အတွက်လည်း တနေရာထဲကို အာရုံစိုက်ပြီး အမှားရှာနိုင်လာပါတယ်။

 

သေဆုံးသွားတဲ့ကုဒ်တွေ

သင်မပြုပြင်ပဲထားရင် သင့်ကုဒ်တွေဟာ ပုပ်ဆွေးသွားနိုင်ပါတယ်။ ကုဒ်တွေ သေတောင်သေသွားနိုင်တယ်။ သေနေတဲ့ကုဒ်ဆိုတာ ဘယ်တော့မှခေါ်မသုံးတဲ့ကုဒ် ပရိုဂရမ်က ဘယ်တော့မှ မရောက်ရှိနိုင်တဲ့ကုဒ်တွေပါ။ သူတို့မှာ အသက်မရှိတော့ဘူး။ သင့်ကုဒ်ကို အသက်ရှင်အောင်လုပ်ပါ။

အောက်က ဥပမာတွေက သေဆုံးသွားတဲ့ကုဒ်တွေပါ။ အမှတ်တမဲ့ကြည့်ယုံနဲ့သတိထားမိမှာမဟုတ်ပါ။

 

13

နောက်ထပ်ဥပမာတခုက

 

14

တခြားသေဆုံးနေတဲ့ကုဒ်တွေကတော့

ဘယ်တော့မှခေါ်မသုံးတဲ့ function တွေ
ကြေငြာထားပြီး ဘယ်သောအခါမှ ခေါ်မသုံးတဲ့ variable တွေ
Function ထဲကို parameter တခုအဖြစ်ပို့ပေးလိုက်ပေမယ့် အဲ့ parameter ကို ဘယ်တော့မှ ခေါ်မသုံးမိတာမျိုးဖြစ်သွားတဲ့ parameter တွေ
ကြေငြာထားပေမယ့် ဘယ်တော့မှ ခေါ်မသုံးတဲ့ Enums, structs, classes, or interfaces တွေ

 

မှတ်ချက်များ (Comments)

စိတ်မကောင်းစရာကတော့ ဒီကမ္ဘာကြီးက ဆိုးရွားတဲ့ မှတ်ချက်တွေနဲ့ ပဟေဠိဆန်နေကြတာပါ။

ကုဒ် editor တခုထဲမှာ မှတ်ချက်တွေကို ကျော်ခွပြီးဖတ်နေရတာမျိုး သင်ကြုံဘူးမှာပါ။

တချို့ကုမ္ပဏီကြီးတွေရဲ့ ကုဒ်စံသတ်မှတ်ချက်က ဦးနှောက်ပျက်သွားစေလောက်မယ့် မှတ်ချက်တွေ သိန်းသန်းချီရေးပါမှ ကောင်းတယ်လို့ သတ်မှတ်တာမျိုးပါ။ တကယ်ကူညီရာမရောက်ပါဘူး။

ကောင်းတဲ့ကုဒ်က မှတ်ချက်တွေ တထမ်းတပိုးနဲ့ အထောက်အကူပြုတာမျိုး မလိုအပ်ပါဘူး။

ကောင်းတဲ့ကုဒ်ဆိုတာ ဘယ်လိုအလုပ်လုပ်ဆိုတာကို ရှင်းပြနေစရာမလိုပါဘူး။

Variable တွေ function တွေ class တွေရဲ့ နာမည်တွေကို သေချာဂရုတစိုက် နာမည်ပေးခြင်း ကုဒ်တွေရဲ့ တည်ဆောက်ပုံကောင်းအောင်လုပ်ထားခြင်းဖြင့် သင့်ကုဒ်က လုံးဝရှင်းရှင်းလင်းလင်းရှိမှာပါ။

အထက်စာကြောင်းပါ အကြောငး်အရာအချက်အလက်တွေကို မှတ်ချက်ထဲ ထပ်ထည့်ဖို့ မလိုအပ်ပါဘူး။

တခြားထပ်နေတာတွေလိုပဲ ကုဒ်မှာရှင်းနေတာတွေကို မှတ်ချက်ထဲမှာထပ်မံဖော်ပြခြင်းဖြင့် ကုဒ်ပြင်ရင် မှတ်ချက်ပါပြင်ရမှာကို မပြင်မိတဲ့အခါ ပိုအန္တရာယ်များပါတယ်။

အရူးထရေးတဲ့ မှတ်ချက်တွေဟာ သိမ်းရမယ့် bytes ပမာဏကိုပါ ဖြုန်းတီးရရောက်ပါတယ်။ အောက်ပါဥပမာကိုကြည့်ပါ (I တစ်တိုးတာ ပရိုဂရမ်မာတိုင်းသိပါတယ် မှတ်ချက်ပေးဖို့ မလိုအပ်ပါဘူး။)

15

ကို တစ်တိုးခြင်း

နောက်ဥပမာတခုကိုကြည့်ပါ။ (မှတ်ချက်ပေးဖို့မလိုအောင် ရှင်းပါတယ်)

 

16

တချို့ ရှုပ်ထွေးတဲ့ algorithm တွေ ကုဒ်အပိုင်းတွေ လောက်ပဲ မှတ်ချက်ပေးပြီး ရှင်းပြဖို့ လိုအပ်ပါတယ်။

သင်ရေးထားတဲ့ ကုဒ်အပိုင်းက မှတ်ချက်များစွာလိုအပ်ပြီဆိုရင် function တခုကို နာမည်ကောင်းမွန်စွာပေးပြီး ထို function အတွင်း လိုအပ်တဲ့ Logic တွေ ခွဲထုတ်ရေးသားဖြင်းဖြင့် ဖြေရှင်းကြည့်ပါ။

 

မှတ်ရန်။။ သင်ပေးလိုက်တဲ့မှတ်ချက်အကြောင်းတိုင်းက ကုဒ်ရဲ့ တန်ဖိုးကိုု မြင့်တက်ပါစေ။ ကုဒ်တွေက ဘယ်လိုအလုပ်လဲ ဘာလုပ်လဲ သူ့ဘာသူပြောပြနိုင်ပါတယ်။ မှတ်ချက်ကတော့ ဘာကြောင့်လုပ်ရလဲဆိုတာ ရှင်းပြသင့်ပါတယ်။ ကုဒ်ဖတ်တဲ့သူအတွက် တကယ်ကို ဘာကြောင့်လုပ်လဲ မရှင်းလင်းမှသာ မှတ်ချက်ထည့်သင့်ပါတယ်။

 

ကုဒ်အဟောင်းတွေကို တကယ်မဖယ်ရှားပဲ မှတ်ချက်အဖြစ်နဲ့ ပိတ်လိုက်တာမျိုး အတွေ့ရများပါတယ်။

အဲ့လိုမလုပ်ပါနဲ့။ ကုဒ်တွေကို တကယ်ဖျက်ပစ်ဖို့ မဝံ့ရဲတဲ့လူတယောက်က လုပ်သွားတာမျိုးပါ။ ဒါမှမဟုတ် ကုဒ်က ဘာလုပ်လဲကောင်းကောငး်နားမလည်တော့ နောင်များပြန်လိုမလားဆိုတဲ့ အတွေးနဲ့ လုပ်သွားတာမျိုးပါ။

ကုဒ်တွေ တကယ်မလိုတော့ရင် လုံးဝဖျက်ပစ်လိုက်ပါ။ သင်ပြန်လိုချင်လည်း သင့်ရဲ့ source control system (ကုဒ်တွေအပြောင်းအလဲများကို သိမ်းပေးသော စနစ်) ကနေပြန်ယူလို့ရသားပဲ။

 

မှတ်ရန်။ ။ ကုဒ်တွေကို မှတ်ချက်အဖြစ် ပိတ်လိုက်ပြီး ဖယ်ရှားတာမျိုး ရှောင်ကြဉ်ပါ။ ဖတ်မယ့်သူတွေကို ပိုရှုပ်စေနိုင်ပါတယ်။

 

ကုဒ်တွေ အရင်က ဘာလုပ်ခဲ့ဘူးတယ်ဆိုတဲ့မှတ်ချက်မျိုးမရေးပါနဲ့ ခုအရေးမပါတော့ဘူးလေ။

ကုဒ်တွေရဲ့ အဆုံးသတ်မှာ ဒါက အဆုံးလို့ မှတ်ချက်ရေးတာမျိုးမလုပ်ပါနဲ့ ကုဒ်တွေရဲ့ ဖွဲ့စည်းပုံကနေ ဒါကို အလွယ်တကူသိနိုင်ပါတယ်။

 

စကားလုံးဖောင်းပွခြင်း

ကုဒ်အတော်များများဟာ မလိုအပ်ပဲ စကားများကြပါတယ်။

အရိုးရှင်းဆုံးဥပမာတခုပေးရရင်

 

17

 

အတော်ကို စာလုံးတွေများပြီး ဘာဆိုလိုလည်း နားလည်ရခက်တာမျိုးပါ။ ဒါကို ဒီလိုလွယ်လွယ်လေးပြင်ရေးလို့ရပါတယ်။

 

18

သင်သုံးတဲ့ ပရိုဂရမ်းမင်းဘာသာစကားကသာ ခွင့်ပြုရင် သုံးခုနည်းကို သုံးဖို့ မတွန့်ဆုတ်ပါနဲ့။ သုံးခုနည်းဆိုတာ

( (၁။ ဘာဖြစ်လဲစစ်ဆေးမယ်) ? ၂။ မှန်တယ်ဆို ဒီအပိုင်းလုပ်မယ် : ၃။ မှားတယ်ဆိုဒီအပိုင်းလုပ်မယ် )

ဒီနည်းကို သုံးခြင်းဖြင့် သင့်ကုဒ်တွေ ရှုပ်ပွထနေတာကို လျော့နည်းသွားစေမှာပါ။

 

အောက်ကရေးထားတဲ့အရှုပ်ထုပ်ကို

19

ဒီလိုပြင်ရေးလိုက်ပါ

20

 

C Programming စတိုင်မျိုး (variable တွေကို ဟိုးထိပ်ဆုံးမှာပဲကြေညာထားဖို့ လိုအပ်တာမျိုး) ရေးသားပုံမျိုးဟာ အတိတ်မှာကျန်ခဲ့ပါပြီ။

ကမ္ဘာကြီးက ရွေ့လျားလာခဲ့ပြီးပါပြီ သင့်ကုဒ်တွေကိုလည်း ရွေ့လျားလိုက်ပါ။

အောက်ပါရေးသားခြင်းမျိုးရှောင်ကြဉ်ပါ။

21

 

Variable ကြေညာတာနဲ့ ခေါ်သုံးတာကို နည်းကပ်စွာထားရှိပါ။ ကုဒ်တွေကို နားလည်အောင်အားစိုက်ရတာ ပိုလျော့နည်းသွားပြီး ဘာမှမထည့်သွင်းရသေးတဲ့ variable မျိုးသုံးမိတဲ့အမှားမျိုးကိုလည်း လျော့နည်းစေမှာပါ။

တခါတရံ variable တွေကို အကျိုးမရှိကြေညာတတ်ပါတယ်။ ဥပမာ

 

22

 

ဒီလိုပြန်ရေးလိုက်ရင် စာလုံးပိုနည်းမယ့်အပြင် ပိုရှင်းလင်းစေမှာပါ။

23

ကုဒ်ဒီဇိုင်းအမှား

မလိုအပ်တဲ့ကုဒ်တွေတည်ရှိနေတာဟာ အောက်ခြေ ကုဒ်အလွှာအမှားတွေကြောင့် ထိန်းသိမ်းမှုအမှားကြောင့် ကြည့်ပဲမဟုတ်ပါဘူး

အပေါ်ယံဒီဇိုင်းစဆွဲကတည်းက အမှားကြောင့်လည်း ဖြစ်ပေါ်နိုင်ပါတယ်။

ဒီဇိုင်းအမှားကြောင့် အစိတ်အပိုင်းများကြားထဲမှာ မလိုအပ်တဲ့ ဆက်သွယ်ရေးလမ်းကြောင်းများစွာ ပေါ်ပေါက်စေနိုင်ပါတယ်။

တိကျတဲ့အကြောင်းပြချက်မရှိပဲ data စုစည်းပေးရတဲ့ကုဒ်တွေ များပြားလာနိုင်ပါတယ်။

နောက်ထပ် data ဖြတ်သန်းမှုတွေပိုဖြစ်လာလေလေ ချို့ယွင်းတဲ့လမ်းကြောင်းကိုရောက်ရှိဖို့ ဖြစ်နိုင်ချေပိုများလာလေလေပါပဲ။

 

အချိန်ကြာလာတာနဲ့အမျှ ကုဒ်အစိတ်အပိုင်းတွေထပ်လာပြီး သူတို့ရဲ့နဂိုအသုံးကနေ လုံးဝခြားနားတဲ့အသုံးသို့ ပြောင်းလဲလာပြီး မသုံးတဲ့ကုဒ်အပိုင်းတွေ ပိုများလာနိုင်ပါတယ်။

ဒီလိုဖြစ်လာရင် မသုံးတဲ့အပိုင်းတွေ ဖျက်ပစ်ဖို့ မကြောက်ရွ့ံပါနဲ့။

လိုအပ်လာရင် အိုဟောင်းနေတဲ့အစိတ်အပိုင်းကို ပိုရှင်းလင်းတဲ့အသစ်နဲ့ ပြောင်းပစ်လိုက်ပါ။

 

ဒီဇိုင်းစဆွဲကတည်းက အဆင်သင့်ယူသုံးနိုင်တဲ့ library တွေက သင့်ပရိုဂရမ်းမင်းအခက်အခဲကို ဖြေရှင်းပေးနိုင်လား ထည့်သွင်းစဉ်းစားထားပါ။

ဒီလို library တွေကို အသုံးချခြင်းဖြင့် မလိုအပ်တဲ့ကုဒ်ပေါင်းများစွာ သင့်ဘာသင်ရေးဖို့လိုတာမျိုးကို ရှောင်ရှားနိုင်မှာပါ။

အပိုဆုအနေနဲ့ လူသုံးများကျော်ကြားတဲ့ library တွေက ပိုအကြမ်းခံ ပိုအသစ်ထပ်ထည့်ရလွယ် ပိုအသုံးပြုလို့ကောင်းနိုင်ပါတယ်။

 

Whitespace

မကြောက်ပါနဲ့။ ကျုပ်က whitespace ( spaces တွေ tabs တွေ newlines တွေ) ကို တိုက်ခိုက်ဖို့ မဟုတ်ပါဘူး။

Whitespace က ကောင်းပါတယ်။ အသုံးပြုဖို့ မကြောက်ပါနဲ့။

ကဗျာဖွဲ့ရင် အဖြတ်အတောက်ညီသလို Whitespace ကို ချင့်ချင့်ချိန်ချိန်အသုံးပြုရင် ကျုပ်တို့ကုဒ်တွေ ပိုကြည့်ကောင်းမှာပါ။

Whitespace သုံးဖို့ မလိုအပ်ဘူးလို့ ဆိုလိုတာမဟုတ်ပါ။ ဒါပေမယ့် တခါတလေ အလွန်အကြူးအသုံးပြုရင် ဥပမာ function တွေကြားထဲမှာ အကြောင်းနှစ်ဆယ်လောက် newlines စာကြောင်းလွတ်တွေခြားနေရင် သိပ်လွန်သွားပြီ။

 

ဒီလိုပါပဲ လက်သည်းကွင်းတွေသုံးတာလည်း သတိထားပါ။ လိုအပ်လို့သုံးရင် logic က ဘာကိုဆိုလိုလည်းဆိုတာ ပိုမိုရှင်းလင်းစေနိုင်ပေမယ့် သုံးတာများလွန်းရင် မလိုအပ်ပဲ ပိုရှုပ်ထွေးစေနိုင်ပါတယ်။

 

ဒီတော့ ကျုပ်တို့ဘာလုပ်သင့်ပါသလဲ

မျှမျှတတပြောရရင် ဘယ်သူမှပုံပန်းမကျမလိုအပ်တဲ့ကုဒ်တွေ မရေးချင်ပါဘူး။

လူအချို့ပဲ သဘာဝမကျတဲ့ ထပ်နေတဲ့ အကျိုးမရှိတဲ့ကုဒ်တွေကို တမင်တကာရေးချင်ကြပါတယ်။ (သို့ပေမယ့် ကုဒ်ကောင်းကောင်းရေးဖို့ အားမစိုက်ပဲ အလွယ်လမ်းပဲလိုက်နေတဲ့ အပျင်းထူတဲ့ ပရိုဂရမ်မာတွေလည်း ရှိကြတယ်)

များသောအားဖြင့် ဒီလိုကုဒ်ပြသနာတွေကို အတွေ့ရများတာက ကုဒ်အိုကုဒ်ဟောင်းတွေမှာပါ။ ဒီကုဒ်အိုကုဒ်ဟောင်းတွေကို နှစ်ကာလများစွာ လူပေါင်းများစွာက ပြင်ကြ ထပ်ထည့်ကြ စမ်းသပ်ကြနဲ့ ကုဒ်ပြသနာတွေပေါ်ပေါက်လာရတာပါ။

 

ဒီတော့ ကျုပ်တို့ဘာလုပ်သင့်လဲ။

ကျုပ်တို့ တာဝန်သိရပါမယ်။

မလိုအပ်တဲ့ကုဒ်တွေကို မရေးပါနဲ့။

တကယ်လို့ သင်က ကုဒ်အိုကုဒ်ဟောင်းတွေနဲ့ အလုပ်လုပ်ရမယ်ဆို ဒီမှာဖော်ပြခဲ့တဲ့ သတိပေးချက်တွေကို အမှတ်ရပါ။

တော်လှန်ရေးစပါ။

Whitespace တွေကို ပြန်လည်သိမ်းယူပါ။

ရှုပ်ပွထအောင် မရေးပါနဲ့။

ရှင်းလင်းစွာရေးပါ။

တရားမျှတချိန်ခွင်လျှာညီမျှပါစေ။

 

၀က်တွေက မစင်ကြားမှာပဲနေတယ်။

ပရိုဂရမ်မာတွေက နေဖို့မလိုပါဘူး။

ကိစ္စပြီးလျှင်ရေလောင်းပါ။

ကုဒ်အစအနတွေသင်ထိတွေ့လိုက်ပြီဆိုတာနဲ့ မလိုတာတွေဖယ်ရှားပစ်ပါ။

 

မှတ်ရန်။ ။ သင့်ရဲ့ကုဒ်တွေကို သင်မတွေ့ခင်ကထက် ပိုကောင်းအောင် လုပ်ထားခဲ့ပါ။ ပိုတာတွေ မလိုတာတွေကို သင်တွေ့တာနဲ့ ဖယ်ရှားပစ်ပါ။

 

ကုဒ်တွေ မလိုတာတွေဖယ်ပစ်တာစတဲ့ ကုဒ်သန့်ရှင်းရေးလုပ်တာကို တခြားလုပ်ငန်းပိုင်းကုဒ်ပြင်တာတွေနဲ့ မရောပဲလုပ်ဖို့လိုတယ်ဆိုတဲ့ အကြံပေးချက်ကို ရယူပါ။

ဒီလိုလုပ်ခြင်းဖြင့် သင့်ရဲ့ source control system ကိုလည်း ပိုပြီး ရှင်းလင်းစေမှာပါ။

ကုဒ်ရှင်းတာနဲ့ လုပ်ငန်းပိုင်းကုဒ်ပြင်တာကို ရောလိုက်ရင် နားလည်ဖို့ ခက်ခဲလာမှာပါ။

တကယ်လို့ ချို့ယွင်းချက် (bugs) တွေပေါ်လာခဲ့ရင် သင့်ရဲ့ကုဒ်ရှင်းလင်းရေးကြောင့်လား လုပ်ငန်းပိုင်းကုဒ်ပြင်ဆင်မှု ကြောင့်လား ဝေခွဲမရပဲ လုပ်ရကိုင်ရခက်ခဲနိုင်ပါတယ်။

 

နိဂုံးချုပ်

ဆော့ဝဲတခုဘာလုပ်ငန်းဆောင်တာတွေ လုပ်ဆောင်နိုင်တယ်ဆိုတာ ကုဒ်ဘယ်နှစ်ကြောင်းပါလဲ သင့်စနစ်ထဲမှာ ကုဒ်အစိတ်အပိုင်းဘယ်နှစ်ခုထိပါ၀င်သလဲဆိုတာတွေနဲ့ မဆက်စပ်ပါဘူး။

ကုဒ်အကြောင်းရေများများရေးတိုင်း ပိုုလုပ်နို်င်တဲ့ဆော့ဝဲလို့ ပြောရခက်ပါတယ်။

ဒါကြောင့် မလိုရင် မရေးပါနဲ့။

နည်းနည်းနဲ့ကောင်းကောင်းရေးပြီး တခြားပျော်စရာလုပ်ဆောင်မှုကိုသာ ရှာဖွေပါလေ။

 

မေးခွန်းများ

၁. သင်ဖော်ပြချက်တွေကို လိုရင်းတိုရှင်းကုဒ်နဲ့ရေးနိုင်ပါသလား။ သင့်လိုတိုရှင်းကုဒ်က နားလည်ဖို့ ပိုခက်နေလား။

၂. သုံးခုနည်းနဲ့ ရေးလို့ ပိုရှင်းလာလား ပိုရှုပ်သွားလား။ ဘာလို့လဲ။

၃. ကျုပ်တို့ cut-and-paste တနေရာက တနေရာကို ကူးရေးနေတာမျိုး ရှောင်သင့်ပါတယ်။ function တခုအနေနဲ့ ခွဲထုတ်မရေးနိုင်ရအောင် ကုဒ်တွေက ဘယ်လောက်ကွဲပြားခြားနားမှုတွေ ရှိနေပါသလဲ။

၄. သေဆုံးနေတဲ့ကုဒ်တွေကို သင်ဘယ်လိုတွေ့ရှိနိုင်ပါသလဲ။

၅. တချို့ကုဒ်စံနှုန်းသတ်မှတ်ချက်တွေက မှတ်ချက်များများပါမှ ကောင်းတဲ့စံသတ်မှတ်လေ့ရှိတယ်။ ဒါတကယ်အသုံးဝင်ရဲ့လား။ ဒါမှမဟုတ် ဒီလိုစံမျိုးလိုက်နာတာဟာ မလိုအပ်ပဲ မှတ်ချက်တွေ များပြားလာတာမျိုးဖြစ်စေနိုင်ပါသလား။

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s