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

အပိုင္း ၁ သင္ခန္းစာ ၂ ပုံသဏၭာန္ေကာင္းထားရွိျခင္း

အျပင္ပန္းပုံပန္းသဏၭာန္ေတြက လွည့္ဖ်ားတတ္တယ္ – Aesop
ဘယ္သူမွ ရွဳပ္ပြထေနတဲ့ကုဒ္ေတြနဲ႕ အလုပ္လုပ္ရတာ ႏွစ္သက္မွာမဟုတ္ပါ
ဘယ္သူမွ ေပါက္ကရေပးထားတဲ့ variable အမည္ေတြနဲ႕ ရန္ျဖစ္ရ မညီမညာပုံစံခ်ထားတဲ့ကုဒ္ႏြံထဲ လူးလြန္႕ခ်င္မွာမဟုတ္ပါ
အဲ့လုိႀကီးက ေပ်ာ္စရာမေကာင္းဘူး အလုပ္မတြင္ဘူး ပရိုဂရမ္မာေတြအတြက္ တမလြန္ပါပဲ
သင္က ကုဒ္ေတြေကာင္းဖို႕ အေလးထားတယ္
ပုံမွန္အားျဖင့္ က်ဳပ္တို႕က ကုဒ္ေတြလွပဖို႕ အေလးထားတယ္ အဲ့လိုလွပေနမွ လုပ္ရကိုင္ရလြယ္ကူမယ္လို႕ ျမန္ျမန္ေကာက္ခ်က္ခ်လို႕ရမွာပါ

မ်ားေသာအားျဖင့္ ပရိုဂရမ္းမင္းစာအုပ္ေတြမွာ ကုဒ္ေတြကိုဘယ္လို္ပုံစံနဲ႕ ေရးသားတင္ျပမလဲဆိုတဲ့ သင္ခန္းစာတခုေတာ့ပါေလ့ရွိတယ္
ဒီစာအုပ္မွာလဲပါေတာ့ေပါ့ ရွာၾကည့္ၾကည့္ပါ
ကုဒ္ေတြကို ဘယ္လိုပုံစံနဲ႕ေရးမလဲ အရမ္းႀကီးအေလးေပးလြန္းလို႕ မလိုအပ္ပဲစကားမ်ားျကတဲ့အထိ ျဖစ္တတ္ၾကတာ စိတ္မေကာင္းစရာပါပဲ
တေယာက္တေယာက္ ရန္ျဖစ္စကားမ်ားျကတာ ဒီလိုအေျကာင္းေတြေျကာင့္ပါ
ဘယ္ ကုဒ္ editor (ဥပမာ eclipse, netbeans စသျဖင့္) က အေကာင္းဆုံးျဖစ္တယ္
စာေျကာင္းအစကို Tabs သုံးၿပီးျခားမယ္ Spaces သုံးၿပီးျခားမယ္ ကြဲျကတာ
စာေျကာင္းအဖြင့္အပိတ္ “{” ေတြ ဘယ္လိုေနရာခ်မယ္
စာေျကာင္းတုိင္း semicolumn နဲ႕ဆုံးမယ္
အဂၤလိပ္စာလုံးအကၡရာအႀကီးနဲ႕စေရးမယ္ အေသးနဲ႕စေရးမယ္
စသျဖင့္ က်ဳပ္မွာက်ဳပ္အႀကိုက္ေတြရွိသလို ခင္ဗ်ားမွာလည္း ခင္ဗ်ားအႀကိဳက္ရွိမယ္
Godwin ရဲ့ ဥပေဒသကေတာ့ အင္တာနက္မွာ ေဆြးေႏြးခ်က္ေတြၾကာရွည္လာတာနဲ႕အမွ် ဟစ္တလာလို နာဇီလိုလူနဲ႕ ႏွိဳင္းယွဥ္ေျပာလာတာမ်ိဳး ျဖစ္ဖို႕မ်ားလာတာပါပဲ
စာေရးသူရဲ့ ဥပေဒသကေတာ့ ကုဒ္ေတြကို ဘယ္လိုlayoutနဲ႕ေရးမယ္လို႕ ေဆြးေႏြးတာၾကာလာတာနဲ႕အမွ် အက်ိဳးမရွိတဲ့ျငင္းခုန္မွဳေတြျဖစ္ဖို႕မ်ားလာတာပါပဲ
ပရုိဂရမ္မာေကာင္းေတြကလည္း ဘယ္လုိပုံစံနဲ႕ေရးမလဲဆိုတာ အရမ္းအေလးနက္ထားျကေတာ့ အက်ိဳးမရွိပဲျငင္းခုန္ဖို႕ျဖစ္လာတာေတြရွိတယ္ လူႀကီးေတြလို ျပဳမူျကရေအာင္ဗ်
မွတ္ရန္။ ။Space သုံးမယ္ Tab သုံးမယ္စသျဖင့္ ကုဒ္ကို ဘယ္လို layoutပုံစံနဲ႕ေရးမယ္ဆိုၿပီး အျငင္းပြားေနၾကတာမ်ိဳးေတြ ရပ္လိုက္ပါ။ ဘယ္လိုပုံစံနဲ႕ေရးရင္ အေကာင္းဆုံးျဖစ္မလဲ စဥ္းစားၿပီး က်င့္သုံးပါ
ကုဒ္layoutကို ေသခ်ာမစဥ္းမစားပဲ အာရုံစိုက္မိတဲ့အေျကာင္းကေတာ့ ေရွးရိုးစြဲအလုပ္မျဖစ္တဲ့ ကုဒ္စစ္ေဆးမွဳေတြေျကာင့္ပါ
ကုဒ္တပိုင္းေလာက္စစ္ဖို႕ေပးလိုက္ရင္ Presentation အသြင္အျပင္တင္ျပပုံ ယုိေပါက္မ်ားကို ေရြးမိတတ္ျကပါတယ္
အထူးသျဖင့္ သာမာန္သာလွ်ံကာဖတ္ၿပီးစစ္တဲ့အခါ ကုဒ္layout ကိုပဲ အဓိကထား ေရြးၾကည့္တတ္ၾကလို႕ပါ
သင္က သိပ္အသုံး၀င္တဲ့ မွတ္ခ်က္ေတြေရးတတ္တယ္လို႕ သင္ထင္တယ္ေပါ့
“[“ bracket တခုေလာက္ေနရာမွားထားမိတာနဲ႕ ဒီဇိုင္းအလြဲေတြကို သင္ မ်က္စိရွမ္းမိတာမ်ိဳးျဖစ္တတ္ပါတယ္
ကုဒ္မ်ားမ်ားစစ္ေဆးရတာနဲ႕အမွ် ျမန္ျမန္အျပီးသတ္ခ်င္ၿပီး ဒီလိုအမွဳမဲ့အမွတ္မဲ့အမွားေတြ ပိုေပၚေပါက္လာတတ္တယ္
အျပင္အဆင္ပုံစံက အေရးႀကီးပါတယ္
Code ေတြကို ဘယ္လိုformatting ပုံစံနဲ႕ေရးတယ္ဆိုတာ အေရးမႀကီးဘူးဆိုၿပီး က်ဳပ္တို႕ဟန္ေဆာင္လို႕မရပါဘူး
ဘာလို႕အေရးႀကီးတယ္ဆိုတာ နားလည္သေဘာေပါက္ပါ
Code format ေကာင္းဆိုတာ အလွဆုံးျဖစ္တယ္လို႕ သင္ထင္တဲ့ဟာ မဟုတ္ပါဘူး
အႏုပညာေျမာက္ေအာင္ ကုဒ္ေတြကို ေနရာခ်ထားတာမ်ိဳး က်ဳပ္တို႕မလုပ္ပါဘူး
ရွင္းလင္းတဲ့ကုဒ္က ေကာင္းပါတယ္ အညီအညာရွိမယ္ ဘယ္layout လည္းဆိုတာေတာင္ သတိထားမိမွာမဟုတ္ဘူး
ကုဒ္ကိုရွင္းရွင္းလင္းလင္းေရးသားေဖာ္ျပတာဟာ အာရုံပိုမစုိက္ရသလို အာရုံေ၀၀ါးမွဳလည္းမျဖစ္ေပၚေစပါဘူး
ဒီလိုမ်ိဳးေရးျခင္းဟာ ပရုိဂရမ္မာေတြကို ကိုယ္ေရးတဲ့ကုဒ္နဲ႕ အလုပ္ပိုထိေရာက္ေစပါတယ္
ကုဒ္ျပင္ဖို႕ အားပိုစုိက္ရတာမ်ိဳးကိုလည္း ေလွ်ာ့ခ်ေပးပါတယ္
မွတ္ရန္။ ။ေကာင္းတဲ့ကုဒ္က သင္ဘာကိုဆိုလိုခ်င္တာလဲဆိုတာကို ေဖာ္ထုတ္ေပးႏုိင္ပါတယ္ အႏုပညာရသေျမာက္ဖို႕ ႀကိုးပမ္းေနတာမ်ိဳးမဟုတ္ပါဘူး
ကုဒ္ေတြကုိ ရွင္းလင္းတဲ့ပုံစံနဲ႕ ေဖာ္ျပဖို႕အေရးႀကီးပါတယ္ အလွသက္သက္မဟုတ္ပါ အမွားအယြင္းကင္းေစဖို႕ျဖစ္ပါတယ္ ဥပမာအေနနဲ႕ C language နဲ႕ေရးထားတဲ့ ေအာက္ပါကုဒ္ကို ၾကည့္ပါ
BBP_CH2_S01
ေရးတဲ့သူက ဘာျဖစ္ေစခ်င္တာလဲ သိတယ္မဟုတ္လား exit(0); ပရိုဂရမ္မွထြက္္ပါ ဆိုတဲ့ကုဒ္စာေျကာင္းကို စစ္ထားတာ မမွန္မွ ထြက္ေစခ်င္တာပါ
ဒါေပမဲ့လည္း ေဖာ္ျပထားပုံအရ ဆိုလိုခ်င္တာကို ၀ွက္ထားသလိုျဖစ္ေနပါတယ္ ဒီကုဒ္ကို run လိုက္တုိင္း ပရိုဂရမ္က ထြက္သြားေနမွာပါ
layout ေရြးခ်ယ္မွဳအမွားကေန ဒီလိုအခက္ေတြ႕ေစတဲ့ကုဒ္ေတြကို ေပၚေပါက္လာေစမွာပါ။ ဒီဥပမာက ဒီစာအုပ္ဖတ္ေကာင္းေအာင္ ေဖာ္ျပထားယုံမဟုတ္ပါဘူး လက္ေတြ႕ေလာကမွာလည္း ဒီထက္ဆုိးရြားတဲ့အမွားေတြျဖစ္ဘူးပါတယ္ Apple ရဲ့ သိပ္မေက်ာ္ျကားလွတဲ့ 2014 goto fail လုံၿခဳံေရးခ်ိဳ႕ယြင္းခ်က္ဟာ SSL/TLS လုပ္ေဆာင္ဖို႕ေရးထားတဲ့ ဒီလို layout အမွားမ်ိဳးေျကာင့္ ျဖစ္ေပၚခဲ့တာပါ
Variable အမည္ေပးတာေတြကေနလည္း အမွားအယြင္းမ်ားစြာျဖစ္ေစႏုိင္ပါတယ္
အမည္ေပးမွားျခင္းကေန စိတ္ပ်က္ေစယုံမက အႏၱရာယ္လည္းရွိေစမွာပါ
ကဲေအာက္ကေပးထားတဲ့ Variable နာမည္ေတြထဲမွာ ဘယ္ဟာကဆိုးရြားပါသလဲ
BBP_CH2_S02
numberOfGreenWidgets ဆိုတာ Variable တခု ဟုတ္ပါသလား
ဘယ္ႏွစ္ခုရွိလဲေရတြက္တာသိမ္းဖို႕ ေပးထားသလိုျဖစ္ေနၿပီး အမွန္အမွားဆိုတဲ့ Boolean type နဲ႕ မသင့္ေတာ္ဘူးမို႕လား
Name အမည္ဆိုတဲ့ variable ကလည္း widget အမည္သိမ္းဖို႕မဟုတ္ပဲ ဘယ္အေရာင္လဲသိမ္းဖို႕ျဖစ္ပါတယ္
turnGreen() ဆိုတဲ့ function နဲ႕ အေရာင္ေျပာင္းၿပီးမွတ္ဖို႕ပါ
ဒါေျကာင့္ေပးထားတဲ့အမည္က အမွတ္မွားေစပါတယ္
Turngreen() ကိုေအာက္ပါအတိုင္းေရးထားပါတယ္
BBP_CH2_S03
ခုနကေပးထားတဲ့ နာမည္ေတြဟာ အမွားေတြခ်ည္းပါပဲ
ဒါက ျကံဖန္ဥပမာေပးထားတာျဖစ္ႏုိင္ပါတယ္ ဒါေပမဲ့ သတိမထားဘဲေရးမယ္ဆုိရင္ ဒီလိုကုဒ္အမွားေတြေပၚေပါက္ႏုိ္င္ပါတယ္
ဒီလိုကုဒ္မ်ိဳးနဲ႕ အလုပ္လုပ္ရရင္ ဘာျဖစ္မယ္ထင္လဲ သင့္ပရိုဂရမ္ဟာ ခ်ိဳ႕ယြင္းခ်က္(bugs) ေတြမ်ားစြာ ရွိလာႏုိင္ပါတယ္
မွတ္ရန္။ ။ ကုဒ္အမွားေတြေရွာင္ဖို႕ ေရးသားေဖာ္ျပပုံေကာင္းဖို႕လိုအပ္ပါတယ္ အဲ့လိုမဟုတ္ရင္ေတာ့ ASCII အႏုပညာေတြ ဖန္တီးေနသလိုျဖစ္ေနေတာ့မယ္
မညီညာတဲ့ layout နဲ႕ေရးျခင္းမ်ိဳး ရွဳပ္ေထြးလွတဲ့ Variable နာမည္ေတြနဲ႕ ေရးထားတာမ်ိဳးနဲ႕ျကဳံရင္ ကုဒ္အရည္အေသြးမေကာင္းတာ ေသခ်ာပါၿပီ
ေရးတဲ့သူက layout ကို ေတာင္ ေသခ်ာစီမေရးတာ ဒီဇိုင္းေကာင္းဖို႕ ေသခ်ာစမ္းဖို႕စတဲ့ တျခားအရည္အေသြးေကာင္းဖို႕လုပ္ရတာေတြနဲ႕ ပိုေ၀းၿပီေပါ့

တဦးနဲ႕တဦးဆက္သြယ္ေရးအတြက္

သင္ဟာ ပရိတ္သတ္ႏွစ္ဦးအတြက္ ကုဒ္ေရးရပါတယ္
ပထမတေယာက္ကေတာ့ Compiler (ဒါမွမဟုတ္ language runtime ) အတြက္ပါ
ဒီ Compiler ဆိုတဲ့ ဘီလူးႀကီးကေတာ့ အိုေဟာင္းၿပီး ေလ်ာ့တိေလ်ာ့ရြဲျဖစ္ေနတဲ့ ကုဒ္မ်ိဳးကိုေတာင္ ယူၿပီး သူနားလည္သလို runလို႕ရတဲ့ ပရိုဂရမ္အျဖစ္ေျပာင္းပစ္ဖို႕ကို ေပ်ာ္ေပ်ာ္ႀကီးလုပ္ေဆာင္မွာပါ
သင္ဘယ္လိုပုံစံနဲ႕ေရးေရး ဘယ္လိုအရည္အေသြးနဲ႕ေရးထားသလဲစစ္ေဆးေနမွာမဟုတ္ပဲ သင့္ကုဒ္ကို လိုလိုလားလားလုပ္ေဆာင္ေပးမွာပါ
သူက ဖတ္တယ္ဆုိတာထက္ ေျပာင္းဖို႕ပဲလုပ္ေဆာင္ေပးမွာပါ
တကယ္အေရးႀကီးတဲ့ပရိသတ္ေနာက္တဦးကေတာ့ တျခားပရိုဂရမ္မာေတြပါပဲ
ကြန္ပ်ဴတာေတြက runဖို႕ က်ဳပ္တို႕ေရးရသလို လူေတြဖတ္ႏုိင္ဖို႕လည္း ေရးရပါတယ္
ဘယ္လူေတြလဲ ဆုိေတာ့
  • သင့္ကုဒ္က သင္ဖတ္ဖို႕ပါ ေရးေနရင္းနဲ႕ေတာင္ဖတ္ေနရၿပီ ကုဒ္ေတြက ရွင္းရွင္းလင္းလင္းႀကီးေရးဖို႕လိုပါတယ္ ဒီလိုမွအမွားနည္းမယ္
  •  ေနာက္တပတ္ႏွစ္ပတ္ ဒါမွမဟုတ္ တလႏွစ္လေနတဲ့အခါ သင့္ေဆာ့ဖ္၀ဲကို release လုပ္ဖို႕အတြက္ သင္ျပန္ဖတ္ဖို႕ပါ
  •  သင့္အဖြဲ႕ထဲက တျခားပရိုဂရမ္မာေတြက သင့္ကုဒ္ကို သူတို႕ကုဒ္ေတြနဲ႕ေပါင္းဖို႕လိုတဲ့အတြက္ သူတို႕လည္းဖတ္ဖို႕ပါ
  •  ေနာက္ေနာင္ႏွစ္ေပါင္းမ်ားစြာျကာတဲ့အခါ ခ်ိဳ႕ယြင္းခ်က္အမွားတခုရွာဖို႕ ျပဳျပင္ထိန္းသိမ္းေရးပရိုဂရမ္မာ(သင္ကိုယ္တိုင္ ဒါမွမဟုတ္ တျခားတေယာက္)က ဖတ္ဖို႕ပါ
ဖတ္ရခက္တဲ့ကုဒ္က အလုပ္လုပ္ရခက္ပါတယ္ ဒါေျကာင့္မို႕တျခားသူေတြဘက္ကနားလည္မွုရွိတဲ့ ရွင္းလင္းတဲ့ ေဖာ္ျပပုံေကာင္းတဲ့ကုဒ္ေတြကို ေရးေပးဖို႕ က်ဳပ္တို႕ျကိဳးပမ္းေနျကတာပါ
မွတ္ဖို႕။။ တျခားလူေတြဖတ္ဖို႕လည္း ေရးေနတယ္ဆိုတာ အမွတ္ရပါ
အျမင္လွေပမယ့္ ဆိုလိုရင္းကိုေ၀၀ါးေစတဲ့ကုဒ္ေတြ က်ဳပ္တို႕ ျမင္ခဲ့ျကၿပီးၿပီ အရမ္းလွေပမဲ့ အင္မတန္မွျပင္ရခက္တာမ်ိဳးပါ
ဥပမာေကာင္းကေတာ့ “comment box” ပုံစံ မွတ္ခ်က္ေပးတာမ်ိဳးပါ
တခ်ိဳ႕ပရိုဂရမ္မာေတြက ေအာင္လံတံခြန္လိုေဘာင္ခတ္ၿပီး မွတ္ခ်က္ေပးရတာျကိဳက္ျကတယ္
BBP_CH2_S04
လွပါရဲ့ ျပင္ဖို႕ေတာ့ခက္တယ္ ဒီမွတ္ခ်က္ကိုသင္ျပန္ျပင္ခ်င္ရင္ ညာဘက္ဆုံးက ျကယ္ေတြကို တခုခ်င္းျပန္စီရမွာပါ
ခင္မင္ရင္းႏွီးစြာေျပာရရင္ေတာ့ တကယ္ကိုရက္ရက္စက္စက္ေဖာ္ျပခ်က္ပုံစံမ်ိဳးပါ ဒီလိုဟန္ပန္နဲ႕ေရးတာဟာ လုပ္ေဖာ္ကုိင္ဖက္ေတြအတြက္ထည့္မစဥ္းစားတတ္တာပါ
ဒါမွမဟုတ္လည္း ဘယ္သူမွ သူတို႕ရဲ့ မွတ္ခ်က္စကားေျပကို မျပင္ႏုိင္ေအာင္ တမင္မ်ားအားထုတ္ေရးထားသလား ထင္ရပါတယ္

Layout ပုံစံ

အေရးရွင္းခ်င္ရင္ အေတြးရွင္းဖို႕လိုပါတယ္ – Johann von Goethe
ကုဒ္layout နဲ႕ သက္ဆုိင္တာေတြကေတာ့ စာေျကာငး္အတြင္းသုိ႕တိုးေရးျခင္း (indentation) ၊ operator ( + – * / စသည္) ေတြေဘးမွာ space ျခားျခင္း ၊ အဂၤလိပ္အကၡရာႀကီးျဖင့္ေရးျခင္း ၊ အတြင္းတိုးေရးတဲ့အခါ tab သုံးမွာလား space သုံးမွာလား အျငင္းပြားစရာ စသျဖင့္ပါ၀င္ပါတယ္ အဲ့ဒီတခုခ်င္းဆီေရြးခ်ယ္တဲ့အထဲက သင္ဘာကိုေရြးေရြး ဘာေျကာင့္ေရြးတယ္ဆိုတဲ့အေျကာင္းရင္းရွိရပါမယ္ ဘယ္layout နဲ႕ေရးဖို႕ေရြးေရြး အဲ့layout က သင့္ကုဒ္ရဲ့ပုံသဏၭန္ပိုေကာင္းေစတယ္ ဆိုလိုရင္းရည္ရြယ္ခ်က္ကို ပိုပီျပင္ေစတယ္ဆို သိပ္ေကာင္းတာေပါ့
ပုံစံတက်ေရးပါ
စကားေျပေရးသလို ကုဒ္ကိုေရးပါ
သင္ခန္းစာ၊စာပိုဒ္၊စာေျကာင္းေတြဆိုၿပီး ခြဲထုတ္လိုက္ပါ
အေျကာင္းအရာတူတာေတြတစုတစည္းထားပါ
အေျကာင္းအရာမတူတာေတြ သပ္သပ္စီခြဲထားပါ
Functions ေတြကို သင္ခန္းစာတခုနဲ႕တူတယ္လို႕ မွတ္ပါ
သင္ခန္းစာတခုခ်င္းဆီထဲမွာ ကြဲျပားတာနည္းၿပီး ဆက္ႏြယ္တဲ့ကုဒ္ေတြေရးပါ
သင္ခန္းစာေတြထဲ စာပုိဒ္ေတြျဖစ္လာေစဖို႕ စာေျကာင္းအလြတ္ေတြျဖင့္ ျခားထားပါ
စာပုိဒ္တပုိဒ္လိုသဘာ၀က်က်ခြဲႏိုင္မွာသာ စာေျကာင္းအလြတ္ကိုထည့္ပါ
ဒီနည္းလမ္းဟာ ပုံသဏၭာန္ေကာင္းရေစဖို႕ ကူညီေပးပါတယ္
BBP_CH2_S05
ကုဒ္ေတြကို ဘယ္လိုစီထားလဲဆိုတာ အေရးႀကီးပါတယ္
သင့္ကုဒ္ေတြကို ဖတ္မည့္စာဖတ္သူဘက္က စဥ္းစားပါ
အေရးအျကီးဆုံးျဖစ္တာေတြကို အရင္ဆုံးထားပါ
API ဖတ္မယ့္သူေတြအတြက္ လက္ေတြ႕အသုံးမ်ားတာေတြ အရင္ထားပါ
ဖတ္မည့္သူအတြက္ အေရးျကီးတာကို သင့္ class definition ရဲ့ အေပၚဆုံးပိုင္းမွာေရးပါ
Public fields/function စတဲ့ public နဲ႕ဆိုင္တာေတြ အရင္ေရးၿပီး Private နဲ႕ဆုိင္တာေတြေနာက္မွာေရးပါ
Object မွာ ေခၚသုံးရတဲ့ Method ေတြမတုိင္ခင္ Object ဘယ္လို create လုပ္ရလဲ အရင္ဆုံးေရးပါ
ေအာက္ေဖာ္ျပပါ Class ေရးပုံမ်ိဳးျဖစ္ပါတယ္
BBP_CH2_S06
ကုဒ္တပိုင္းခ်င္းဆီ တိုတိုေရးပါ Function တခုထဲမွာ စာပိုဒ္ငါးပိုဒ္စာေလာက္မေရးပါနဲ႕
သင့္ေတာ္ရင္ Function ငါးခုအျဖစ္ ခြဲေရးၿပီး Function နာမည္ေသခ်ာေရြးေပးပါ

ညီညာမွဳ

ဘယ္ layout စတုိင္ နဲ႕ ေရးမလဲဆိုၿပီး အေရြးခက္ေနတာမ်ိဳးေရွာင္ပါ
တခုခုကို ေရြးခ်ယ္ပါ တညီတညာအစဥ္တစိုက္သုံးပါ
သင့္ ပရိုဂရမ္းမင္းဘာသာစကားနဲ႕တူညီတာမ်ိဳး သဘာ၀က်တာမ်ိဳးေရြးပါ standard library ေတြရဲ့ စတုိင္မ်ိဳးအသုံးျပဳပါ
သင့္အဖြဲ႕ထဲကတျခားလူေတြရဲ့ layoutနဲ႕ ပုံစံတူ ေရးပါ
သင့္ရဲ့ကိုယ္ပိုင္စတိုင္က ပိုလွ ပိုေကာင္းလို႕ဆိုၿပီးထင္ယုံနဲ႕ သင့္စတုိင္ကိုမသုံးပါႏွင့္
သင့္ရဲ့ပေရာ့ဂ်က္မွာ တညီတညာသုံးတာမ်ိဳးမရွိရင္ Coding Standard ကုဒ္စံသတ္မွတ္ခ်က္ အတိုင္း (သို႕) Style Guide မွာေဖာ္ျပထားတဲ့အတုိင္း သုံးပါ
ဒီလိုစည္းကမ္းခ်က္ေတြကလည္း ရွည္လ်ားေထြျပားတဲ့ စာရြက္ရွည္ႀကီးျဖစ္စရာမလိုပါဘူး
သင့္အဖြဲ႕သားေတြ လိုက္နာႏုိင္တဲ့ layout သတ္မွတ္ခ်က္ေတြဆို လုံေလာက္ပါတယ္
ကုဒ္ စံသတ္မွတ္ခ်က္ဆိုတို္င္းလည္း သင့္အဖြဲ႕သားေတြကလည္း ႏွစ္ဦးႏွစ္ဖက္သေဘာတူတာမ်ိဳးျဖစ္ရပါမယ္ ဖိအားေပးေရးခိုင္းတာမ်ိဳးမျဖစ္ေစရပါဘူး
တကယ္လို႕ တျခား file တခုခုကိုလုပ္ရၿပီ အဲ့fileက သင့္ပေရာ့ဂ်က္ layout ပုံစံအတိုင္းမဟုတ္ရင္ အဲ့ဒီ file ရဲ့ layout ပုံစံအတိုင္း လိုက္နာလုပ္ေဆာင္ပါ
သင့္အဖြဲ႕ရဲ့ IDE ေတြ ကုဒ္ေရးတဲ့ editor ေတြကိုလညး္ တညီတည္းခ်ိန္ညိွထားပါ
Tab ခုန္တဲ့အကြာအေ၀းကိုညီတူထားပါ
မွတ္ခ်က္ေရးတဲ့ layout ကိုေရာ စာေျကာင္းအဖြင့္အပိတ္ “{“ ေတြကိုေရာ တူညီစြာသုံးပါ
စာေျကာင္းအဆုံးသတ္အကၡရာ line ending ထားရွိပုံေတြလည္း တူပါေစ
Cross platform project ေတြအတြက္ မတူညီတဲ့ ကြန္ပ်ဴတာမ်ိဳးေတြမွာ ျပိုင္တူေရးျကရင္ ဒီလိုစာေျကာင္းအဆုံးသတ္အကၡရာက ပိုအေရးႀကီးပါတယ္
သင္ဒီလို ညီညာေအာင္ ျကိဳးစားမေရးရင္ သင္တို႕ကုဒ္ေတြက မတူကြဲျပားၿပီး ဆိုးရြားလွတဲ့ကုဒ္ေတြ သင္ေရးထုတ္ေနမွာပါ

Space စစ္ပြဲ

ကုဒ္ေတြရဲ့ တင္ျပပုံ ပုံသဏၭာန္ကို အေရးမထားတဲ့ ပရိုဂရမ္မာေတြနဲ႕ က်ဳပ္ ပေရာ့ဂ်က္တခုအတူလုပ္ဘူးပါတယ္
ကုဒ္ေတြက ရွဳပ္ေထြးလွၿပီး မညီမညာနဲ႕ စိတ္ပ်က္စရာေကာင္းပါတယ္
ကုဒ္ စံသတ္မွတ္ခ်က္ထားဖို႕ က်ဳပ္သူတို႕ကို ေတာင္းဆိုလိုက္ပါတယ္
ပရိုဂရမ္မာအားလုံးက အျကံေကာင္းအျဖစ္လက္ခံသေဘာတူျကျပီး (variable/class စတဲ့) နာမည္ေတြ ဘယ္လိုေပးမယ္ ဘယ္ layout သုံးမယ္ ဘယ္လို folder အဆင့္ဆင့္ထားမယ္ဆိုတာ အားလုံးသေဘာတူညီခ်င္ျကပါတယ္
ဒါဟာ ျကီးက်ယ္တဲ့ေျခလွမ္းအစပါ ကုဒ္ေတြက ရွင္းရွင္းလင္းလင္းျဖစ္လာပါတယ္
ဒါေပမဲ့လည္း သေဘာဘယ္လိုမွမညီနိုင္တဲ့အေျကာင္းတခုေတာ့ရွိပါတယ္
သင္ခန္႕မွန္းမိမွာပါ Tab သုံးမလား Space သုံးမလားဆိုတာေပါ့
အားလုံးနီးပါက Space ေလးခါနဲ႕ စာေျကာင္းအစျခားထားတာကို သေဘာတူျကတယ္
တေယာက္ကေတာ့ လုံး၀ Tab မွ Tab ပဲ Tab က ပိုေကာင္းတယ္ပဲ သေဘာရပါတယ္
သူက Space သုံးဖို႕ျငင္းတယ္ ေစာဒကတက္တယ္ သူေရးတဲ့ပုံစံျပင္ဖို႕လည္း ျငင္းတယ္
ခုထိလည္း သူျငင္းေနဦးမလားပဲ
က်ဳပ္တို႕ သိသာထင္ရွားတဲ့တိုးတက္မွဳေတြရရွိေနတာေရာ မလိုအပ္ပဲသေဘာထားကြဲလြဲတာကို ေရွာင္ခ်င္တာနဲ႕ပဲ ဒီကိစၥကို ေဘးဖယ္ထားခဲ့ျကတယ္
က်ဳပ္တို႕အားလုံးက Spaces သုံးတယ္ သူက Tabs သုံးတယ္
အဆုံးသတ္ရလာဒ္ကေတာ့ ကုဒ္ေတြက စိတ္ပ်က္ဖို႕ေကာင္းၿပီး လုပ္ရကိုင္ရခက္ပါတယ္ ျပင္ရတာလည္း အေတာ္ခက္ၿပီး တခါတေလ cursor က space တခုစာေရြ႕ၿပီး တခါတေလ tab တခုစာခုန္ေနပါေတာ့တယ္ tab အဆုံးသတ္ကို ေသခ်ာျခားထားရင္ တခ်ိဳ႕ Editor ေတြမွာေကာင္းေကာင္းျပႏုိင္ေပမယ့္ တခ်ိဳ႕ Editor ေတြမွာေတာ့ တရြဲ႕တေစာင္းနဲ႕ ျကည့္ရဆိုးစြာ ျပေနပါတယ္
“အမည္ေပးျခင္း”
ကြ်ႏု္ပ္က စကားလုံးတလုံးကုိ မေလးမစားအထင္ေသးတဲ့အသံနဲ႕ ေျပာရင္ အဲ႕စကားလုံးက ကြ်ႏု္ပ္ဆိုလိုခ်င္တဲ့အတိုင္း အဓိပါၸယ္ေဆာင္ပါတယ္ အပိုအလိုမရွိပါဘူး – Lewis Caroll
Variables, Function, Type စသျဖင့္ က်ဳပ္တို႕ အမည္ေတြအမ်ားျကီးေပးျကရပါတယ္
ပိုအေရးျကီးတဲ့ files ေတြ ပေရာ့ဂ်က္ေတြ ပရုိဂရမ္ေတြကိုလည္း အမည္ေပးၾကရပါတယ္
အမ်ားသုံး Public API ေတြမွာ အမည္ေပးရတာ ပိုၿပီး ေရြးျကရပါေသးတယ္ ဘာလို႕လဲဆိုေတာ့ ထုတ္ၿပီးသား လူသုံးျပီးသား API ေတြဆို အမည္ေတြက ေက်ာက္သားလိုခုိင္ၿမဲသြားၿပီး ေပးၿပီသားအမည္ကို ျပန္ျပင္ရခက္လြန္းလို႕ပါ
Object တခုက ဘာလဲဆိုတာ အမည္နဲ႕တင္ေဖာ္ထုတ္ႏုိင္ပါတယ္ အမည္က သူ႕ရဲ့အျပဳအမူနဲ႕ ဘယ္လိုသုံးဖို႕ရည္ရြယ္တယ္ဆိုတာ ေဖာ္ျပေပးႏုိင္တယ္
အမည္ေပးမွားတဲ့အမည္တခုက အင္မတန္ရွဳပ္ေထြးေစပါတယ္
ေကာင္းတဲ့အမည္တခုကေတာ့ ရွင္းလင္းမွန္ကန္စြာေဖာ္ျပတတ္ပါတယ္
သင္ဘာကိုဆိုလိုခ်င္လဲအတိအက်သိမွာသာ အမည္ေပးလို႕ရပါတယ္
သင္ဆိုလိုခ်င္တာကို ရွင္းရွင္းလင္းလင္းမသိပဲ ဘယ္လိုသုံးရမလဲရွင္းရွင္းလင္းလင္းမသိပဲ အမည္ေပးရမလြယ္ပါဘူး

မလုိအပ္ပဲသုံးတာေတြ ေရွာင္ပါ

အမည္ေပးတဲ့အခါ မလိုအပ္တာေတြကိုေရွာင္ပါ
BBP_CH2_S07
numberofWidgets ဆိုတာ မလိုအပ္ပဲ ရွည္လ်ားလြန္းပါတယ္
Widget ဆိုတဲ့စာလုံးကို ထပ္ကာထပ္ကာသုံးထားပါတယ္
ဒီလိုရွည္တဲ့အတြက္ ကုဒ္က ပုိျငီးေငြ႕ဖို႕ေကာင္းၿပီး ဖတ္ရခက္လာပါတယ္
ဒီ Method က ဘယ္ႏွစ္ခုရွိသလဲဆိုတဲ့ size ကိုျပန္ေပးခ်င္တာျဖစ္တဲ့အတြက္ size() လို႕ လြယ္လြယ္ကူကူ ေခၚလို႕ရပါတယ္ ဘာမွရွဳပ္ေထြးေနစရာမလိုေတာ့ပါဘူး
ထပ္ကာထပ္ကာ မလိုအပ္ပဲသုံးတဲ့ စာလုံးေတြေရွာင္ပါ
တခါတုန္းက က်ဳပ္ project တခုမွာ DataObject လို႕ေခၚတဲ့ class တခုကုိ ေတြ႕ဘူးတယ္ မလိုအပ္ပဲ ရွဳပ္ေထြးစရာေကာငး္တဲ့ နာမည္တခုပါပဲ
“ရွင္းလင္းစြာေပးပါ”
အႏွစ္ခ်ဳပ္လြန္းတာထက္ ရွင္းလင္းစြာအမည္ေပးမွဳကို ေရြးပါ
ကီးဘုတ္ရိုက္ရသက္သာယုံ အမည္ေတြကို တိုတုိမေပးပါႏွင့္
Variable အမည္ေတြကို သင္ရိုက္တဲ့အျကိမ္ထက္ ဖတ္တဲ့အျကိမ္က ပိုမ်ားပါတယ္
Loop ေတြမွာသုံးတဲ့ loop ဘယ္ႏွျကိမ္လည္းေရတြက္တဲ့အမည္ေတြဆိုရင္ေတာ့ တိုတိုေလးေပးေပါ့ ဖတ္ရပိုလြယ္တာေပါ့
ဘယ္ေနရာအတြက္သုံးမယ့္ variable လည္းေပၚမူတည္ၿပီး ေပးပါ
လွ်ိဳ႕၀ွက္နက္နဲတဲ့အမည္ေတြ ေပးဖို႕ မလိုပါဘူး ျကီးျကီးက်ယ္က်ယ္စာလုံးေတြ အဂၤလိပ္စကားလုံးေတြရဲ့ ထိပ္ဆုံးအကၡရာေတြပဲသုံးၿပီး အတိုေကာက္အမည္ေပးတာမ်ိဳးေရွာင္ပါ

သဘာ၀က်က် အမည္ေပးပါ

သင့္ ပရိုဂရမ္ဘာသာစကားမွာသုံးတဲ့ အကၡရာအျကီးအေသးပုံစံကို အသုံးျပဳပါ
ပရိုဂရမ္ဘာသာစကားတခုမွာ တကယ္အားေကာင္းတဲ့အမည္ေပးျခင္းေတြ ရွိတတ္လို႕ သင့္မွာအေျကာင္းျပခ်က္ခုိင္လုံမွသာ ခ်ိဳးေဖာက္ပါ
ဥပမာအားျဖင့္
· C programming ရဲ့ macros ေတြက အမ်ားအားျဖင့္ အဂၤလိပ္အကၡရာအျကီးနဲ႕စေပးေလ့ရွိပါတယ္
· Types ေတြ (ဥပမာ Class) ကို အျကီးနဲ႕ေပးေလ႕ရွိၿပီး methods နဲ႕ variables ေတြကို အေသးနဲ႕စေပးေလ႕ရွိပါတယ္
ဒါအမ်ားသုံးျကတဲ့ပုံစံျဖစ္ၿပီး သင္ခ်ိဳးေဖာက္မယ္ဆို သင့္ကုဒ္က ဖတ္ရရွဳပ္ေစမွာပါ
“တိက်မွန္ကန္စြာ အမည္ေပးပါ”
သင္ေပးတဲ့အမည္ေတြက တိက်မွန္ကန္ပါေစ
Array လိုသုံးမယ့္ type တခုကို WidgetSet ဆိုၿပီး Set အစု အေနနဲ႕ အမည္မေပးပါနဲ႕
မတိက်မမွန္ကန္ပဲအမည္ေပးရင္ သင္ေဖာ္ျပတဲ့ typeရဲ့ အျပဳအမူ ၀ိေသသလကၡဏာေတြကို ဖတ္မည့္သူက လြဲမွားစြာမွတ္ယူႏိုင္ပါတယ္
မညီမညာျဖစ္တဲ့ကုဒ္ေတြနဲ႕က်ဳပ္တို႕မျကာခဏျကဳံျကရပါတယ္
အဲ့လိုကုဒ္ေတြနဲ႕ အလုပ္လုပ္ရရင္ သတိထားပါ
တကယ္လို႕ သင္ကမျဖစ္မေန ေသသပ္ရွင္းလင္းသြားေအာင္လုပ္ရမယ္ဆိုလည္း တျခားတြက္ခ်က္မွဳ လုပ္ေဆာင္ခ်က္ျပင္ဆင္မွဳေတြနဲ႕ တၿပိဳင္တည္းမလုပ္ပါနဲ႕
ကုဒ္အသြင္အျပင္ ျပင္ထားတာေတြကို source control ထဲ သီးသန္႕တေခါက္သက္သက္ထည့္ပါ ၿပီးမွ တျခားလုပ္ေဆာင္ခ်က္ေတြကို ျပင္ဆင္ပါ
အဲ့တာႏွစ္ခုကိုေရာလုပ္ရင္ ေတာ္ေတာ္ရွဳပ္ေထြးသြားေစပါလိမ့္မယ္ ကုဒ္ layout ပိုင္းအျပင္အဆင္က လုပ္ေဆာင္မွဳပိုင္းျပင္ဆင္တာကို အမွားအယြင္းပါေစႏုိင္ပါတယ္
မွတ္ရန္။ ။ အသြင္အျပင္ျပင္တာနဲ႕ လုပ္ေဆာင္ခ်က္ျပင္တာကို တျပိဳင္တည္းမလုပ္ပါနဲ႕ source control ထဲကို သီးျခား version အျဖစ္ ထည့္ပါ
Layout style တခုေရြးၿပီးတာနဲ႕ တသက္လုံးအဲ့တာပဲသုံးရမယ္ မဆိုလိုပါ
ေရြးထားတဲ့ Layoutက သင့္ကုဒ္ေတြကုို ဘယ္လိုအက်ိဳးသက္ေရာက္လဲ အၿမဲေစာင့္ျကည့္ပါ
သင္ဖတ္ရတဲ့ တျခားကုဒ္ေတြဆီကလည္း သင္ယူပါ
အေတြ႕အျကံဳမ်ားလာတဲ႕နဲ႕အမွ် Layout ပုိင္းကို လိုအပ္သလိုျပင္ဆင္ပါ
က်ဳပ္ရဲ့ အသက္ေမြး၀မ္းေက်ာင္းဘ၀မွာ က်ဳပ္ကုဒ္ေရးတဲ့ပုံစံကုိ ျဖည္းျဖည္းခ်င္းျပင္ခဲ့တယ္ ပိုညီညာၿပီး ပုိျပင္ရလြယ္တဲ့ layout မ်ိဳးဆီ ေျပာင္းလာခဲ့တယ္
ကုဒ္format ေတြျပင္ေပးတဲ့ ညိွေပးတဲ့ tools ေတြလည္းရွိပါတယ္ စမ္းသုံးျကည့္လို႕ရေပမယ့္ လက္ေတြ႕အသုံး၀င္ဖို႕ခက္ပါတယ္ လက္ေတြ႕ကုဒ္ေတြရဲ့ အသြင္အျပင္ကို ျပင္ဖို႕ layout tools ေတြက ျပင္ေပးဖို႕မလြယ္ပါဘူး

နိဂုံး

ကုဒ္ေတြဘယ္လုိပုံသဏၭာန္နဲ႕ေရးမယ္ဆိုတာ အျငင္းပြားေနျကတာ ရပ္လိုက္ပါ သင့္ပေရာ့ဂ်က္အတြက္ သင့္ေလ်ာ္မယ့္ layout style ကို အသုံးျပဳပါ
Layout ပုံစံေကာင္းေတြမွာ ဘာေတြပါ၀င္မလဲ ဘာေျကာင့္ပါ၀င္သလဲဆိုတာ ေတြးေတာထားပါ
အၿမဲသင္ျကားေနၿပီး တျခားလူေတြရဲ့ကုဒ္ေတြကိုဖတ္ရင္း အေတြ႕အျကဳံအၿမဲယူေနပါ
သင့္ကုဒ္ေတြကို ညီညာေစဖို႕ ရွင္းလင္ေစဖို႕ အၿမဲျကိဳးစားေနပါ
“ေမးခြန္းမ်ား”
· သင့္ကုမၸဏီရဲ့ စံသတ္မွတ္ခ်က္ကို လိုက္နာဖို႕ ကုဒ္အေဟာင္းေတြရဲ့ layout ပုံစံကို သင္ျပင္သင့္လား ဒါမွမဟုတ္ နဂိုေရးတဲ့သူရဲ့ပုံစံအတိုင္းထားသင့္လား ဘာေျကာင့္ပါလဲ
· Code reformat tool ကုဒ္ျပန္စီတဲ့ tool ေတြက အသုံး၀င္ပါသလား သင္သုံးတဲ့ ပရိုဂရမ္မင္းဘာသာစကားအေပၚဘယ္ေလာက္မူတည္ေနပါသလဲ
· Code ဒီဇိုင္းေကာငး္တာနဲ႕ Code တင္ျပပုံေကာင္းတာ ဘာကြာလဲ ဘယ္ဟာက ပုိအေရးျကီးလဲ
· သင္ရဲ့ပေရာ့ဂ်က္ကုဒ္ေတြက ညီညာပါသလား မညီရင္ ဘယ္လိုျပဳျပင္သင့္လဲ
· ပရုိဂရမ္ဘာသာစကားတခုရဲ့ layout ပုံစံနဲ႕ အမည္ေပးပုံေပးနည္းေတြလိုက္နာဖို႕ အေရးျကီးတယ္ဆိုတာ မွန္ပါသလား ဒါမွမဟုတ္ကုိယ့္အဖြဲ့ရဲ့ပုံစံအတုိင္းေပးမွ ပိုမိုကြဲျပားမွာပါလား
· ကုဒ္ေတြကို အေရာင္ခြဲျခားေဖာ္ျပေပးႏုိင္တဲ့ Editor ေတြကိုသုံးတာနဲ႕ ကုဒ္ေတြကို အေရာင္နဲ႕ခြဲျခားလို႕ရယုံနဲ႕ ကုဒ္ေတြရဲ့ အသြင္အျပင္ layout ပုံစံကို အေလးထားစရာမလိုေတာ့ဘူးလား
ေလးစားစြာျဖင့္
ေစာေအးခ်မ္း

 

Unicode

အပိုင်း ၁ သင်ခန်းစာ ၂ ပုံသဏ္ဌာန်ကောင်းထားရှိခြင်း

 

အပြင်ပန်းပုံပန်းသဏ္ဌာန်တွေက လှည့်ဖျားတတ်တယ် – Aesop

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

များသောအားဖြင့် ပရိုဂရမ်းမင်းစာအုပ်တွေမှာ ကုဒ်တွေကိုဘယ်လို်ပုံစံနဲ့ ရေးသားတင်ပြမလဲဆိုတဲ့ သင်ခန်းစာတခုတော့ပါလေ့ရှိတယ်
ဒီစာအုပ်မှာလဲပါတော့ပေါ့ ရှာကြည့်ကြည့်ပါ
ကုဒ်တွေကို ဘယ်လိုပုံစံနဲ့ရေးမလဲ အရမ်းကြီးအလေးပေးလွန်းလို့ မလိုအပ်ပဲစကားများကြတဲ့အထိ ဖြစ်တတ်ကြတာ စိတ်မကောင်းစရာပါပဲ
တယောက်တယောက် ရန်ဖြစ်စကားများကြတာ ဒီလိုအကြောင်းတွေကြောင့်ပါ
ဘယ် ကုဒ် editor (ဥပမာ eclipse, netbeans စသဖြင့်) က အကောင်းဆုံးဖြစ်တယ်
စာကြောင်းအစကို Tabs သုံးပြီးခြားမယ် Spaces သုံးပြီးခြားမယ် ကွဲကြတာ
စာကြောင်းအဖွင့်အပိတ် “{” တွေ ဘယ်လိုနေရာချမယ်
စာကြောင်းတိုင်း semicolumn နဲ့ဆုံးမယ်
အင်္ဂလိပ်စာလုံးအက္ခရာအကြီးနဲ့စရေးမယ် အသေးနဲ့စရေးမယ်
စသဖြင့် ကျုပ်မှာကျုပ်အကြိုက်တွေရှိသလို ခင်ဗျားမှာလည်း ခင်ဗျားအကြိုက်ရှိမယ်

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

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

ကုဒ်layoutကို သေချာမစဉ်းမစားပဲ အာရုံစိုက်မိတဲ့အကြောင်းကတော့ ရှေးရိုးစွဲအလုပ်မဖြစ်တဲ့ ကုဒ်စစ်ဆေးမှုတွေကြောင့်ပါ
ကုဒ်တပိုင်းလောက်စစ်ဖို့ပေးလိုက်ရင် Presentation အသွင်အပြင်တင်ပြပုံ ယိုပေါက်များကို ရွေးမိတတ်ကြပါတယ်
အထူးသဖြင့် သာမာန်သာလျှံကာဖတ်ပြီးစစ်တဲ့အခါ ကုဒ်layout ကိုပဲ အဓိကထား ရွေးကြည့်တတ်ကြလို့ပါ
သင်က သိပ်အသုံးဝင်တဲ့ မှတ်ချက်တွေရေးတတ်တယ်လို့ သင်ထင်တယ်ပေါ့
“[“ bracket တခုလောက်နေရာမှားထားမိတာနဲ့ ဒီဇိုင်းအလွဲတွေကို သင် မျက်စိရှမ်းမိတာမျိုးဖြစ်တတ်ပါတယ်
ကုဒ်များများစစ်ဆေးရတာနဲ့အမျှ မြန်မြန်အပြီးသတ်ချင်ပြီး ဒီလိုအမှုမဲ့အမှတ်မဲ့အမှားတွေ ပိုပေါ်ပေါက်လာတတ်တယ်

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

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

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

ကုဒ်တွေကို ရှင်းလင်းတဲ့ပုံစံနဲ့ ဖော်ပြဖို့အရေးကြီးပါတယ် အလှသက်သက်မဟုတ်ပါ အမှားအယွင်းကင်းစေဖို့ဖြစ်ပါတယ် ဥပမာအနေနဲ့ C language နဲ့ရေးထားတဲ့ အောက်ပါကုဒ်ကို ကြည့်ပါ

BBP_CH2_S01
ရေးတဲ့သူက ဘာဖြစ်စေချင်တာလဲ သိတယ်မဟုတ်လား exit(0); ပရိုဂရမ်မှထွက််ပါ ဆိုတဲ့ကုဒ်စာကြောင်းကို စစ်ထားတာ မမှန်မှ ထွက်စေချင်တာပါ
ဒါပေမဲ့လည်း ဖော်ပြထားပုံအရ ဆိုလိုချင်တာကို ၀ှက်ထားသလိုဖြစ်နေပါတယ် ဒီကုဒ်ကို run လိုက်တိုင်း ပရိုဂရမ်က ထွက်သွားနေမှာပါ

layout ရွေးချယ်မှုအမှားကနေ ဒီလိုအခက်တွေ့စေတဲ့ကုဒ်တွေကို ပေါ်ပေါက်လာစေမှာပါ။ ဒီဥပမာက ဒီစာအုပ်ဖတ်ကောင်းအောင် ဖော်ပြထားယုံမဟုတ်ပါဘူး လက်တွေ့လောကမှာလည်း ဒီထက်ဆိုးရွားတဲ့အမှားတွေဖြစ်ဘူးပါတယ် Apple ရဲ့ သိပ်မကျော်ကြားလှတဲ့ 2014 goto fail လုံခြုံရေးချို့ယွင်းချက်ဟာ SSL/TLS လုပ်ဆောင်ဖို့ရေးထားတဲ့ ဒီလို layout အမှားမျိုးကြောင့် ဖြစ်ပေါ်ခဲ့တာပါ
Variable အမည်ပေးတာတွေကနေလည်း အမှားအယွင်းများစွာဖြစ်စေနိုင်ပါတယ်
အမည်ပေးမှားခြင်းကနေ စိတ်ပျက်စေယုံမက အန္တရာယ်လည်းရှိစေမှာပါ

ကဲအောက်ကပေးထားတဲ့ Variable နာမည်တွေထဲမှာ ဘယ်ဟာကဆိုးရွားပါသလဲ
BBP_CH2_S02
numberOfGreenWidgets ဆိုတာ Variable တခု ဟုတ်ပါသလား
ဘယ်နှစ်ခုရှိလဲရေတွက်တာသိမ်းဖို့ ပေးထားသလိုဖြစ်နေပြီး အမှန်အမှားဆိုတဲ့ Boolean type နဲ့ မသင့်တော်ဘူးမို့လား
Name အမည်ဆိုတဲ့ variable ကလည်း widget အမည်သိမ်းဖို့မဟုတ်ပဲ ဘယ်အရောင်လဲသိမ်းဖို့ဖြစ်ပါတယ်
turnGreen() ဆိုတဲ့ function နဲ့ အရောင်ပြောင်းပြီးမှတ်ဖို့ပါ
ဒါကြောင့်ပေးထားတဲ့အမည်က အမှတ်မှားစေပါတယ်
Turngreen() ကိုအောက်ပါအတိုင်းရေးထားပါတယ်

BBP_CH2_S03
ခုနကပေးထားတဲ့ နာမည်တွေဟာ အမှားတွေချည်းပါပဲ

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

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

မညီညာတဲ့ layout နဲ့ရေးခြင်းမျိုး ရှုပ်ထွေးလှတဲ့ Variable နာမည်တွေနဲ့ ရေးထားတာမျိုးနဲ့ကြုံရင် ကုဒ်အရည်အသွေးမကောင်းတာ သေချာပါပြီ
ရေးတဲ့သူက layout ကို တောင် သေချာစီမရေးတာ ဒီဇိုင်းကောင်းဖို့ သေချာစမ်းဖို့စတဲ့ တခြားအရည်အသွေးကောင်းဖို့လုပ်ရတာတွေနဲ့ ပိုဝေးပြီပေါ့

တဦးနဲ့တဦးဆက်သွယ်ရေးအတွက်

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

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

ဥပမာကောင်းကတော့ “comment box” ပုံစံ မှတ်ချက်ပေးတာမျိုးပါ
တချို့ပရိုဂရမ်မာတွေက အောင်လံတံခွန်လိုဘောင်ခတ်ပြီး မှတ်ချက်ပေးရတာကြိုက်ကြတယ်

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

Layout ပုံစံ

အရေးရှင်းချင်ရင် အတွေးရှင်းဖို့လိုပါတယ် – Johann von Goethe
ကုဒ်layout နဲ့ သက်ဆိုင်တာတွေကတော့ စာကြောငး်အတွင်းသို့တိုးရေးခြင်း (indentation) ၊ operator ( + – * / စသည်) တွေဘေးမှာ space ခြားခြင်း ၊ အင်္ဂလိပ်အက္ခရာကြီးဖြင့်ရေးခြင်း ၊ အတွင်းတိုးရေးတဲ့အခါ tab သုံးမှာလား space သုံးမှာလား အငြင်းပွားစရာ စသဖြင့်ပါ၀င်ပါတယ် အဲ့ဒီတခုချင်းဆီရွေးချယ်တဲ့အထဲက သင်ဘာကိုရွေးရွေး ဘာကြောင့်ရွေးတယ်ဆိုတဲ့အကြောင်းရင်းရှိရပါမယ် ဘယ်layout နဲ့ရေးဖို့ရွေးရွေး အဲ့layout က သင့်ကုဒ်ရဲ့ပုံသဏ္ဌန်ပိုကောင်းစေတယ် ဆိုလိုရင်းရည်ရွယ်ချက်ကို ပိုပီပြင်စေတယ်ဆို သိပ်ကောင်းတာပေါ့
ပုံစံတကျရေးပါ
စကားပြေရေးသလို ကုဒ်ကိုရေးပါ
သင်ခန်းစာ၊စာပိုဒ်၊စာကြောင်းတွေဆိုပြီး ခွဲထုတ်လိုက်ပါ
အကြောင်းအရာတူတာတွေတစုတစည်းထားပါ
အကြောင်းအရာမတူတာတွေ သပ်သပ်စီခွဲထားပါ
Functions တွေကို သင်ခန်းစာတခုနဲ့တူတယ်လို့ မှတ်ပါ
သင်ခန်းစာတခုချင်းဆီထဲမှာ ကွဲပြားတာနည်းပြီး ဆက်နွယ်တဲ့ကုဒ်တွေရေးပါ
သင်ခန်းစာတွေထဲ စာပိုဒ်တွေဖြစ်လာစေဖို့ စာကြောင်းအလွတ်တွေဖြင့် ခြားထားပါ
စာပိုဒ်တပိုဒ်လိုသဘာဝကျကျခွဲနိုင်မှာသာ စာကြောင်းအလွတ်ကိုထည့်ပါ
ဒီနည်းလမ်းဟာ ပုံသဏ္ဌာန်ကောင်းရစေဖို့ ကူညီပေးပါတယ်

BBP_CH2_S05
ကုဒ်တွေကို ဘယ်လိုစီထားလဲဆိုတာ အရေးကြီးပါတယ်
သင့်ကုဒ်တွေကို ဖတ်မည့်စာဖတ်သူဘက်က စဉ်းစားပါ
အရေးအကြီးဆုံးဖြစ်တာတွေကို အရင်ဆုံးထားပါ
API ဖတ်မယ့်သူတွေအတွက် လက်တွေ့အသုံးများတာတွေ အရင်ထားပါ
ဖတ်မည့်သူအတွက် အရေးကြီးတာကို သင့် class definition ရဲ့ အပေါ်ဆုံးပိုင်းမှာရေးပါ
Public fields/function စတဲ့ public နဲ့ဆိုင်တာတွေ အရင်ရေးပြီး Private နဲ့ဆိုင်တာတွေနောက်မှာရေးပါ
Object မှာ ခေါ်သုံးရတဲ့ Method တွေမတိုင်ခင် Object ဘယ်လို create လုပ်ရလဲ အရင်ဆုံးရေးပါ
အောက်ဖော်ပြပါ Class ရေးပုံမျိုးဖြစ်ပါတယ်

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

ညီညာမှု

ဘယ် layout စတိုင် နဲ့ ရေးမလဲဆိုပြီး အရွေးခက်နေတာမျိုးရှောင်ပါ
တခုခုကို ရွေးချယ်ပါ တညီတညာအစဉ်တစိုက်သုံးပါ
သင့် ပရိုဂရမ်းမင်းဘာသာစကားနဲ့တူညီတာမျိုး သဘာဝကျတာမျိုးရွေးပါ standard library တွေရဲ့ စတိုင်မျိုးအသုံးပြုပါ
သင့်အဖွဲ့ထဲကတခြားလူတွေရဲ့ layoutနဲ့ ပုံစံတူ ရေးပါ
သင့်ရဲ့ကိုယ်ပိုင်စတိုင်က ပိုလှ ပိုကောင်းလို့ဆိုပြီးထင်ယုံနဲ့ သင့်စတိုင်ကိုမသုံးပါနှင့်
သင့်ရဲ့ပရော့ဂျက်မှာ တညီတညာသုံးတာမျိုးမရှိရင် Coding Standard ကုဒ်စံသတ်မှတ်ချက် အတိုင်း (သို့) Style Guide မှာဖော်ပြထားတဲ့အတိုင်း သုံးပါ
ဒီလိုစည်းကမ်းချက်တွေကလည်း ရှည်လျားထွေပြားတဲ့ စာရွက်ရှည်ကြီးဖြစ်စရာမလိုပါဘူး
သင့်အဖွဲ့သားတွေ လိုက်နာနိုင်တဲ့ layout သတ်မှတ်ချက်တွေဆို လုံလောက်ပါတယ်
ကုဒ် စံသတ်မှတ်ချက်ဆိုတို်င်းလည်း သင့်အဖွဲ့သားတွေကလည်း နှစ်ဦးနှစ်ဖက်သဘောတူတာမျိုးဖြစ်ရပါမယ် ဖိအားပေးရေးခိုင်းတာမျိုးမဖြစ်စေရပါဘူး
တကယ်လို့ တခြား file တခုခုကိုလုပ်ရပြီ အဲ့fileက သင့်ပရော့ဂျက် layout ပုံစံအတိုင်းမဟုတ်ရင် အဲ့ဒီ file ရဲ့ layout ပုံစံအတိုင်း လိုက်နာလုပ်ဆောင်ပါ
သင့်အဖွဲ့ရဲ့ IDE တွေ ကုဒ်ရေးတဲ့ editor တွေကိုလညး် တညီတည်းချိန်ညှိထားပါ
Tab ခုန်တဲ့အကွာအဝေးကိုညီတူထားပါ
မှတ်ချက်ရေးတဲ့ layout ကိုရော စာကြောင်းအဖွင့်အပိတ် “{“ တွေကိုရော တူညီစွာသုံးပါ
စာကြောင်းအဆုံးသတ်အက္ခရာ line ending ထားရှိပုံတွေလည်း တူပါစေ
Cross platform project တွေအတွက် မတူညီတဲ့ ကွန်ပျူတာမျိုးတွေမှာ ပြိုင်တူရေးကြရင် ဒီလိုစာကြောင်းအဆုံးသတ်အက္ခရာက ပိုအရေးကြီးပါတယ်
သင်ဒီလို ညီညာအောင် ကြိုးစားမရေးရင် သင်တို့ကုဒ်တွေက မတူကွဲပြားပြီး ဆိုးရွားလှတဲ့ကုဒ်တွေ သင်ရေးထုတ်နေမှာပါ

Space စစ်ပွဲ

ကုဒ်တွေရဲ့ တင်ပြပုံ ပုံသဏ္ဌာန်ကို အရေးမထားတဲ့ ပရိုဂရမ်မာတွေနဲ့ ကျုပ် ပရော့ဂျက်တခုအတူလုပ်ဘူးပါတယ်
ကုဒ်တွေက ရှုပ်ထွေးလှပြီး မညီမညာနဲ့ စိတ်ပျက်စရာကောင်းပါတယ်
ကုဒ် စံသတ်မှတ်ချက်ထားဖို့ ကျုပ်သူတို့ကို တောင်းဆိုလိုက်ပါတယ်
ပရိုဂရမ်မာအားလုံးက အကြံကောင်းအဖြစ်လက်ခံသဘောတူကြပြီး (variable/class စတဲ့) နာမည်တွေ ဘယ်လိုပေးမယ် ဘယ် layout သုံးမယ် ဘယ်လို folder အဆင့်ဆင့်ထားမယ်ဆိုတာ အားလုံးသဘောတူညီချင်ကြပါတယ်
ဒါဟာ ကြီးကျယ်တဲ့ခြေလှမ်းအစပါ ကုဒ်တွေက ရှင်းရှင်းလင်းလင်းဖြစ်လာပါတယ်
ဒါပေမဲ့လည်း သဘောဘယ်လိုမှမညီနိုင်တဲ့အကြောင်းတခုတော့ရှိပါတယ်
သင်ခန့်မှန်းမိမှာပါ Tab သုံးမလား Space သုံးမလားဆိုတာပေါ့
အားလုံးနီးပါက Space လေးခါနဲ့ စာကြောင်းအစခြားထားတာကို သဘောတူကြတယ်
တယောက်ကတော့ လုံးဝ Tab မှ Tab ပဲ Tab က ပိုကောင်းတယ်ပဲ သဘောရပါတယ်
သူက Space သုံးဖို့ငြင်းတယ် စောဒကတက်တယ် သူရေးတဲ့ပုံစံပြင်ဖို့လည်း ငြင်းတယ်
ခုထိလည်း သူငြင်းနေဦးမလားပဲ
ကျုပ်တို့ သိသာထင်ရှားတဲ့တိုးတက်မှုတွေရရှိနေတာရော မလိုအပ်ပဲသဘောထားကွဲလွဲတာကို ရှောင်ချင်တာနဲ့ပဲ ဒီကိစ္စကို ဘေးဖယ်ထားခဲ့ကြတယ်
ကျုပ်တို့အားလုံးက Spaces သုံးတယ် သူက Tabs သုံးတယ်
အဆုံးသတ်ရလာဒ်ကတော့ ကုဒ်တွေက စိတ်ပျက်ဖို့ကောင်းပြီး လုပ်ရကိုင်ရခက်ပါတယ် ပြင်ရတာလည်း အတော်ခက်ပြီး တခါတလေ cursor က space တခုစာရွေ့ပြီး တခါတလေ tab တခုစာခုန်နေပါတော့တယ် tab အဆုံးသတ်ကို သေချာခြားထားရင် တချို့ Editor တွေမှာကောင်းကောင်းပြနိုင်ပေမယ့် တချို့ Editor တွေမှာတော့ တရွဲ့တစောင်းနဲ့ ကြည့်ရဆိုးစွာ ပြနေပါတယ်

အမည်ပေးခြင်း
ကျွနု်ပ်က စကားလုံးတလုံးကို မလေးမစားအထင်သေးတဲ့အသံနဲ့ ပြောရင် အဲ့စကားလုံးက ကျွနု်ပ်ဆိုလိုချင်တဲ့အတိုင်း အဓိပါ္ပယ်ဆောင်ပါတယ် အပိုအလိုမရှိပါဘူး – Lewis Caroll
Variables, Function, Type စသဖြင့် ကျုပ်တို့ အမည်တွေအများကြီးပေးကြရပါတယ်
ပိုအရေးကြီးတဲ့ files တွေ ပရော့ဂျက်တွေ ပရိုဂရမ်တွေကိုလည်း အမည်ပေးကြရပါတယ်
အများသုံး Public API တွေမှာ အမည်ပေးရတာ ပိုပြီး ရွေးကြရပါသေးတယ် ဘာလို့လဲဆိုတော့ ထုတ်ပြီးသား လူသုံးပြီးသား API တွေဆို အမည်တွေက ကျောက်သားလိုခိုင်မြဲသွားပြီး ပေးပြီသားအမည်ကို ပြန်ပြင်ရခက်လွန်းလို့ပါ
Object တခုက ဘာလဲဆိုတာ အမည်နဲ့တင်ဖော်ထုတ်နိုင်ပါတယ် အမည်က သူ့ရဲ့အပြုအမူနဲ့ ဘယ်လိုသုံးဖို့ရည်ရွယ်တယ်ဆိုတာ ဖော်ပြပေးနိုင်တယ်
အမည်ပေးမှားတဲ့အမည်တခုက အင်မတန်ရှုပ်ထွေးစေပါတယ်
ကောင်းတဲ့အမည်တခုကတော့ ရှင်းလင်းမှန်ကန်စွာဖော်ပြတတ်ပါတယ်
သင်ဘာကိုဆိုလိုချင်လဲအတိအကျသိမှာသာ အမည်ပေးလို့ရပါတယ်
သင်ဆိုလိုချင်တာကို ရှင်းရှင်းလင်းလင်းမသိပဲ ဘယ်လိုသုံးရမလဲရှင်းရှင်းလင်းလင်းမသိပဲ အမည်ပေးရမလွယ်ပါဘူး

မလိုအပ်ပဲသုံးတာတွေ ရှောင်ပါ

အမည်ပေးတဲ့အခါ မလိုအပ်တာတွေကိုရှောင်ပါ

BBP_CH2_S07
numberofWidgets ဆိုတာ မလိုအပ်ပဲ ရှည်လျားလွန်းပါတယ်
Widget ဆိုတဲ့စာလုံးကို ထပ်ကာထပ်ကာသုံးထားပါတယ်
ဒီလိုရှည်တဲ့အတွက် ကုဒ်က ပိုငြီးငွေ့ဖို့ကောင်းပြီး ဖတ်ရခက်လာပါတယ်
ဒီ Method က ဘယ်နှစ်ခုရှိသလဲဆိုတဲ့ size ကိုပြန်ပေးချင်တာဖြစ်တဲ့အတွက် size() လို့ လွယ်လွယ်ကူကူ ခေါ်လို့ရပါတယ် ဘာမှရှုပ်ထွေးနေစရာမလိုတော့ပါဘူး
ထပ်ကာထပ်ကာ မလိုအပ်ပဲသုံးတဲ့ စာလုံးတွေရှောင်ပါ
တခါတုန်းက ကျုပ် project တခုမှာ DataObject လို့ခေါ်တဲ့ class တခုကို တွေ့ဘူးတယ် မလိုအပ်ပဲ ရှုပ်ထွေးစရာကောငး်တဲ့ နာမည်တခုပါပဲ
“ရှင်းလင်းစွာပေးပါ”
အနှစ်ချုပ်လွန်းတာထက် ရှင်းလင်းစွာအမည်ပေးမှုကို ရွေးပါ
ကီးဘုတ်ရိုက်ရသက်သာယုံ အမည်တွေကို တိုတိုမပေးပါနှင့်
Variable အမည်တွေကို သင်ရိုက်တဲ့အကြိမ်ထက် ဖတ်တဲ့အကြိမ်က ပိုများပါတယ်
Loop တွေမှာသုံးတဲ့ loop ဘယ်နှကြိမ်လည်းရေတွက်တဲ့အမည်တွေဆိုရင်တော့ တိုတိုလေးပေးပေါ့ ဖတ်ရပိုလွယ်တာပေါ့
ဘယ်နေရာအတွက်သုံးမယ့် variable လည်းပေါ်မူတည်ပြီး ပေးပါ
လျှို့ဝှက်နက်နဲတဲ့အမည်တွေ ပေးဖို့ မလိုပါဘူး ကြီးကြီးကျယ်ကျယ်စာလုံးတွေ အင်္ဂလိပ်စကားလုံးတွေရဲ့ ထိပ်ဆုံးအက္ခရာတွေပဲသုံးပြီး အတိုကောက်အမည်ပေးတာမျိုးရှောင်ပါ

သဘာဝကျကျ အမည်ပေးပါ

သင့် ပရိုဂရမ်ဘာသာစကားမှာသုံးတဲ့ အက္ခရာအကြီးအသေးပုံစံကို အသုံးပြုပါ
ပရိုဂရမ်ဘာသာစကားတခုမှာ တကယ်အားကောင်းတဲ့အမည်ပေးခြင်းတွေ ရှိတတ်လို့ သင့်မှာအကြောင်းပြချက်ခိုင်လုံမှသာ ချိုးဖောက်ပါ
ဥပမာအားဖြင့်
· C programming ရဲ့ macros တွေက အများအားဖြင့် အင်္ဂလိပ်အက္ခရာအကြီးနဲ့စပေးလေ့ရှိပါတယ်
· Types တွေ (ဥပမာ Class) ကို အကြီးနဲ့ပေးလေ့ရှိပြီး methods နဲ့ variables တွေကို အသေးနဲ့စပေးလေ့ရှိပါတယ်
ဒါအများသုံးကြတဲ့ပုံစံဖြစ်ပြီး သင်ချိုးဖောက်မယ်ဆို သင့်ကုဒ်က ဖတ်ရရှုပ်စေမှာပါ
“တိကျမှန်ကန်စွာ အမည်ပေးပါ”
သင်ပေးတဲ့အမည်တွေက တိကျမှန်ကန်ပါစေ
Array လိုသုံးမယ့် type တခုကို WidgetSet ဆိုပြီး Set အစု အနေနဲ့ အမည်မပေးပါနဲ့
မတိကျမမှန်ကန်ပဲအမည်ပေးရင် သင်ဖော်ပြတဲ့ typeရဲ့ အပြုအမူ ၀ိသေသလက္ခဏာတွေကို ဖတ်မည့်သူက လွဲမှားစွာမှတ်ယူနိုင်ပါတယ်
မညီမညာဖြစ်တဲ့ကုဒ်တွေနဲ့ကျုပ်တို့မကြာခဏကြုံကြရပါတယ်
အဲ့လိုကုဒ်တွေနဲ့ အလုပ်လုပ်ရရင် သတိထားပါ
တကယ်လို့ သင်ကမဖြစ်မနေ သေသပ်ရှင်းလင်းသွားအောင်လုပ်ရမယ်ဆိုလည်း တခြားတွက်ချက်မှု လုပ်ဆောင်ချက်ပြင်ဆင်မှုတွေနဲ့ တပြိုင်တည်းမလုပ်ပါနဲ့
ကုဒ်အသွင်အပြင် ပြင်ထားတာတွေကို source control ထဲ သီးသန့်တခေါက်သက်သက်ထည့်ပါ ပြီးမှ တခြားလုပ်ဆောင်ချက်တွေကို ပြင်ဆင်ပါ
အဲ့တာနှစ်ခုကိုရောလုပ်ရင် တော်တော်ရှုပ်ထွေးသွားစေပါလိမ့်မယ် ကုဒ် layout ပိုင်းအပြင်အဆင်က လုပ်ဆောင်မှုပိုင်းပြင်ဆင်တာကို အမှားအယွင်းပါစေနိုင်ပါတယ်
မှတ်ရန်။ ။ အသွင်အပြင်ပြင်တာနဲ့ လုပ်ဆောင်ချက်ပြင်တာကို တပြိုင်တည်းမလုပ်ပါနဲ့ source control ထဲကို သီးခြား version အဖြစ် ထည့်ပါ
Layout style တခုရွေးပြီးတာနဲ့ တသက်လုံးအဲ့တာပဲသုံးရမယ် မဆိုလိုပါ
ရွေးထားတဲ့ Layoutက သင့်ကုဒ်တွေကိုု ဘယ်လိုအကျိုးသက်ရောက်လဲ အမြဲစောင့်ကြည့်ပါ
သင်ဖတ်ရတဲ့ တခြားကုဒ်တွေဆီကလည်း သင်ယူပါ
အတွေ့အကြုံများလာတဲ့နဲ့အမျှ Layout ပိုင်းကို လိုအပ်သလိုပြင်ဆင်ပါ
ကျုပ်ရဲ့ အသက်မွေးဝမ်းကျောင်းဘဝမှာ ကျုပ်ကုဒ်ရေးတဲ့ပုံစံကို ဖြည်းဖြည်းချင်းပြင်ခဲ့တယ် ပိုညီညာပြီး ပိုပြင်ရလွယ်တဲ့ layout မျိုးဆီ ပြောင်းလာခဲ့တယ်
ကုဒ်format တွေပြင်ပေးတဲ့ ညှိပေးတဲ့ tools တွေလည်းရှိပါတယ် စမ်းသုံးကြည့်လို့ရပေမယ့် လက်တွေ့အသုံးဝင်ဖို့ခက်ပါတယ် လက်တွေ့ကုဒ်တွေရဲ့ အသွင်အပြင်ကို ပြင်ဖို့ layout tools တွေက ပြင်ပေးဖို့မလွယ်ပါဘူး

 

နိဂုံး

ကုဒ်တွေဘယ်လိုပုံသဏ္ဌာန်နဲ့ရေးမယ်ဆိုတာ အငြင်းပွားနေကြတာ ရပ်လိုက်ပါ သင့်ပရော့ဂျက်အတွက် သင့်လျော်မယ့် layout style ကို အသုံးပြုပါ
Layout ပုံစံကောင်းတွေမှာ ဘာတွေပါ၀င်မလဲ ဘာကြောင့်ပါ၀င်သလဲဆိုတာ တွေးတောထားပါ
အမြဲသင်ကြားနေပြီး တခြားလူတွေရဲ့ကုဒ်တွေကိုဖတ်ရင်း အတွေ့အကြုံအမြဲယူနေပါ
သင့်ကုဒ်တွေကို ညီညာစေဖို့ ရှင်းလင်စေဖို့ အမြဲကြိုးစားနေပါ
“မေးခွန်းများ”
· သင့်ကုမ္ပဏီရဲ့ စံသတ်မှတ်ချက်ကို လိုက်နာဖို့ ကုဒ်အဟောင်းတွေရဲ့ layout ပုံစံကို သင်ပြင်သင့်လား ဒါမှမဟုတ် နဂိုရေးတဲ့သူရဲ့ပုံစံအတိုင်းထားသင့်လား ဘာကြောင့်ပါလဲ
· Code reformat tool ကုဒ်ပြန်စီတဲ့ tool တွေက အသုံးဝင်ပါသလား သင်သုံးတဲ့ ပရိုဂရမ်မင်းဘာသာစကားအပေါ်ဘယ်လောက်မူတည်နေပါသလဲ
· Code ဒီဇိုင်းကောငး်တာနဲ့ Code တင်ပြပုံကောင်းတာ ဘာကွာလဲ ဘယ်ဟာက ပိုအရေးကြီးလဲ
· သင်ရဲ့ပရော့ဂျက်ကုဒ်တွေက ညီညာပါသလား မညီရင် ဘယ်လိုပြုပြင်သင့်လဲ
· ပရိုဂရမ်ဘာသာစကားတခုရဲ့ layout ပုံစံနဲ့ အမည်ပေးပုံပေးနည်းတွေလိုက်နာဖို့ အရေးကြီးတယ်ဆိုတာ မှန်ပါသလား ဒါမှမဟုတ်ကိုယ့်အဖွဲ့ရဲ့ပုံစံအတိုင်းပေးမှ ပိုမိုကွဲပြားမှာပါလား
· ကုဒ်တွေကို အရောင်ခွဲခြားဖော်ပြပေးနိုင်တဲ့ Editor တွေကိုသုံးတာနဲ့ ကုဒ်တွေကို အရောင်နဲ့ခွဲခြားလို့ရယုံနဲ့ ကုဒ်တွေရဲ့ အသွင်အပြင် layout ပုံစံကို အလေးထားစရာမလိုတော့ဘူးလား

 

လေးစားစွာဖြင့်
စောအေးချမ်း

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