‫ﺑﺮﻧﺎﻣﻪ ﻧﻮﯾﺴﯽ اﺳﺘﺎﻧﺪارد‬

‫ﺑﻬﻤﻦ ﻋﺮبرﺿﺎﯾﯽ – ﺗﺎﺑﺴﺘﺎن ‪95‬‬

 ‫‪2‬‬ ‫ﺑﺮﻧﺎﻣﻪﻧﻮﯾﺴﯽ‬

‫ﻓﻬﺮﺳﺖ ﻣﻄﺎﻟﺐ‬

‫ﺻﻔﺤﻪ‬
‫ﻋﻨﻮان‬

‫ﻣﻘﺪﻣﻪ ‪4 ..................................................................................................................................................................................‬‬

‫ﻣﺘﻐﯿﺮﻫﺎ‪6 ................................................................................................................................ ................................‬‬ ‫‪1‬‬

‫ﻧﺤﻮه ﮐﺪﻧﻮﯾﺴﯽ ‪13 ...............................................................................................................................................‬‬ ‫‪2‬‬

‫ﺗﻮﺿﺤﯿﺎت ‪26 .........................................................................................................................................................‬‬ ‫‪3‬‬

‫ﺗﻮﺻﯿﻪﻫﺎي ﺑﺮﻧﺎﻣﻪ ﻧﻮﯾﺴﯽ ‪28..............................................................................................................................‬‬ ‫‪4‬‬

‫‪3‬‬ ‫ﺑﺮﻧﺎﻣﻪﻧﻮﯾﺴﯽ‬
 ‫‪4‬‬ ‫ﺑﺮﻧﺎﻣﻪﻧﻮﯾﺴﯽ‬

‫ﻣﻘﺪﻣﻪ‬

‫در اﯾﻦ ﮐﺘﺎب اﺳﺘﺎﻧﺪارد ﮐﺪ ﻧﻮﯾﺴﯽ زﺑﺎن ‪ C‬و ‪ C++‬ﻣﻌﺮﻓﯽ ﻣﯽﺷﻮد‪ .‬ﻣﻨﻈﻮر از اﺳﺘﺎﻧﺪارد ﮐﺪ ﻧﻮﯾﺴﯽ اﯾﺠﺎد روﯾﻪاي‬
‫ﯾﮑﺴﺎن ﺟﻬﺖ ﻧﻮﺷﺘﻦ ﻣﺘﻦ ﮐﺪ ﻣﯽﺑﺎﺷﺪ ﺑﻪ ﮔﻮﻧﻪاي ﮐﻪ ﻇﺎﻫﺮ ﮐﺪﻫﺎي ﻣﺨﺘﻠﻒ ﻧﻮﺷﺘﻪ ﺷﺪه در ﮔﺮوه ﺑﺮﻧﺎﻧﻪﻧﻮﯾﺴﯽ‬
‫ﯾﮑﺴﺎن ﺑﺎﺷﺪ‪.‬‬

‫ﭼﺮا ﺑﺎﯾﺪ اﺳﺘﺎﻧﺪارد ﮐﺪ ﻧﻮﯾﺴﯽ را رﻋﺎﯾﺖ ﻧﻤﻮد؟‬

‫ﺑﻪ ﺟﺮات ﻣﯽﺗﻮان ادﻋﺎ ﻧﻤﻮد ﮐﺪي ﮐﻪ اﻓﺮاد ﻣﯽﻧﻮﯾﺴﻨﺪ ﻫﻤﺎﻧﻨﺪ دﺳﺘﺨﻂ اﻓﺮاد ﻣﯽﺑﺎﺷﺪ و ﭘﺮواﺿﺢ اﺳﺖ ﮐﻪ ﮐﺴﯽ‬
‫دﺳﺘﺨﻂ ﺧﺮﭼﻨﮓ ﻗﻮرﺑﺎﻏﻪاي را ﻧﻤﯽ ﭘﺴﻨﺪد ﻟﺬا اﻓﺮاد ﻫﻤﻮاره ﺑﻪ دﻧﺒﺎل داﺷﺘﻦ دﺳﺘﺨﻄﯽ زﯾﺒﺎ ﻫﺴﺘﻨﺪ‪ .‬در اﯾﻦ‬
‫راﺳﺘﺎ روشﻫﺎي ﻣﺨﺘﻠﻔﯽ ﺟﻬﺖ رﺳﻢاﻟﺨﻂ وﺟﻮد دارد ﭼﻪ در زﺑﺎن ﻓﺎرﺳﯽ ﭼﻪ در زﺑﺎنﻫﺎي دﯾﮕﺮ ﮐﻪ ﻫﻤﻪ آﻧﻬﺎ‬
‫ﺳﻌﯽ ﻣﯽﮐﻨﻨﺪ روﺷﯽ زﯾﺒﺎ را ﺑﺮاي رﺳﻢاﻟﺨﻂ ﻣﻌﺮﻓﯽ ﮐﻨﻨﺪ‪.‬‬

‫در ﺑﺮﻧﺎﻣﻪﻧﻮﯾﺴﯽ ﻧﯿﺰ ﻫﺪف اﺳﺘﺎﻧﺪارد ﮐﺪ ﻧﻮﯾﺴﯽ ﭼﻨﯿﻦ ﻣﯽﺑﺎﺷﺪ‪ .‬ﭘﺲ ﻫﻤﺎﻧﻈﻮر ﮐﻪ ﺗﻨﺪﻧﻮﯾﺴﯽ ﺗﺎ ﺣﺪ زﯾﺎدي ﺑﺎﻋﺚ‬
‫ﻧﺎﺧﻮاﻧﺎ ﺷﺪن ﻣﯽﺷﻮد در ﺑﺮﻧﺎﻣﻪﻧﻮﯾﺴﯽ ﻧﯿﺰ ﮐﺪ ﻧﻮﯾﺴﯽ ﺳﺮﯾﻊ و ﺑﺪون رﻋﺎﯾﺖ اﺳﺘﺎﻧﺪارﻫﺎ ﺑﺎﻋﺚ ﻣﯽﺷﻮد ﮐﺪي ﺑﻪ‬
‫دﺳﺖ آﯾﺪ ﮐﻪ ﺷﺎﯾﺪ ﺑﺮاي ﺧﻮد ﺑﺮﻧﺎﻣﻪﻧﻮﯾﺲ ﻧﯿﺰ ﺑﻌﺪ از ﻣﺪﺗﯽ ﻗﺎﺑﻞ ﻓﻬﻢ ﻧﺒﺎﺷﺪ و ﯾﺎدآور ﺣﮑﺎﯾﺖ ﻧﻮﯾﺴﻨﺪه ﻧﺎﻣﻪاي‬
‫ﺷﻮد ﮐﻪ ﻧﻪ دﯾ ﮕﺮان ﺗﻮاﻧﺴﺘﻨﺪ ﻧﺎﻣﻪ را ﺑﺨﻮاﻧﻨﺪ ﻧﻪ ﺧﻮد او؛ ﭘﺲ ﻫﻤﻮاره ﻧﺎﻣﻪ را ﺑﻪ ﮔﻮﻧﻪاي ﺑﻨﻮﯾﺴﯿﺪ ﮐﻪ ﻋﻼوه‬
‫ﺑﺮ ﺷﻤﺎ دﯾﮕﺮان ﻧﯿﺰ ﺑﺘﻮاﻧﻨﺪ آن را ﺑﺨﻮاﻧﻨﺪ‪.‬‬

‫ﺷﺎﯾﺪ ﺑﺘﻮان ﻣﺰاﯾﺎي زﯾﺮ را ﺑﺮاي رﻋﺎﯾﺖ اﺳﺘﺎﻧﺪارد ﮐﺪ ﻧﻮﯾﺴﯽ ذﮐﺮ ﻧﻤﻮد‪.‬‬

‫‪ .1‬ﻫﺮ ﺑﺮﻧﺎﻣﻪﻧﻮﯾﺴﯽ ﻣﯽﺗﻮاﻧﺪ ﮐﺪﻫﺎ را ﻓﺎرغ از ﺑﺮﻧﺎﻣﻪﻧﻮﯾﺲ آن ﺑﺨﻮاﻧﺪ‪.‬‬

‫‪ .2‬ﺑﻪ ﺳﺮﻋﺖ ﻣﯽﺗﻮان ﮐﺪﻫﺎي ﻣﻮﺟﻮد را ﻣﻬﻨﺪﺳﯽ ﻣﻌﮑﻮس ﻧﻤﻮد‪.‬‬
‫‪ .3‬در ﻣﺤﯿﻂﻫﺎي ﮔﺮوﻫﯽ اﻓﺮاد ﮐﻤﺘﺮ ﺑﺎ ﻣﺸﮑﻼت ﺑﺮﻧﺎﻣﻪ ﻧﻮﯾﺴﯽ ﻣﻮاﺟﻪ ﻣﯽﺷﻮﻧﺪ‪.‬‬
‫‪ .4‬ﻫﻤﻪ اﻓﺮاد ﮔﺮوه اﻧﮕﯿﺰه ﻣﺸﺘﺮك دارﻧﺪ؛ دﺷﻤﻦ ﻣﺸﺘﺮك اﺳﺘﺎﻧﺪار ﮐﺪﻧﻮﯾﺴﯽ!‬

‫اﻣﺎ رﻋﺎﯾﺖ اﺳﺘﺎﻧﺪارد ﻧﯿﺰ ﻣﻌﺎﯾﺐ زﯾﺮ را ﺑﻪ ﻫﻤﺮاه دراد‪.‬‬

‫اﺳﺘﺎﻧﺪارد ﻣﻌﻤﻮﻻ ﺧﻮب ﻧﯿﺴﺖ ﭼﺮا ﮐﻪ ﻣﻄﺎﺑﻖ اﺳﺘﺎﻧﺪارد ﻣﻦ)ﺑﺮﻧﺎﻣﻪ ﻧﻮﯾﺲ( ﻧﯿﺴﺖ‪.‬‬ ‫‪.1‬‬
‫اﺳﺘﺎﻧﺪارد ﺧﻼﻗﯿﺖ را از ﺑﯿﻦ ﻣﯽﺑﺮد‪.‬‬ ‫‪.2‬‬
‫اﺳﺘﺎﻧﺪارد دﺳﺖ و ﭘﺎ ﮔﯿﺮ اﺳﺖ و ﺳﺮﻋﺖ ﮐﺎر را ﮐﺎﻫﺶ ﻣﯽدﻫﺪ‪.‬‬ ‫‪.3‬‬
‫اﺳﺘﺎﻧﺪارد ﻣﺎﻧﻨﺪ رﯾﯿﺲ ﺧﺸﮏ و ﺳﺨﺖﮔﯿﺮ اﺳﺖ‪.‬‬ ‫‪.4‬‬
 ‫‪5‬‬ ‫ﺑﺮﻧﺎﻣﻪﻧﻮﯾﺴﯽ‬

‫اﻣﺎ ﻋﻠﯿﺮﻏﻢ ﻣﻮارد ﺑﺎﻻ ﺗﺠﺮﺑﻪ ﻧﺸﺎن داده اﺳﺖ ﮐﻪ رﻋﺎﯾﺖ اﺳﺘﺎﻧﺪارد ﻫﻤﻮاره ﺑﺎﻋﺚ ﻧﺘﯿﺠﻪﮔﯿﺮي ﺑﻬﺘﺮ در اﻧﺘﻬﺎي ﮐﺎر‬
‫ﺷﺪه اﺳﺖ‪ .‬ﺑﻪ ﻋﺒﺎرت دﯾﮕﺮ اﮔﺮ ﺷﻤﺎ اﻣﺮوز ﺑﺮاي اوﻟﯿﻦ ﺑﺎر ﺑﺎ اﯾﻦ اﺳﺘﺎﻧﺪارد ﺑﺮﺧﻮرد ﮐﻨﯿﺪ ﻣﺎﻧﻨﺪ ﺧﻮدروﯾﯽ ﻫﺴﺘﯿﺪ‬
‫ﮐﻪ ﺗﺎزه از ﺧﻂ ﺗﻮﻟﯿﺪ ﺧﺎرج ﺷﺪه‪ ،‬اﯾﻦ ﺧﻮدرو ﻣﻤﮑﻦ اﺳﺖ ﺑﺘﻮاﻧﺪ ﺑﺎ ﺳﺮﻋﺖ ﺑﯿﺶ از ‪200‬ﮐﯿﻠﻮﻣﺘﺮ در ﺳﺎﻋﺖ ﺣﺮﮐﺖ‬
‫ﮐﻨﺪ اﻣﺎ در اﺑﺘﺪاي اﻣﺮ ﻫﯿﭻ ﮐﺎرﺑﺮي ﺑﺎ اﯾﻦ ﺗﻮﺟﯿﻪ ﮐﻪ آبﺑﻨﺪي ﺧﻮدرو ﺑﺎﻋﺚ اﺗﻼف وﻗﺖ در ﻣﺴﯿﺮ اﺳﺖ ﺑﺎ ﺳﺮﻋﺖ‬
‫ﺑﺎﻻ ﺷﺮوع ﺑﻪ ﺣﺮﮐﺖ ﻧﻤﯽﮐﻨﺪ و ﻫﻤﻪ ﻫﺰﯾﻨﻪ زﻣﺎن را ﭘﺮداﺧﺖ ﻣﯽﮐﻨﻨﺪ ﺗﺎ ﻋﻤﺮ ﺧﻮدرو را ﺑﺎﻻ ﺑﺒﺮﻧﺪ‪.‬‬

‫اﺳﺘﺎﻧﺪارد ﻧﯿﺰ ﺑﺮاي اﻓﺮاد ﭼﻨﯿﻦ اﺳﺖ ﺧﺼﻮﺻﺎ در ﻣﺤﯿﻂﻫﺎي ﮔﺮوﻫﯽ ﭘﺲ ﺳﻌﯽ ﻧﮑﻨﯿﺪ ﺧﻮدرو ﺻﻔﺮ ﮐﯿﻠﻮﻣﺘﺮ ﺧﻮد‬
‫را ﺑﺎ ﺳﺮﻋﺖ ‪200‬ﮐﯿﻠﻮﻣﺘﺮ در ﺳﺎﻋﺖ آزﻣﺎﯾﺶ ﮐﻨﯿﺪ‪.‬‬

‫ﺑﻨﺎﺑﺮاﯾﻦ آﻧﭽﻪ در اﯾﻦ ﮐﺘﺎب آﻣﺪه ﺑﺎ ﻫﺪف اﻓﺰاﯾﺶ ﮐﺎراﯾﯽ ﺑﺮﻧﺎﻣﻪﻧﻮﯾﺲ و ﻣﺤﺼﻮل اﺳﺖ ﻧﻪ اﯾﺠﺎد روالﻫﺎي ﺑﯿﻬﻮده‬
‫ﻟﺬا ﺳﻌﯽ ﮐﻨﯿﺪ آن را رﻋﺎﯾﺖ ﮐﻨﯿﺪ ﻫﺮ ﭼﻨﺪ ﮐﻪ در اﺑﺘﺪاي ﮐﺎر ﺑﺎﻋﺚ ﮐﻨﺪي ﺑﯿﺶ از ﺣﺪ ﮐﺎر ﺷﻤﺎ ﺷﻮد‪.‬‬

‫در اداﻣﻪ اﺑﺘﺪا درﺑﺎره ﻣﺘﻐﯿﺮﻫﺎي ﺻﺤﺒﺖ ﻣﯽﺷﻮد‪ ،‬ﺳﭙﺲ ﻗﻮاﻧﯿﻦ ﻧﻮﺷﺘﻦ ﮐﺪ ﺑﺮرﺳﯽ ﻣﯽﺷﻮد‪ .‬ﭘﺲ از آن در ﺑﺨﺶ‬
‫‪ 3‬اﺳﺘﺎﻧﺪارد ﺗﻮﺿﯿﺤﺎت ﺗﺸﺮﯾﺢ ﺷﺪه و ﺑﺎﻻﺧﺮه در ﺑﺨﺶ ‪ 5‬ﻧﮑﺎت ﺑﺮﻧﺎﻣﻪﻧﻮﯾﺴﯽ ﺑﯿﺎن ﺷﺪه اﺳﺖ‪.‬‬

‫در اﻧﺘﻬﺎ از ﺧﻮاﻧﺪﮔﺎن ﮔﺮاﻣﯽ ﺗﻘﺎﺿﺎ ﻣﯽﺷﻮد ﻧﻈﺮات ﺧﻮد را درﺑﺎره اﯾﻦ ﮐﺘﺎب ﺑﻪ اﯾﻤﯿﻞ ‪[email protected]‬‬
‫ارﺳﺎل ﮐﻨﻨﺪ‪ .‬ﺑﺪﯾﻬﯽ اﺳﺖ ﻧﻈﺮات ﺷﻤﺎ ﮐﻤﮏ ﺑﺴﯿﺎر زﯾﺎدي در ﺗﮑﻤﯿﻞ اﯾﻦ ﮐﺘﺎب ﺧﻮاﻫﺪ ﻧﻤﻮد‪ .‬ﭘﯿﺸﺎﭘﯿﺶ از‬
‫ﻫﻤﮑﺎري ﺗﻤﺎﻣﯽ ﻋﺰﯾﺰان ﺗﺸﮑﺮ ﻣﯽﺷﻮد‪.‬‬
 ‫‪6‬‬ ‫ﺑﺮﻧﺎﻣﻪﻧﻮﯾﺴﯽ‬

‫‪ 1‬ﻣﺘﻐﯿﺮﻫﺎ‬

‫ﻣﺘﻐﯿﺮﻫﺎ ﻗﻠﺐ ﻫﺮ ﺑﺮﻧﺎﻣﻪ ﻣﯽﺑﺎﺷﻨﺪ‪ .‬ﻣﻄﻤﺌﻦ ﺑﺎﺷﯿﺪ ﻫﯿﭻ ﭼﯿﺰ ﺑﻪ اﻧﺪازه رﻋﺎﯾﺖ ﻗﻮاﻧﯿﻦ ﻣﺘﻐﯿﺮﻫﺎ ﻧﻤﯽﺗﻮاﻧﺪ ﺳﺮﻋﺖ و‬
‫ﻣﺎﻧﺪﮔﺎري ﺑﺮﻧﺎﻣﻪ را ﺗﻀﻤﯿﻦ ﮐﻨﺪ‪ .‬ﻟﺬا اﯾﻦ ﺑﺨﺶ را ﺑﺎ ﺣﻮﺻﻠﻪ ﻣﻄﺎﻟﻌﻪ ﮐﻨﯿﺪ‪.‬‬

‫اوﻟﯿﻦ ﻧﮑﺘﻪ ﻧﺎم ﻣﺘﻐﯿﺮﻫﺎ ﻣﯽﺑﺎﺷﺪ‪ .‬ﻣﻄﻤﺌﻦ ﺑﺎﺷﯿﺪ ﮐﻪ اﮔﺮ در زﻧﺪﮔﯽ روزﻣﺮه ﻧﯿﺰ ﻧﺎم ﻫﺮﺷﯽ‪ ،‬اﺗﻔﺎق و ‪ ...‬ﻣﺘﻨﺎﺳﺐ ﺑﺎ‬
‫آن اﻧﺘﺨﺎب ﻣﯽﺷﺪ ﺧﺼﻮﺻﺎ اﻓﺮاد‪ ،‬زﻧﺪﮔﯽ ﺑﺴﯿﺎر راﺣﺖ ﺑﻮد و ﭘﯿﺸﺮﻓﺖ ﺑﺸﺮ ﺳﺮﯾﻌﺘﺮ ﻣﯽﺷﺪ ﭼﺮا ﮐﻪ ﺷﻤﺎ ﺑﺎ ﺷﻨﯿﺪن‬
‫ﻧﺎم ﻫﺮ ﺷﺨﺺ ﯾﺎ ﻫﺮ اﺗﻔﺎق اﻃﻼﻋﺎت اوﻟﯿﻪ ﻣﻮرد ﻧﯿﺎز را ﺑﻪ دﺳﺖ ﻣﯽآوردﯾﺪ‪ .‬ﺣﺎل ﮐﻪ در دﻧﯿﺎي واﻗﻌﯽ اﻣﮑﺎن ﭘﺬﯾﺮ‬
‫ﻧﺸﺪه اﺳﺖ در دﻧﯿﺎي ﺑﺮﻧﺎﻣﻪ ﻧﻮﯾﺴﯽ اﯾﻦ اﻣﺮ را رﻋﺎﯾﺖ ﮐﻨﯿﺪ‪.‬‬

‫‪ .1‬ﻧﺎم ﻣﺘﻐﯿﺮ را ﻣﺘﻨﺎﺳﺐ ﺑﺎ ﮐﺎرﺑﺮد آن ﺗﻌﺮﯾﻒ ﮐﻨﯿﺪ‪.‬‬

‫ﺳﻌﯽ ﮐﻨﯿﺪ ﻧﺎم ﻣﺘﻐﯿﺮ ﺣﺘﻤﺎ ﺑﯿﺎﻧﮕﺮ ﮐﺎرﺑﺮد آن ﺑﺎﺷﺪ ﺑﻪ ﻣﺜﺎل زﯾﺮ ﺗﻮﺟﻪ ﮐﻨﯿﺪ‪.‬‬

‫;‪int xx = 0‬‬

‫;‪int yy = xx + 1‬‬

‫در اﯾﻦ ﻣﺜﺎل ﻣﺘﻐﯿﺮﻫﺎي ‪ xx‬و ‪ yy‬ﺑﻪ ﻫﯿﭻ وﺟﻪ ﻣﻔﻬﻮم ﻧﻤﯽﺑﺎﺷﻨﺪ‪ .‬اﻣﺎ در ﻣﺜﺎل ﺑﻌﺪ ﭼﻨﯿﻦ ﻧﻤﯽﺑﺎﺷﺪ‪.‬‬

‫;‪int size = 0‬‬

‫;‪int maxSize = size + 1‬‬

‫‪ .2‬ﺗﻤﺎﻣﯽ ﻣﺘﻐﯿﺮﻫﺎ در اﺑﺘﺪاي ﺗﺎﺑﻊ ﺗﻌﺮﯾﻒ ﺷﻮﻧﺪ‬

‫اﮔﺮ ﻗﺎﻧﻮن ‪ 1‬رﻋﺎﯾﺖ ﺷﻮد آﻧﮕﺎه اﯾﻦ ﻗﺎﻧﻮن ﻣﺎﻧﻨﺪ ﮐﺎرت ﺷﻨﺎﺳﺎﯾﯽ ﺗﺎﺑﻊ اﺳﺖ‪ .‬ﺷﻤﺎ ﺑﺎ دﯾﺪن ﻣﺘﻐﯿﺮﻫﺎي ﻣﻮرد اﺳﺘﻔﺎده‬
‫در ﺗﺎﺑﻊ ﺑﻪ راﺣﺘﯽ ﻣﯽﺗﻮاﻧﯿﺪ ﺗﺎ ﺣﺪ زﯾﺎدي اﻟﮕﻮرﯾﺘﻢ و رﻓﺘﺎر ﺗﺎﺑﻊ را ﺣﺪس ﺑﺰﻧﯿﺪ ﭘﺲ ﺳﻌﯽ ﮐﻨﯿﺪ ﮐﺎرت ﺷﻨﺎﺳﺎﯾﯽ‬
‫را در اﺑﺘﺪا ﻧﺸﺎن دﻫﯿﺪ ﻧﻪ در اﻧﺘﻬﺎ‪.‬‬

‫ﻧﮑﺘﻪ دﯾﮕﺮ اﯾﻨﮑﻪ اﯾﻦ اﻣﺮ ﺑﺎﻋﺚ ﻣﯽﺷﻮد ﺧﻮاﻧﺎﯾﯽ ﮐﺪ ﺷﻤﺎ اﻓﺰاﯾﺶ ﯾﺎﺑﺪ و از ﺗﻌﺮﯾﻒ ﻣﺠﺪد ﻣﺘﻐﯿﺮ ﺧﺼﻮﺻﺎ ﻣﺘﻐﯿﺮﻫﺎي‬
‫ﺣﻠﻘﻪ ﺧﻮدداري ﮐﺮده و ﻣﺘﻌﺎﻗﺒﺎ ﺑﺎ ﺧﻄﺎي ﮐﺎﻣﭙﺎﯾﻠﺮ ﻣﻮاﺟﻪ ﻧﺸﻮﯾﺪ‪.‬‬

‫)( ‪int featureCount‬‬

‫{‬
 ‫‪7‬‬ ‫ﺑﺮﻧﺎﻣﻪﻧﻮﯾﺴﯽ‬

‫‪int‬‬ ‫;‪sum = 0‬‬

‫‪int‬‬ ‫;‪i = 0‬‬

‫)‪for (i = 0; i < MAX_FEATURES; i++‬‬

‫;)‪sum += getFeatures (i‬‬

‫}‬

‫‪ .3‬ﻧﺎم ﻣﺘﻐﯿﺮ ﺑﺎ ﺣﺮوف ﮐﻮﭼﮏ ﺷﺮوع ﺷﻮد و در ﻣﺘﻐﯿﺮﻫﺎي ﭼﻨﺪ ﮐﻠﻤﻪاي ﺣﺮف اول ﻫﺮ ﮐﻠﻤﻪ‪ ،‬ﻏﯿﺮ‬
‫از ﮐﻠﻤﻪ اول‪ ،‬ﺑﺎ ﺣﺮوف ﺑﺰرگ ﺑﺎﺷﺪ‪.1‬‬

‫اﯾﻦ ﻗﺎﻧﻮن اﺑﺘﺪا ﻧﺤﻮه ﻧﺎﻣﮕﺪاري را ﺑﯿﺎن ﻣﯽﮐﻨﺪ ﺛﺎﻧﯿﺎ اﯾﻨﮑﻪ از ﻣﺘﻐﯿﺮﻫﺎي ﭼﻨﺪ ﮐﻠﻤﻪاي ﻫﺮاس ﻧﺪاﺷﺘﻪ ﺑﺎﺷﻨﯿﺪ‪.‬‬
‫ﻣﻄﻤﺌﻨﺎ ﮐﻠﻤﻪ >ﺑﻨﺰ ‪ <CLK 2009‬ﺑﻪ ﻣﺮاﺗﺐ ﻣﻔﻬﻮمﺗﺮ از >ﺑﻨﺰ< ﻣﯽﺑﺎﺷﺪ‪.‬‬

‫ﻧﮑﺘﻪ ﻣﻬﻢ در اﯾﻦ راﺳﺘﺎ ﻋﺪم اﺳﺘﻔﺎده از ﮐﺎﮐﺘﺮﻫﺎي ﺛﺎﻧﻮﯾﻪ‪ 2‬ﻣﯽ ﺑﺎﺷﻨﺪ‪ .‬ﻣﻌﻤﻮﻻ ﺑﺮﻧﺎﻣﻪﻧﻮﯾﺴﺎن از ﮐﺎراﮐﺘﺮﻫﺎي _ و‬
‫__ ﺑﯿﺸﺘﺮ اﺳﺘﻔﺎده ﻣﯽﮐﻨﻨﺪ‪ .‬ﺗﻮﺻﯿﻪ ﺑﻪ اﺳﺘﻔﺎده ﻧﮑﺮدن از ﮐﺎراﮐﺘﺮﻫﺎﯾﯽ ﻣﺎﻧﻨﺪ _ و __ ﺑﺮاي ﺟﺪا ﮐﺮدن ﮐﻠﻤﺎت دو‬
‫دﻟﯿﻞ ﻋﻤﺪه دارد‪.‬‬

‫‪ .1‬ﻧﻮﺷﺘﻦ ﻧﺎم ﻣﺘﻐﯿﺮ ﺳﺮﯾﻌﺘﺮ اﻧﺠﺎم ﻣﯽﺷﻮد ﭼﺮا ﮐﻪ ﮐﺎراﮐﺘﺮﻫﺎي _ و __ ﻧﯿﺎز ﺑﻪ ﮔﺮﻓﺘﻦ دو ﮐﻠﯿﺪ دارﻧﺪ‪.‬‬
‫‪ .2‬ﭘﯿﻮﺳﺘﮕﯽ ﻧﺎم ﻣﺘﻐﯿﺮ ﺣﻔﻆ ﻣﯽﺷﻮد و ﺧﻄﺎي ﭼﺸﻢ ﺑﺎﻋﺚ ﻧﻤﯽﺷﻮد ﯾﮏ ﻣﺘﻐﯿﺮ‪ ،‬ﭼﻨﺪ ﻣﺘﻐﯿﺮ ﺧﻮاﻧﺪه ﺷﻮد‪.‬‬

‫;‪int maxSize; // NOT: int max_size‬‬

‫;‪int tableCellWidth; // NOT: table_cell_width‬‬

‫‪ .4‬ﺑﺮاي ﻣﺘﻐﯿﺮﻫﺎﯾﯽ ﮐﻪ ﯾﮏ ﻫﺪف دارﻧﺪ ﻧﺎمﻫﺎي ﻣﺨﺘﻠﻒ و ﻣﻨﺎﺳﺐ اﻧﺘﺨﺎب ﮐﻨﯿﺪ‪.‬‬

‫در اﻏﻠﺐ اوﻗﺎت ﻣﺘﻐﯿﺮﻫﺎي ﺗﻌﺮﯾﻒ ﻣﯽﺷﻮﻧﺪ ﮐﻪ ﻫﻤﻪ ﺑﺮاي ﯾﮏ ﻣﻨﻈﻮر ﻫﺴﺘﻨﺪ ﻣﺎﻧﻨﺪ ﻣﺘﻐﯿﺮﻫﺎي واﺳﻂ ﯾﺎ ﻣﻮﻗﺖ در‬
‫ﭼﻨﯿﻦ ﻣﻮاﻗﻌﯽ ﻣﺎﻧﻨﺪ ﻣﺜﺎل زﯾﺮ ﻋﻤﻞ ﻧﮑﻨﯿﺪ‪.‬‬

‫‪ - 1‬ﺑﻪ اﯾﻦ روش ﻧﺎﻣﮕﺬاري ‪ Camel Case‬ﮔﻮﯾﻨﺪ‬

‫‪ - 2‬ﮐﺎرﮐﺘﺮﻫﺎي ﺛﺎﻧﻮﯾﻪ ﮐﺎرﮐﺘﺮﻫﺎﯾﯽ ﻫﺴﺘﻨﺪ ﮐﻪ ﺑﺎ اﺳﺘﻔﺎد از ﮐﻠﯿﺪﻫﺎي ﮐﻤﮑﯽ‪ shift, Alt،‬و ‪ Ctrl‬ﺗﺎﯾﭗ ﻣﯽﺷﻮﻧﺪ‪.‬‬
 ‫‪8‬‬ ‫ﺑﺮﻧﺎﻣﻪﻧﻮﯾﺴﯽ‬

‫;… ‪int tmp1, tmp2,‬‬

‫ﺑﻠﮑﻪ ﺳﻌﯽ ﮐﻨﯿﺪ ﻧﺎم ﻣﻨﺎﺳﺒﯽ اﻧﺘﺨﺎب ﻧﻤﺎﯾﺪ‪ .‬ﻣﺎﻧﻨﺪ‬

‫;‪int tmpSize, tmpCount, ..‬‬

‫ﻫﻤﻮاره ﺑﻪ ﯾﺎد داﺷﺘﻪ ﺑﺎﺷﯿﺪ ﮐﻪ ﻧﺎﻣﮕﺬاري ﺑﻪ ﺳﺒﮏ ‪ tmp1 , tmp2‬ﻣﺎﻧﻨﺪ اﯾﻦ اﺳﺖ ﮐﻪ ﺷﻤﺎ در ﺧﺎﻧﻮاده ﻧﺎم ﻓﺮزﻧﺪان‬
‫را ﺑﮕﺬارﯾﺪ ﺑﭽﻪ اول‪ ،‬ﺑﭽﻪ دوم و ‪. ...‬‬

‫‪ .5‬از ﭘﺴﻮﻧﺪ ‪ s‬ﺟﻬﺖ ﻣﺘﻐﯿﺮﻫﺎﯾﯽ ﮐﻪ ﺑﯿﺎﻧﮕﺮ ﺗﻌﺪاد ﻫﺴﺘﻨﺪ ﺻﺮﻓﻨﻈﺮ ﮐﻨﯿﺪ و ﺑﻪ ﺟﺎي آن از ﭘﺴﻮﻧﺪ‬
‫‪ List‬ﯾﺎ ﭘﯿﺸﻮﻧﺪ ‪ n‬اﺳﺘﻔﺎده ﮐﻨﯿﺪ‪.‬‬

‫ﭘﺴﻮﻧﺪ ‪ s‬در اﻧﺘﻬﺎي ﻣﺘﻐﯿﺮ ﺑﺴﯿﺎر ﺧﻄﺎﺧﯿﺰ اﺳﺖ‪ .‬ﭼﺮا ﮐﻪ ‪:‬‬

‫‪ .1‬ﭼﺸﻢ ﺑﻪ راﺣﺘﯽ ﻧﻤﯽﺗﻮاﻧﺪ ‪ s‬را در اﻧﺘﻬﺎي ﻣﺘﻐﯿﺮ ﺑﺒﯿﻨﺪ‪.‬‬

‫‪ .2‬ﻫﻤﻮاره در ﺟﺎﯾﯽ ﮐﻪ اﯾﻦ ﻣﺘﻐﯿﺮ وﺟﻮد دارد ﻣﻌﺎدل آن ﻣﺘﻐﯿﺮي ﺑﺪون ‪ s‬وﺟﻮد دارد و ﻫﻤﻮاره ﺑﺎﻋﺚ ﺧﻄﺎي‬
‫ﺑﺮﻧﺎﻣﻪ ﻧﻮﯾﺲ ﻣﯽﺷﻮد‪.‬‬

‫ﻟﺬا اﺳﺘﻔﺎده از اﯾﻦ ﭘﺴﻮﻧﺪ ﻣﻨﺎﺳﺐ ﻧﻤﯽﺑﺎﺷﺪ ﺑﻪ ﺟﺎي آن ﺑﻬﺘﺮ اﺳﺖ از ﭘﺴﻮﻧﺪ ‪ List‬ﯾﺎ ﭘﯿﺸﻮﻧﺪ ‪ n‬اﺳﺘﻔﺎده ﺷﻮد ﮐﻪ‬
‫ﺗﻮﺻﯿ ﻪ ﺑﻪ اﺳﺘﻔﺎده از ﭘﺴﻮﻧﺪ اﺳﺖ اﻣﺎ ﻫﺮ ﻣﻮرد ﮐﻪ اﺳﺘﻔﺎده ﺷﺪ ﺑﺎﯾﺪ در ﺗﻤﺎﻣﯽ ﺑﺮﻧﺎﻣﻪ ﻗﺎﻧﻮن رﻋﺎﯾﺖ ﺷﻮد‪.‬‬

‫‪int featureList; // NOT: int features‬‬

‫‪int nLine; // NOT: int lines‬‬

‫‪ .6‬ﻧﺎم ﻣﺘﻐﯿﺮ ﻣﺘﻨﺎﺳﺐ ﺑﺎ ﺣﻮﺿﻪ دﯾﺪ آن ﺑﺎﺷﺪ‪.‬‬

‫ﻣﻨﻈﻮر از اﯾﻦ ﻗﺎﻧﻮن اﯾﻦ اﺳﺖ ﮐﻪ ﻣﺜﻼ در ﺣﻮﺿﻪ دﯾﺪ ﯾﮏ ﺗﺎﺑﻊ ﻣﯽﺗﻮان ﻣﺘﻐﯿﺮي ﺑﺎ ﻧﺎم ‪ tmp‬ﺗﻌﺮﯾﻒ ﻧﻤﻮد اﻣﺎ ﺗﻌﺮﯾﻒ‬
‫اﯾﻦ ﻣﺘﻐﯿﺮ در ﺣﻮﺿﻪ دﯾﺪ ﯾﮏ ﮐﻼس اﺻﻼ ﻣﻨﺎﺳﺐ ﻧﻤﯽﺑﺎﺷﺪ‪ .‬ﺑﻨﺎﺑﺮاﯾﻦ ﺳﻌﯽ ﮐﻨﯿﺪ ﻃﻮل ﻧﺎم ﻣﺘﻐﯿﺮ ﻣﺘﻨﺎﺳﺐ ﺑﺎ‬
‫ﺣﻮﺿﻪ دﯾﺪ آن ﺑﺎﺷﺪ و در زﻣﺎن ﺧﻮاﻧﺪن ﮐﺪ اﯾﺠﺎد ﮐﻨﺪي ﯾﺎ ﺳﺮدرﮔﻤﯽ ﻧﮑﻨﺪ‪.‬‬

‫در اﯾﻦ زﻣﯿﻨﻪ ﻗﺎﻧﻮن ﺳﺮاﻧﮕﺸﺘﯽ اﯾﻦ اﺳﺖ ‪ » :‬ﻃﻮل ﻧﺎم ﻣﺘﻐﯿﺮ ﻋﮑﺲ ﺣﻮﺿﻪ دﯾﺪ آن ﻣﯽﺑﺎﺷﺪ«‬
 ‫‪9‬‬ ‫ﺑﺮﻧﺎﻣﻪﻧﻮﯾﺴﯽ‬

‫‪ .7‬ﻃﻮل ﻧﺎم ﻣﺘﻐﯿﺮ ﻣﺘﻨﺎﺳﺐ ﺑﺎ ﻣﻔﻬﻮم آن ﺑﺎﺷﺪ‬

‫ﻫﻤﺎﻧﻄﻮر ﮐﻪ ﮔﻔﺘﻪ ﺷﺪ ﻧﺎم ﻣﺘ ﻐﯿﺮ ﺑﺎﯾﺪ ﻣﻔﻬﻮم ﺑﺎﺷﺪ اﻣﺎ ﺑﺎﯾﺪ ﺑﻪ ﺧﺎﻃﺮ داﺷﺖ ﮐﻪ اﯾﻦ ﺑﻪ ﻣﻌﻨﺎي اﯾﺠﺎد ﻣﺘﻐﯿﺮﻫﺎي ﺑﺎ‬
‫ﻃﻮل زﯾﺎد ﻧﻤﯽﺑﺎﺷﺪ‪ .‬ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﻧﻘﻄﻪاي ﮐﻪ ﻣﺘﻐﯿﺮ ﺗﻌﺮﯾﻒ ﻣﯽﺷﻮد ﮔﺎﻫﯽ ﻣﯽﺗﻮان ﺑﺎ اﺳﺘﻔﺎده از ﺳﺮﻧﺎمﻫﺎ‪ ،‬ﻧﺎم ﻣﺘﻐﯿﺮ‬
‫را ﺧﻼﺻﻪ اﻣﺎ ﻣﻔﻬﻮم اﻧﺘﺨﺎب ﮐﺮد ﮔﺎﻫﯽ ﻫﻢ ﺧﯿﺮ‪ .‬ﻣﺜﻼ ﻣﻤﮑﻦ اﺳﺖ در ﺣﻮﺿﻪ دﯾﺪ ﯾﮏ ﺗﺎﺑﻊ ﮐﻮﭼﮏ ﺑﺘﻮان از ﻧﺎم‬
‫‪ stuID‬ﺑﺮاي ﺷﻤﺎره ﺷﻨﺎﺳﺎﯾﯽ داﻧﺶآﻣﻮز اﺳﺘﻔﺎده ﻧﻤﻮد اﻣﺎ ﮔﺎﻫﯽ ﻫﻢ ﻣﺠﺒﻮر ﺑﻪ اﺳﺘﻔﺎده از ﻧﺎم ‪ studentID‬ﺷﻮﯾﻢ‪.‬‬
‫ﺑﻪ ﻫﺮﺣﺎل ﻗﺎﻧﻮن ﻣﻬﻢ اﯾﻦ اﺳﺖ ﮐﻪ ﺑﺎ اﺳﺘﻔﺎده از ﻧﺎمﻫﺎي ﺧﯿﻠﯽ ﻃﻮﻻﻧﯽ ﺑﯿﺨﻮد ﮐﺪ را ﻃﻮﻻﻧﯽ ﻧﮑﻨﯿﻢ و ﺑﺎ اﺳﺘﻔﺎده‬
‫از ﻧﺎمﻫﺎي ﺧﯿﻠﯽ ﺧﻼﺻﻪ ﻧﯿﺰ ﮐﺪ را ﻧﺎﻣﻔﻬﻮم ﻧﮑﻨﯿﻢ‪ .‬در ﯾﮏ ﺟﻤﻠﻪ » ﺗﻔﺮﯾﻂ و اﻓﺮا در ﻃﻮل ﻧﺎم ﻣﺘﻐﯿﺮ ﻧﻨﻤﺎﯾﯿﻢ«‬

‫‪ .8‬در ﻫﻨﮕﺎم ﺗﻌﺮﯾﻒ ﮐﺮدن اﺷﺎرهﮔﺮ * را ﺑﻪ ﻣﺘﻐﯿﺮ ﺑﭽﺴﺎﻧﯿﺪ ﻧﻪ ﺑﻪ ﻧﻮع آن‪.‬‬

‫در ﺑﺮﺧﯽ از اﺳﺘﺎﻧﺪاردﻫﺎ ﺗﻮﺻﯿﻪ ﻣﯽﺷﻮد * را ﺑﻪ ﻧﻮع ﻣﺘﻐﯿﺮ ﺑﭽﺴﺒﺎﻧﯿﺪ اﻣﺎ اﯾﻦ ﭘﯿﺸﻨﻬﺎد ﻣﻌﺎﯾﺐ زﯾﺮ را دارد‪:‬‬

‫‪ .1‬در ﻫﻨﮕﺎم ﺧﻮاﻧﺪن ﺧﻄﺎي ﭼﺸﻢ ﻣﯽﺗﻮاﻧﺪ آن را ﻧﺒﯿﻨﺪ و ﺗﺼﻮر ﺷﻮد ﮐﻪ ﻣﺘﻐﯿﺮ اﺷﺎرهﮔﺮ ﻧﯿﺴﺖ‪.‬‬
‫‪ .2‬در اﮐﺜﺮ ﺗﻮﺻﯿﻪﻫﺎي ﺑﺮﻧﺎﻣﻪﻧﻮﯾﺴﯽ‪ ،‬ﺗﻮﺻﯿﻪ ﻣﯽﺷﻮد ﺑﺮاي اﺷﺎرﮔﺮﻫﺎ ﻧﻮع ﺟﺪﯾﺪ ﺗﻌﺮﯾﻒ ﮐﻨﯿﺪ ﺗﺎ ﻣﻮرد ﻗﺒﻞ ﭘﯿﺶ‬
‫ﻧﯿﺎﯾﺪ‪ .‬در واﻗﻊ ﻧﮑﺘﻪ در اﯾﻨﺠﺎﺳﺖ ﮐﻪ ﭼﺴﺒﺎﻧﺪن * ﺑﻪ ﻧﻮع ﺧﻮد ﺑﯿﺎﻧﮕﺮ ﻧﻮع ﺟﺪﯾﺪ اﺳﺖ ﻧﻪ ﻧﺎم ﻣﺘﻐﯿﺮي از ﻧﻮع‬
‫اﺷﺎرهﮔﺮ‪.‬‬

‫ﺑﻨﺎﺑﺮاﯾﻦ ﻣﺎﻧﻨﺪ ﻣﺜﺎل زﯾﺮ ﻋﻤﻞ ﮐﻨﯿﺪ‪.‬‬

‫‪RGFeature *feature = NULL, centerFeature; // NOT: RGFeature* feature = NULL,‬‬

‫;‪centerFeature‬‬

‫ﻋﻼوه ﺑﺮ ﻣﻮارد ﺑﺎﻻ در ﺗﻤﺎﻣﯽ ﮐﺘﺐ آﻣﻮزﺷﯽ ﺗﺎﮐﯿﺪ ﻣﯽﺷﻮد ﮐﻪ در ﺗﻌﺮﯾﻔﯽ ﻣﺎﻧﻨﺪ ﻣﺜﺎل ﺑﺎﻻ ‪ feature‬اﺷﺎرهﮔﺮ اﺳﺖ‬
‫اﻣﺎ ‪ centerFeature‬ﻧﯿﺴﺖ ﺣﺎل آﻧﮑﻪ اﯾﻦ ﻣﻮﺿﻮع در اﺳﺘﺎﻧﺪارد ﺗﻮﺻﯿﻪ ﺷﺪه ﺑﻪ ﺧﻮﺑﯽ دﯾﺪه ﻧﻤﯽﺷﻮد اﻣﺎ در‬
‫اﺳﺘﺎﻧﺪارد اﯾﻦ ﻣﺴﺘﻨﺪ ﺑﻪ ﺧﻮﺑﯽ دﯾﺪه ﺷﺪه اﺳﺖ‪.‬‬

‫‪ .9‬ﻧﺎم ﻣﺘﻐﯿﺮﻫﺎي ﮐﻼﺳﯽ ﺑﺎ ﭘﯿﺸﻮﻧﺪ ‪ m‬ﺷﺮوع ﺷﻮد‪.‬‬

‫اﯾﻦ ﻧﮑﺘﻪ ﺟﻬﺖ ﺑﺎﻻﺑﺮدن ﺧﻮاﻧﺎﯾﯽ ﮐﺪ اﺳﺖ و ﺑﺎﻋﺚ ﻣﯽﺷﻮد در ﻣﺘﻦ ﮐﺪ ﺑﻪ راﺣﺘﯽ ﺑﺘﻮان ﻣﺘﻐﯿﺮﻫﺎﯾﯽ ﮐﻼﺳﯽ را‬
‫ﺗﺸﺨﯿﺺ داد‪ .‬ﭘﺮواﺿﺢ اﺳﺖ ﮐﻪ ﺗﻮﺻﯿﻪ ‪ 3‬ﻧﯿﺰ ﺑﺎﯾﺪ در اﯾﻨﺠﺎ رﻋﺎﯾﺖ ﺷﻮد و ﻧﺎم ﻣﺘﻐﯿﺮ ﭼﻮن ﺑﻌﺪ از ﭘﯿﺸﻮﻧﺪ ﻣﯽآﯾﺪ‬
‫ﺣﺘﻤﺎ ﺑﺎﯾﺪ ﺑﺎ ﺣﺮف ﺑﺰرگ ﺷﺮوع ﺷﻮد‪.‬‬

‫‪class RGFeature‬‬

‫{‬
 ‫‪10‬‬ ‫ﺑﺮﻧﺎﻣﻪﻧﻮﯾﺴﯽ‬

‫‪privet:‬‬

‫;‪int mSize; // NOT: int size_; int _size; int m_size; int msize‬‬

‫}‬

‫‪ .10‬ﺷﻤﺎرﻧﺪهﻫﺎي ﺣﻠﻘﻪ را ‪ i, j, k‬ﺑﻨﺎﻣﯿﺪ و اﮔﺮ ﺑﯿﺶ از ﺳﻪ ﺳﻄﺢ ﺗﻮدرﺗﻮﯾﯽ داﺷﺘﯿﺪ از ‪ l, m, n‬ﺑﺮاي‬

‫ﺳﻄﻮح داﺧﻠﯽ اﺳﺘﻔﺎده ﮐﻨﯿﺪ‪.‬‬

‫اﯾﻦ ﺗﻮﺻﯿﻪ ﺗﻘﺮﯾﺒﺎ راﯾﺞ اﺳﺖ ﭼﺮا ﮐﻪ ﺷﻤﺎرﻧﺪه در ﮐﻮﭼﮑﺘﺮﯾﻦ ﺣﻮﺿﻪ دﯾﺪ ﻗﺮار دارد ﭘﺲ ﺑﺎ ﻗﺎﻧﻮن ‪ 6‬و ‪ 7‬ﻫﻤﺨﻮاﻧﯽ‬
‫دارد و ﻫﻤﭽﻨﯿﻦ راﯾﺞ ﺑﻮدن آن ﺑﻪ ﻧﻮﻋﯽ ﻗﺎﻧﻮن ﺷﺪه و ﺧﻼف ﻗﺎﻧﻮن ﻋﻤﻞ ﮐﺮدن ﺟﺎﯾﺰ ﻧﻤﯽﺑﺎﺷﺪ‪.‬‬

‫‪ .11‬ﻧﺎم ﮐﻼسﻫﺎ‪ ،‬اﻧﻮاع ‪ type‬و ﺳﺎﺧﺘﺎرﻫﺎ ‪ structure‬ﺣﺘﻤﺎ ﺑﺎ ﺣﺮوف ﺑﺰرگ و ﺑﺎ ﭘﯿﺸﻮﻧﺪ ﻣﻨﺎﺳﺐ ﺷﺮوع‬
‫ﺷﻮد‪.‬‬

‫ﭘﯿﺸﻮﻧﺪ ﻣﻨﺎﺳﺐ‪ ،‬ﺳﺮﻧﺎم‪ 3‬ﺷﺮﮐﺖ ﻣﯽﺑﺎﺷﺪ ﮐﻪ ﻣﻌﺮف ﻣﺎﻟﮑﯿﺖ ﮐﺪ اﺳﺖ‪ .‬اﺳﺘﻔﺎده از ﺣﺮوف ﺑﺰرگ ﺟﻬﺖ ﺗﻤﺎﯾﺰ ﺳﺮﯾﻊ‬
‫ﻣﺘﻐﯿﺮ از ﻧﻮع آن ﻣﯽﺑﺎﺷﺪ‪.‬‬

‫‪class RGFeature‬‬

‫{‬

‫…‬

‫;}‬

‫‪// NOT:‬‬

‫… ‪class rgFeature‬‬

‫‪//NOT:‬‬

‫… ‪class RgFeature‬‬

‫‪Acronym - 3‬‬
 ‫‪11‬‬ ‫ﺑﺮﻧﺎﻣﻪﻧﻮﯾﺴﯽ‬

‫‪ .12‬ﻧﺎم ﻣﺎﮐﺮوﻫﺎ ﺗﻤﺎﻣﯽ ﺑﺎ ﺣﺮوف ﺑﺰرگ ﺑﺎﺷﺪ و ﺑﺎ ﺧﻂ ﺗﯿﺮه زﯾﺮ _ ﮐﻠﻤﺎت از ﯾﮑﺪﯾﮕﺮ ﺟﺪا ﺷﻮﻧﺪ‪.‬‬

‫اﺳﺘﻔﺎده از ﺣﺮوف ﺑﺰرگ ﺑﺮاي ﺗﻤﯿﺰ ﺳﺮﯾﻊ ﻣﺎﮐﺮو از ﺳﺎﯾﺮ ﻣﺘﻐﯿﺮﻫﺎ و اﻧﻮاع ﻣﯽﺑﺎﺷﺪ‪ .‬و ﺧﻂ ﺗﯿﺮه زﯾﺮ ﻧﯿﺰ ﻫﻤﯿﻨﻄﻮر‬
‫ﭼﺮا ﮐﻪ در ﺟﺎي دﯾﮕﺮي از آن اﺳﺘﻔﺎده ﻧﻤﯽﺷﻮد‪.‬‬

‫‪#define MAX_SIZE 5‬‬

‫‪//NOT:‬‬

‫‪#define MAXSIZE 5‬‬

‫‪#define maxSize‬‬ ‫‪5‬‬

‫‪#define max_size‬‬ ‫‪5‬‬

‫‪ .13‬ﻧﺎم ﺗﻮاﺑﻊ ﺑﺎ ﺣﺮوف ﮐﻮﭼﮏ ﺷﺮوع ﺷﺪه ‪،‬ﻣﺎﻧﻨﺪ ﻗﺎﻧﻮن ‪ ،3‬و ﺑﯿﺎن ﮐﻨﻨﺪه ﮐﺎرﮐﺮد ﺗﺎﺑﻊ ﺑﺎﺷﺪ‪.‬‬

‫ﺗﻮﺟﻪ داﺷﺘﻪ ﺑﺎﺷﯿﺪ در زﺑﺎن ‪ C‬ﺗﻮاﺑﻊ در ﻋﻤﻞ ﻣﺘﻐﯿﺮﻫﺎي از ﺟﻨﺲ اﺷﺎرهﮔﺮ ﻫﺴﺘﻨﺪ ﺑﻨﺎﺑﺮاﯾﻦ ﺑﺎ اﯾﻦ ﺗﻮﺟﯿﻪ ﻣﯽﺗﻮان‬
‫ﺗﻮﺻﯿﻪ ‪ 3‬را ﻧﯿﺰ در اﯾﻨﺠﺎ اﺳﺘﻔﺎده ﻧﻤﻮد ﻋﻼوه ﺑﺮ آن از دﯾﺪﮔﺎه ﻣﻔﻬﻮﻣﯽ در ﺑﺮﻧﺎﻣﻪ ﻧﻮﯾﺴﯽ ﺗﺎﺑﻊ و ﻣﺘﻐﯿﺮ از ﯾﮏ‬
‫ﻣﻔﻬﻮم ﻣﯽﺑﺎﺷﻨﺪ‪.‬‬

‫ﻧﮑﺘﻪ ﻣﻬﻢ در ﻧﺎم ﺗﻮاﺑﻊ ﻣﻔﻬﻮم ﺑﻮدن ﻧﺎم ﺗﺎﺑﻊ اﺳﺖ‪ .‬ﺑﺴﯿﺎر ﺿﺮوري اﺳﺖ ﮐﻪ از روي ﻧﺎم ﺗﺎﺑﻊ ﺑﺘﻮان وﻇﯿﻔﻪ آن را‬
‫ﺗﺸﺨﯿﺺ داد اﯾﻦ ﻣﻮﺿﻮع ﺑﻪ ﺷﺪت ﺑﻪ ﻣﻬﻨﺪﺳﯽ ﻣﻌﮑﻮس ﮐﺪ ﮐﻤﮏ ﻣﯽﮐﻨﺪ‪ .‬ﻣﺜﻼ ﺗﺎﺑﻌﯽ ﮐﻪ ﻫﺪف آن اﺳﺘﺨﺮاج‬
‫ﻣﻌﺪل ﯾﮏ آراﯾﻪ اﺳﺖ ﻧﺎم ‪ average‬ﺑﺮاي آن ﻧﺎﻣﻨﺎﺳﺐ اﺳﺖ ﭼﺮا ﮐﻪ ﻣﻔﻬﻮم ﻣﺤﺎﺳﺒﻪ در آن دﯾﺪه ﻧﻤﯽﺷﻮد ﺑﻠﮑﻪ‬
‫ﺑﻪ ﻧﻈﺮ ﻣﯽآﯾﺪ ﻣﻘﺪاري را ﺑﺎ اﯾﻦ ﻣﻀﻤﻮن ﺧﻮاﻧﺪه و ﺑﺮﻣﯽﮔﺮداﻧﺪ در اﯾﻨﺠﺎ اﺳﺘﻔﺎده از ﻧﺎم ‪ calcAverage‬ﯾﺎ‬
‫‪ computAverage‬ﻣﻨﺎﺳﺐﺗﺮ اﺳﺖ‪.‬‬

‫ﺑﺮ ﻫﻤﯿﻦ اﺳﺎس ﺗﻮﺻﯿﻪﻫﺎي زﯾﺮ در ﻧﺎﻣﮕﺬاري ﺗﻮاﺑﻊ ﻣﻔﯿﺪ ﺑﻪ ﻧﻈﺮ ﻣﯿﺂﯾﺪ‪:‬‬

‫‪ .1‬ﺗﻮاﺑﻌﯽ ﮐﻪ ﺑﺮاي ﺧﻮاﻧﺪن ﯾﺎ ﻧﻮﺷﺘﻦ ﻣﺘﻐﯿﺮﻫﺎي ﮐﻼﺳﯽ ﻫﺴﺘﻨﺪ ﺑﺎ ﺷﮑﻞ )( ]‪ set[var‬و )( ]‪get[var‬‬
‫ﻧﺎﻣﮕﺬاري ﺷﻮﻧﺪ‪.‬‬
‫‪ .2‬ﺗﻮاﺑﻌﯽ ﮐﻪ ﺑﺮاي ﺟﺴﺘﺠﻮ ﺑﻪ ﮐﺎر ﻣﯽروﻧﺪ ﺑﺎ ﭘﯿﺸﻮﻧﺪ ‪ find‬ﻫﻤﺮاه ﺷﻮﻧﺪ ﻣﺎﻧﻨﺪ ‪findMax,‬‬
‫‪.findNearestFeature‬‬
‫‪ .3‬ﺗﻮاﺑﻌﯽ ﮐﻪ ﻣﻘﺪاردﻫﯽ اوﻟﯿﻪ اﻧﺠﺎم ﻣﯽدﻫﻨﺪ ﺑﺎ ﭘﯿﺸﻮﻧﺪ ‪ init‬ﯾﺎ ‪ initialize‬ﺷﺮوع ﺷﻮﻧﺪ ﻣﺎﻧﻨﺪ ‪.initDistance‬‬
‫‪12‬‬ ‫ﺑﺮﻧﺎﻣﻪﻧﻮﯾﺴﯽ‬

‫‪ .4‬از ﭘﯿﺸﻮﻧﺪ ‪ is‬ﺑﺮاي ﺗﻮاﺑﻌﯽ ﮐﻪ ﻣﻘﺪار ﺑﻮﻟﯿﻦ ﺑﺮﻣﯽﮔﺮداﻧﻨﺪ اﺳﺘﻔﺎده ﺷﻮد ﻣﺎﻧﻨﺪ ‪isActive, isEnabled‬‬
‫‪ .5‬در ﺻﻮرت ﻧﯿﺎز ﭘﯿﺸﻮﻧﺪﻫﺎي ‪ has , can‬و ‪ should‬ﻧﯿﺰ ﺟﺎﯾﮕﺰﯾﻦ ﻣﻨﺎﺳﺒﯽ ﺑﺮاي ﭘﯿﺸﻮﻧﺪ ‪ is‬ﻣﯽﺑﺎﺷﻨﺪ‪.‬‬
 ‫‪13‬‬ ‫ﺑﺮﻧﺎﻣﻪﻧﻮﯾﺴﯽ‬

‫‪ 2‬ﻧﺤﻮه ﮐﺪﻧﻮﯾﺴﯽ‬

‫ﮐﺪ ﻧﻮﺷﺘﻪ ﺷﺪه ﻇﺎﻫﺮ ﺑﺮﻧﺎﻣﻪ اﺳﺖ ﻧﻪ ﺑﺎﻃﻦ ﺑﺮﻧﺎﻣﻪ ﭘﺲ ﭘﺮواﺿﺢ اﺳﺖ ﮐﻪ ﺑﺎﯾﺪ اﻫﻤﯿﺖ زﯾﺎدي ﺑﻪ ﺑﺎﻃﻦ ﺑﺮﻧﺎﻣﻪ داد‬
‫ﻧﻪ ﻇﺎﻫﺮ آن‪ .‬اﻣﺎ ﻫﺮ ﺑﺎﻃﻦ زﯾﺒﺎ ﺣﺘﻤﺎ ﻫﻤﺮاه ﻇﺎﻫﺮي زﯾﺒﺎ اﺳﺖ و ﻧﻤﯽﺗﻮان ﻣﻮردي را ﯾﺎﻓﺖ ﮐﻪ ﺑﺎﻃﻨﯽ زﯾﺒﺎ اﻣﺎ‬
‫ﻇﺎﻫﺮي زﺷﺖ داﺷﺘﻪ ﺑﺎﺷﺪ‪ .‬ﻇﺎﻫﺮ زﯾﺒﺎ ﻫﻤﻮاره ﺑﺎﻋﺚ ﺟﺬب اﻓﺮاد ﻣﯽﺷﻮد در ﻧﺘﯿﺠﻪ اﮔﺮ ﻣﯽﺧﻮاﻫﯿﺪ ﺳﺎﯾﺮ ﺑﺮﻧﺎﻣﻪ‬
‫ﻧﻮﯾﺲﻫﺎ‪ ،‬ﮐﻪ اﺣﺘﻤﺎﻻ از ﮐﺪ ﺷﻤﺎ ﮐﺎري ﺟﺰ اﯾﺮاد ﮔﺮﻓﺘﻦ ﻧﺪارﻧﺪ‪ ،‬ﺑﻪ ﮐﺎر ﺷﻤﺎ ﻋﻼﻗﻤﻨﺪ ﺷﻮﻧﺪ ﻣﻄﻤﺌﻦ ﺑﺎﺷﯿﺪ رﻋﺎﯾﺖ‬
‫ﻇﺎﻫﺮ زﯾﺒﺎ ﺑﺴﯿﺎر ﺑﻪ ﺷﻤﺎ ﮐﻤﮏ ﺧﻮاﻫﺪ ﮐﺮد‪.‬‬

‫‪ .14‬ﮐﺪ ﺧﻮد را ﺷﻠﻮغ ﻧﮑﻨﯿﺪ‪.‬‬

‫از ﻧﮑﺎت ﻣﻬﻢ در ﮐﺪ ﻧﻮﯾﺴﯽ واﺿﺢ ﺑﻮدن ﮐﺪ اﺳﺖ ﻟﺬا ﺳﻌﯽ ﮐﻨﯿﺪ ﮐﺪﻫﺎ ﻏﯿﺮ ﺿﺮوري ﮐﻪ ﻣﻌﻤﻮﻻ ﺑﻪ ﺗﻮﺿﯿﺤﺎت‬
‫)‪ (comment‬ﺗﺒﺪﯾﻞ ﺷﺪهاﻧﺪ‪ ،‬را ﺣﺬف ﮐﻨﯿﺪ زﯾﺮا اﯾﻦ ﮐﺪﻫﺎ ﻣﻌﻤﻮﻻ ﻓﻘﻂ ﺑﺎﻋﺚ ﻃﻮﯾﻞ ﺷﺪن ﮐﺪ ﺷﻤﺎ ﻣﯽﺷﻮﻧﺪ و‬
‫اﺷﮑﺎلزداﯾﯽ‪ ،‬ﺧﻮاﻧﺪن ﮐﺪ و ردﮔﯿﺮي را ﺑﯽﺟﻬﺖ ﺳﺨﺖ ﻣﯽﮐﻨﻨﺪ‪ .‬ﭘﺲ ﻫﻤﻮاره ﺳﻌﯽ ﮐﻨﯿﺪ اﮔﺮ از ﺻﺤﺖ‬
‫ﮐﺎرﮐﺮدﮐﺪي ﻣﻄﻤﺌﻦ ﺷﺪﯾﺪ ﺳﺎﯾﺮ ﮐﺪﻫﺎي ﺗﻮﺿﯿﺤﯽ را ﺣﺬف ﮐﻨﯿﺪ و اﮔﺮ ﭼﻨﯿﻦ ﻧﯿﺴﺖ اﺑﺘﺪا ﻣﺸﮑﻼت آن ﻗﺴﻤﺖ‬
‫را ﺑﺮﻃﺮف ﮐﻨﯿﺪ ﺳﭙﺲ اداﻣﻪ دﻫﯿﺪ‪.‬‬

‫ﺗﻮﺟﻪ داﺷﺘﻪ ﺑﺎﺷﯿﺪ ﮐﻪ ﺑﺮاي رﻓﻊ ﺧﻄﺎ ﻣﻌﻤﻮﻻ اﻓﺮاد از اﯾﺠﺎد ﺧﺮوﺟﯽ اﺳﺘﻔﺎده ﻣﯽﮐﻨﻨﺪ ﻣﺜﻼ در زﺑﺎن ﺳﯽ دﺳﺘﻮر‬
‫‪ printf‬ﺑﻪ ﻓﺮاوﻧﯽ اﺳﺘﻔﺎده ﻣﯽﺷﻮد‪ .‬ﺳﻌﯽ ﮐﻨﯿﺪ‬

‫‪ .1‬ﺧﺮوﺟﯽﻫﺎ ﮐﻨﺘﺮل ﺷﺪه ﺑﺎﺷﻨﺪ و ﺧﺮوﺟﯽ ﺑﯽ ﺟﻬﺖ ﺗﻮﻟﯿﺪ ﻧﮑﻨﯿﺪ‪.‬‬

‫‪ .2‬ﺧﺮوﺟﯽ ﺑﻪ ﮔﻮﻧﻪاي ﺑﺎﺷﻨﺪ ﮐﻪ ﺣﺬف آنﻫﺎ راﺣﺖ ﺑﺎﺷﺪ‬
‫‪ .3‬ﻫﺮﮔﺎه ﻣﺸﮑﻼت ﺑﺮﻃﺮف ﺷﺪ ﺧﺮوﺟﯽﻫﺎي را ﺣﺬف ﮐﻨﯿﺪ ﻣﮕﺮ ﻣﻮارد ﺿﺮوري ﮐﻪ ﺑﺎﯾﺪ در ﺑﺮﻧﺎﻣﻪ ﺑﻤﺎﻧﻨﺪ‪.‬‬

‫ﺑﻨﺎﺑﺮاﯾﻦ ﺧﻮد را در ﯾﮏ اﺗﺎق ﺷﻠﻮغ و ﭘﺮ از وﺳﺎﯾﻞ ﻗﺮار ﻧﺪﻫﯿﺪ‪.‬‬

‫;‪int scnNum = 0‬‬

‫;‪int i‬‬

‫‪//‬‬ ‫;‪QStringList clientNames‬‬

‫;‪QStringList clientIP‬‬

‫*‪/‬‬ ‫;‪RGSceen *scn‬‬

‫;‪QHBoxLayout *layout = NULL‬‬

 14 ‫ﺑﺮﻧﺎﻣﻪﻧﻮﯾﺴﯽ‬

setupUi(this);

mConfig = config;

*/

mConfig->get ("screen", "name", clientNames);

mConfig->get ("screen", "ip", clientIP);

scnNum = clientNames.size ();

// if (scnNum == 0 || scnNum != clientIP.size ())

QMessageBox::critical (this, tr ("Client Ui"), tr ("Invalid screen definition!"));

// else

layout = new QHBoxLayout (this);

for (i = 0; i < scnNum; i++)

/* scn = new RGSceen (this, clientIP.at (i));

scn->pushButton->setText (clientNames.at (i)); */

layout->addWidget (scn);

‫ﻣﻘﺎﯾﺴﻪ ﮐﻨﯿﺪ ﺑﺎ ﻣﻮرد زﯾﺮ‬

int scnNum = 0;

int i;

QStringList clientNames;

QStringList clientIP;

RGSceen *scn;

QHBoxLayout *layout = NULL;

 15 ‫ﺑﺮﻧﺎﻣﻪﻧﻮﯾﺴﯽ‬

setupUi(this);

mConfig = config;

mConfig->get ("screen", "name", clientNames);

mConfig->get ("screen", "ip", clientIP);

scnNum = clientNames.size ();

if (scnNum == 0 || scnNum != clientIP.size ())

QMessageBox::critical (this, tr ("Client Ui"), tr ("Invalid screen definition!"));

else

layout = new QHBoxLayout (this);

for (i = 0; i < scnNum; i++)

scn = new RGSceen (this, clientIP.at (i));

scn->pushButton->setText (clientNames.at (i));

layout->addWidget (scn);

.‫ﭘﺮواﺿﺢ اﺳﺖ ﮐﻪ ﻣﻄﺎﻟﻌﻪ ﮐﺪ دوم ﺑﻪ ﻣﺮاﺗﺐ راﺣﺖﺗﺮ ﻣﯽﺑﺎﺷﺪ‬

.‫ از ﺷﮑﺴﺘﻦ ﺑﯽﻣﻮرد ﺧﻄﻮط ﭘﺮﻫﯿﺰ ﮐﻨﯿﺪ‬.15

‫ﺑﻪ ﯾﺎد داﺷﺘﻪ ﺑﺎﺷﯿﺪ زﻣﺎﻧﯽ ﮐﻪ ﻣﺘﻨﯽ را ﻣﻄﺎﻟﻌﻪ ﻣﯽﮐﻨﺪ رﻓﺘﻦ ﺑﻪ ﺧﻂ ﺑﻌﺪي ﻫﻢ زﻣﺎنﺑﺮ اﺳﺖ و ﻫﻢ ﻣﯽﺗﻮاﻧﺪ ﺑﺎﻋﺚ‬
‫ را ﻧﯿﺰ‬14 ‫ﭘﺮﯾﺪن از روي ﺧﻂ ﺑﻪ دﻟﯿﻞ ﺧﻄﺎي ﭼﺸﻢ ﺷﻮد ﭘﺲ ﺳﻌﯽ ﮐﻨﯿﺪ ﺧﻄﻮط را ﺑﯽﻣﻮرد ﻧﺸﮑﻨﯿﺪ ﺗﺎ ﻗﺎﻧﻮن‬
.‫ﻧﻘﺾ ﻧﮑﺮده ﺑﺎﺷﺪ‬
 16 ‫ﺑﺮﻧﺎﻣﻪﻧﻮﯾﺴﯽ‬

int findMax (QStringList stringList, int startIndex);

// NOT:

int

findMax (

QStringList stringList,

int startIndex)

‫اﻣﺎ ﭼﻨﺎﻧﭽﻪ ﻃﻮل ﺧﻂ زﯾﺎد ﻃﻮﻻﻧﯽ ﺷﺪ ﺑﻄﻮرﯾﮑﻪ ﻧﯿﺎز ﺑﻪ ﻣﺮور اﻓﻘﯽ ﺻﻔﺤﻪ ﭘﯿﺪا ﮐﺮد آﻧﮕﺎه ﻣﻄﺎﺑﻖ ﻗﻮاﻧﯿﻦ زﯾﺮ ﺳﻌﯽ‬
.‫ﮐﻨﯿﺪ ﺧﻄﻮط را ﺑﺸﮑﻨﯿﺪ‬

.‫ ﭘﺎراﻣﺘﺮﻫﺎي ﺗﺎﺑﻊ ﻫﺮ ﮐﺪام در ﯾﮏ ﺧﻂ و ﮐﺎﻣﺎ در اﻧﺘﻬﺎي ﺧﻂ ﺑﺎﺷﺪ‬.1

.‫ ﻋﻤﻠﮕﺮﻫﺎ ﻫﻤﻮاره در اﻧﺘﻬﺎي ﺧﻂ ﺑﺎﺷﻨﺪ‬.2

int findMax (

QStringList stringList,

int startIndex)

// NOT:

int findMax (

QStringList stringList, int startIndex)

x= (a+b+

c + d );

// NOT:

x=(a+b

+ c + d );
 ‫‪17‬‬ ‫ﺑﺮﻧﺎﻣﻪﻧﻮﯾﺴﯽ‬

‫‪ .16‬از ﺑﻪ ﮐﺎرﺑﺮدن اﻋﺪاد ﺟﺎدوﯾﯽ ﭘﺮﻫﯿﺰ ﮐﻨﯿﺪ‪.‬‬

‫ﻣﻌﻤﻮﻻ ﺑﺮﻧﺎﻣﻪﻧﻮﯾﺴﺎن ﻫﻤﻮاره ﺑﺎ ﻣﺘﻐﯿﺮﻫﺎي ﻣﻮاﺟﻪ ﻣﯽﺷﻮﻧﺪ ﮐﻪ ﻣﺜﻼ ﺑﯿﺶ از دو ﺳﻪ ﻣﻘﺪار‪ ،‬ﺣﺎﻟﺖ‪ ،‬ﻣﺨﺘﻠﻒ ﻧﻤﯽ‪-‬‬
‫ﮔﯿﺮﻧﺪ در ﭼﻨﯿﻦ ﻣﻮادري ﻣﻤﮑﻦ اﺳﺖ در ذﻫﻦ ﺧﻮد ﺑﺮاي ﻫﺮ ﻣﻘﺪار ﻣﻔﻬﻮﻣﯽ ﻣﺘﺼﻮر ﺷﻮﻧﺪ و در ﻋﺒﺎرات ﺷﺮﻃﯽ‪،‬‬
‫ورودي ﺗﻮاﺑﻊ و ‪ ...‬ﺑﻪ ﺟﺎي ﻣﻔﻬﻮم ﻋﺪد را ارﺳﺎل ﮐﻨﻨﺪ ﻣﺎﻧﻨﺪ ﻣﺜﺎل زﯾﺮ‪:‬‬

‫)‪if ( type == 1‬‬

‫;)‪getSize (type, 2‬‬

‫ﻫﻤﺎﻧﻄﻮر ﮐﻪ دﯾﺪه ﻣﯽﺷﻮد‪.‬‬

‫‪ .1‬زﯾﺒﺎﯾﯽ ﮐﺪ از ﺑﯿﻦ رﻓﺘﻪ اﺳﺖ‪.‬‬

‫‪ .2‬ﮐﺪ ﺑﺴﯿﺎر ﻧﺎﻣﻔﻬﻮم اﺳﺖ‪.‬‬
‫‪ .3‬ردﮔﯿﺮي ﮐﺪ ﺟﻬﺖ اﺷﮑﺎل زداﯾﯽ ﯾﺎ ﻣﻬﻨﺪﺳﯽ ﻣﻌﮑﻮس ﺳﺨﺖ اﺳﺖ‪.‬‬

‫ﺑﻨﺎﺑﺮاﯾﻦ ﺑﺎﯾﺪ ﺑﻪ ﺟﺎي اﯾﻦ اﻋﺪاد از ﻣﺎﮐﺮوﻫﺎ اﺳﺘﻔﺎده ﻧﻤﻮد‪.‬‬

‫‪#define SURFACE‬‬ ‫‪1‬‬

‫‪#define AIR‬‬ ‫‪2‬‬

‫‪#define SUBSURFACE 3‬‬

‫‪..‬‬

‫‪..‬‬

‫)‪if (type == AIR‬‬

‫;)‪getSize (type, SURFACE‬‬

‫اﻟﺒﺘﻪ ﮔﺎﻫﯽ ﻣﻮاﻗﻊ در ﮐﺘﺐ ﺗﻮﺻﯿﻪ ﻣﯽﺷﻮد در ﭼﻨﯿﻦ ﻣﻮاردي ﻧﻮع ﺷﻤﺎرﺷﯽ ﺗﻌﺮﯾﻒ ﺷﻮد‪ .‬اﯾﻦ ﻣﻮرد ﺗﻮﺻﯿﻪ ﻧﻤﯽﺷﻮد‬
‫ﭼﺮا ﮐﻪ‪:‬‬

‫‪ .1‬زﻣﺎن ﮐﺎﻣﭙﺎﯾﻞ ﺑﺎﻻ ﻣﯽ رود‪.‬‬

‫‪ .2‬ﮐﺎﻣﭙﺎﯾﻠﺮﻫﺎ ﺑﺮاي اﻧﻮاع ﺷﻤﺎرﺷﯽ در ﻣﻮرد ﻋﻤﻠﮕﺮﻫﺎ و ‪ Cast‬ﮐﺮدن ﺧﻄﺎﻫﺎي زﯾﺎدي ﺗﻮﻟﯿﺪ ﻣﯿﮑﻨﻨﺪ‪.‬‬
 ‫‪18‬‬ ‫ﺑﺮﻧﺎﻣﻪﻧﻮﯾﺴﯽ‬

‫‪ .3‬در زﻣﺎن ﻣﻬﻨﺪﺳﯽ ﻣﻌﮑﻮس ردﮔﯿﺮي ﺗﻌﺪاد زﯾﺎد اﻧﻮاع ﻣﺘﻐﯿﺮ ﮐﺎر را ﺳﺨﺖ ﻣﯽﮐﻨﺪ‪.‬‬

‫‪ .17‬ﻓﻀﺎي ﺧﺎﻟﯽ )‪ (space‬اﺑﺰار ﺟﺎدوﯾﯽ زﯾﺒﺎ ﺳﺎزي اﺳﺖ‪.‬‬

‫ﻣﻄﻤﺌﻦ ﺑﺎﺷﯿﺪ ﻫﯿﭻ اﺑﺰار آراﯾﺸﯽ در زﻣﯿﻨﻪ ﮐﺎرﺑﺮدي ﺧﻮد ﺑﻪ اﻧﺪازه ﻓﻀﺎي ﺧﺎﻟﯽ در ﺑﺮﻧﺎﻣﻪﺳﺎزي ﻗﺪرت زﯾﺒﺎﺳﺎزي‬
‫ﻧﺪارد‪ .‬ﭘﺲ ﺑﺪاﻧﯿﺪ ﻓﻀﺎي ﺧﺎﻟﯽ دوﺳﺖ ﺷﻤﺎﺳﺖ و از آن دوري ﻧﮑﻨﯿﺪ‪ .‬ﻫﻤﻮاره ﺳﻌﯽ ﮐﻨﯿﺪ در ﻣﻮارد زﯾﺮ ﻓﻀﺎي‬
‫ﺧﺎﻟﯽ اﯾﺠﺎد ﺷﻮد‪.‬‬

‫ﺑﻌﺪ و ﻗﺒﻞ از ﻋﻤﻠﮕﺮﻫﺎ ﻓﻀﺎي ﺧﺎﻟﯽ اﯾﺠﺎد ﺷﻮد‪.‬‬ ‫‪.1‬‬

‫ﺑﻌﺪ از ﮐﺎﻣﺎ در ﭘﺎراﻣﺘﺮﻫﺎي ورودي ﺗﻮاﺑﻊ ﻓﻀﺎي ﺧﺎﻟﯽ اﯾﺠﺎد ﺷﻮد‪.‬‬ ‫‪.2‬‬
‫ﺑﻌﺪ از ; در ﺣﻠﻘﻪﻫﺎ‪.‬‬ ‫‪.3‬‬
‫ﻗﺒﻞ از ( و ﺑﻌﺪ از ) در دﺳﺘﻮرات ﻓﻀﺎي ﺧﺎﻟﯽ اﯾﺠﺎد ﺷﻮد‪.‬‬ ‫‪.4‬‬
‫ﻧﺎم ﺗﻮاﺑﻊ را ﺑﻪ ﭘﺮاﻧﺘﺰ ﺑﻌﺪ از آن ﻧﭽﺴﺒﺎﻧﯿﺪ و ﯾﮏ ﻓﻀﺎي ﺧﺎﻟﯽ اﯾﺠﺎد ﮐﻨﯿﺪ‪.‬‬ ‫‪.5‬‬
‫ﮐﻠﻤﺎت ﮐﻠﯿﺪي را ﺑﻪ ﭘﺮاﻧﺘﺰﻫﺎ ﻧﭽﺴﺒﺎﻧﯿﺪ‪.‬‬ ‫‪.6‬‬
‫ﻫﻤﺘﺮازي ﺑﺴﯿﺎر ﺗﺎﮐﯿﺪ ﺷﺪه ﭘﺲ از ﻓﻀﺎي ﺧﺎﻟﯽ ﺑﺮاي ﻫﻤﺘﺮاز ﮐﺮدن اﺳﺘﻔﺎده ﮐﻨﯿﺪ‪.‬‬ ‫‪.7‬‬

‫ﺑﻪ ﮐﺪ ﻧﻤﻮﻧﻪ زﯾﺮ ﺗﻮﺟﻪ ﮐﻨﯿﺪ‪.‬‬

‫)‪int findMaxArea (int sizeList[], int count‬‬

‫{‬

‫‪int‬‬ ‫;‪i‬‬

‫;‪float area = 0.0, maxArea = 0.0‬‬

‫)‪for ( i = 0; i < (count - 1); i++‬‬

‫{‬

‫;] ‪area = sizeList [i] * sizeList [ i + 1‬‬

‫)‪if ( maxArea < area‬‬

‫{‬

‫;‪maxArae = area‬‬

‫}‬
 ‫‪19‬‬ ‫ﺑﺮﻧﺎﻣﻪﻧﻮﯾﺴﯽ‬

‫}‬

‫;‪return maxArae‬‬

‫}‬

‫ﻫﻤﺎﻧﻄﻮر ﮐﻪ دﯾﺪه ﻣﯽﺷﻮد در زﻣﺎن ﺗﻌﺮﯾﻒ ﻣﺘﻐﯿﺮ ﺑﺎ اﺳﺘﻔﺎده از ﻓﻀﺎي ﺧﺎﻟﯽ ﺳﻌﯽ ﺷﺪه اﺳﺖ ﻫﻤﺘﺮازي رﻋﺎﯾﺖ‬
‫ﺷﻮد‪.‬‬

‫ﻗﺎﻧﻮن ﮐﻠﯽ اﯾﻦ اﺳﺖ ﮐﻪ ﻧﻪ اﻓﺮاط ﺷﻮد ﻧﻪ ﺗﻔﺮﯾﻂ ﯾﻌﻨﯽ از ﻓﻀﺎي ﺧﺎﻟﯽ ﺑﻪ اﻧﺪازهاي اﺳﺘﻔﺎده ﺷﻮد ﮐﻪ ﮐﺪ‬
‫زﯾﺒﺎ ﺷﻮد و ﺧﻮاﻧﺎﯾﯽ و ﺳﻬﻮﻟﺖ ردﮔﯿﺮي آن ﻧﯿﺰ ﺣﻔﻆ ﺷﻮد ﭘﺲ ﺧﻮد را ﺻﺮﻓﺎ ﻣﻘﯿﺪ ﺑﻪ اﯾﻦ ﻗﺎﻧﻮن ﻧﺪاﻧﯿﺪ‬
‫اﻣﺎ آن را ﻧﯿﺰ ﮐﺎﻣﻼ ﻧﻘﺾ ﻧﮑﻨﯿﺪ‪.‬‬

‫‪ .18‬ﺗﻮاﺑﻌﯽ ﺑﺎ ﭼﻨﺪ ﻫﺰار ﺧﻂ و ﯾﺎ ﺣﺘﯽ ﭼﻨﺪﺻﺪ ﺧﻂ ﯾﻌﻨﯽ ﺷﮑﺴﺖ‪.‬‬

‫ﺑﻪ ﯾﺎد داﺷﺘﻪ ﺑﺎﺷﯿﺪ ﮐﻪ ﺗﻮاﺑﻊ ﻗﺮار ﻧﯿﺴﺖ ﺧﻮد ﯾﮏ ﺑﺮﻧﺎﻣﻪ ﮐﺎﻣﻞ ﺑﺎﺷﻨﺪ ﺑﻠﮑﻪ ﻫﺪف آنﻫﺎ ﺟﻠﻮﮔﯿﺮي از ﮐﺪ ﻧﻮﯾﺴﯽ‬
‫ﻣﺠﺪد و اﯾﺠﺎد ﻣﺠﺮدﺳﺎزي‪ 4‬اﺳﺖ ﭘﺲ اﮔﺮ ﺗﺎﺑﻌﯽ ﭼﻨﺪ ﻫﺰار ﺧﻂ ﺷﺪ ﯾﻌﻨﯽ اﯾﻦ ﺗﺎﺑﻊ ﺧﻮد ﯾﮏ ﺑﺮﻧﺎﻣﻪ ﮐﺎﻣﻞ اﺳﺖ‬
‫ﮐﻪ ﻣﯽﺗﻮاﻧﺪ ﻣﺠﺪدا ﺑﻪ ﭼﻨﺪﯾﻦ ﺗﺎﺑﻊ دﯾﮕﺮ ﺷﮑﺴﺘﻪ ﺷﻮد ﻟﺬا ﻫﺮ ﮔﺎه ﭼﻨﯿﻦ ﺗﺎﺑﻌﯽ را در ﺑﺮﻧﺎﻣﻪ ﺧﻮد دﯾﺪﯾﺪ ﺑﺪاﻧﯿﺪ‬
‫ﮐﻪ در ﻃﺮاﺣﯽ ﯾﺎ ﻧﺤﻮه ﭘﯿﺎدهﺳﺎزي اﯾﺮاد اﺳﺎﺳﯽ وﺟﻮد دارد و ﺑﺎﯾﺪ ﺑﺎزﺑﯿﻨﯽ ﺷﻮد‪.‬‬

‫اﻟﺒﺘﻪ ﺗﻮﺟﻪ ﮐﻨﯿﺪ ﮐﻪ در اﯾﻨﺠﺎ ﺗﻌﺪاد ﺧﻄﻮط ﻣﻔﯿﺪ ﺗﺎﺑﻊ ﻣﺪ ﻧﻈﺮ اﺳﺖ ﭼﺮا ﮐﻪ ﺑﺮﺧﯽ ﺧﻄﻮط ﻣﺎﻧﻨﺪ ﻓﻀﺎﻫﺎي ﺧﺎﻟﯽ‬
‫ﮐﻪ ﺟﻬﺖ ﺧﻮاﻧﺎﯾﯽ اﯾﺠﺎد ﺷﺪهاﻧﺪ ﺑﻪ ﺣﺴﺎب ﻧﻤﯽاﯾﻨﺪ‪ .‬ﺑﻬﺘﺮﯾﻦ ﻣﻌﯿﺎر ﺟﻬﺖ ﺑﺮرﺳﯽ اﯾﻨﮑﻪ آﯾﺎ اﯾﻦ ﺗﺎﺑﻊ ﺑﻠﻨﺪﺗﺮ از ﺣﺪ‬
‫ﻧﯿﺎز اﺳﺖ اﯾﻦ اﺳﺖ ﮐﻪ ﻋﻼوه ﺑﺮ ﻃﻮل ﺗﺎﺑﻊ در ﺗﺎﺑﻊ ﺑﯿﺶ از ﯾﮏ ﯾﺎ ﺣﺪاﮐﺜﺮ دو اﻟﮕﻮرﯾﺘﻢ ﭘﯿﺎدهﺳﺎزي ﻧﺸﺪه ﺑﺎﺷﺪ‪.‬‬

‫‪ .19‬از دﺳﺘﻮرات ﺗﻮدرﺗﻮ ﭘﺮﻫﯿﺰ ﮐﻨﯿﺪ‪.‬‬

‫ﺑﺮﺧﯽ ﻣﻮاﻗﻊ ﺑﺮﻧﺎﻣﻪﻧﻮﯾﺴﺎن ﺟﻬﺖ ﮐﻮﺗﺎه ﮐﺮدن ﻃﻮل ﺑﺮﻧﺎﻣﻪ از دﺳﺘﻮرات ﺗﻮدرﺗﻮ اﺳﺘﻔﺎده ﻣﯽﮐﻨﻨﺪ‪ .‬ﻣﺎﻧﻨﺪ ﻣﺜﺎل زﯾﺮ‪:‬‬

‫;)‪a = ((x = sin ( getAngle (feature) / 2.0)) > VALID_SIZE ? 2*x:x‬‬

‫‪Abstraction - 4‬‬
 ‫‪20‬‬ ‫ﺑﺮﻧﺎﻣﻪﻧﻮﯾﺴﯽ‬

‫ﻓﻬﻢ اﯾﻦ ﻧﻮع دﺳﺘﻮرات ﺑﺴﯿﺎر ﺳﺨﺖ و ﺣﺘﯽ ﺑﺮاي ﺧﻮد ﺑﺮﻧﺎﻣﻪﻧﻮﯾﺲ ﻧﯿﺰ ﺑﺴﯿﺎر ﭘﯿﭽﯿﺪه ﻣﯽﺑﺎﺷﺪ و ﻣﯽﺗﻮاﻧﻨﺪ از‬
‫دﺳﺘﻮرات ﺧﻄﺎﺧﯿﺰ ﺑﺮﻧﺎﻣﻪ ﺑﺎﺷﺪ ﻟﺬا از ﻧﻮﺷﺘﻦ اﯾﻦ ﻧﻮع دﺳﺘﻮرات ﺷﺪﯾﺪا ﭘﺮﻫﯿﺰ ﮐﻨﯿﺪ و ﺳﻌﯽ ﮐﻨﯿﺪ دﺳﺘﻮر را ﺑﻪ‬
‫ﭼﻨﺪ دﺳﺘﻮر ﺑﺸﮑﻨﯿﺪ‪ .‬ﻣﺎﻧﻨﺪ ﻧﻤﻮﻧﻪ زﯾﺮ‪:‬‬

‫;‪angle = getAngle (feature) / 2.0‬‬

‫;)‪y = sin (angle‬‬

‫)‪if (y > VALID_SIZE‬‬

‫;‪a = 2 * x‬‬

‫‪else‬‬

‫;‪a = x‬‬

‫‪// OR:‬‬

‫;‪a = x‬‬

‫;‪angle = getAngle (feature) / 2.0‬‬

‫;)‪y = sin (angle‬‬

‫)‪if (y > VALID_SIZE‬‬

‫;‪a = 2 * x‬‬

‫ﭘﺮ واﺿﺢ اﺳﺖ ﮐﻪ ﻧﻤﻮﻧﻪ ﮐﺪ اﺧﯿﺮ ﺑﻪ راﺣﺘﯽ و ﺑﻪ ﺳﺮﻋﺖ ﻗﺎﺑﻞ ﻓﻬﻢ و اﺷﮑﺎل زداﯾﯽ ﻣﯽﺑﺎﺷﺪ‪.‬‬

‫‪ .20‬از ‪ goto‬اﺳﺘﻔﺎده ﻧﮑﻨﯿﺪ‪.‬‬

‫اﺳﺘﻔﺎده از ‪ goto‬ﺑﺎﻋﺚ ﺷﮑﺴﺘﻪ ﺷﺪن ﺳﺎﺧﺘﺎر ﭘﯿﻤﺎﻧﻪاي )‪ (Modular‬ﺑﺮﻧﺎﻣﻪ ﻣﯽﺷﻮد ﻟﺬا اﺳﺘﻔﺎده از آن ﺑﺴﯿﺎر‬
‫ﻧﺎﻣﻨﺎﺳﺐ اﺳﺖ اﻣﺎ در ﯾﮏ ﻣﻮرد اﺳﺘﻔﺎده از اﯾﻦ دﺳﺘﻮر ﻧﻪ ﺗﻨﻬﺎ ﻣﻨﺎﺳﺐ ﺑﻠﮑﻪ ﭘﺴﻨﺪﯾﺪه ﻣﯽﺑﺎﺷﺪ‪.‬‬
 ‫‪21‬‬ ‫ﺑﺮﻧﺎﻣﻪﻧﻮﯾﺴﯽ‬

‫در ﺑﺮﺧﯽ ﻣﻮاﻗﻊ در ﺗﻮاﺑﻊ در ﻧﻘﺎط ﻣﺨﺘﻠﻒ ﺑﺮﻧﺎﻣﻪ ﻣﻨﺎﺑﻌﯽ اﯾﺠﺎد ﻣﯽﺷﻮد ﮐﻪ ﻗﺒﻞ از ﺧﺮوج از ﺗﺎﺑﻊ ﺑﺎﯾﺪ آزاد ﺷﻮﻧﺪ‬
‫اﻣﺎ در ﺗﺎﺑﻊ ﭼﻨﺪﯾﻦ ﻧﻘﻄﻪ ﺧﺮوﺟﯽ وﺟﻮد دارد در ﭼﻨﯿﻦ ﻣﻮاﻗﻌﯽ ﺑﺮاي ﺟﻠﻮﮔﯿﺮي از ﻧﻮﺷﺘﻦ ﺗﮑﺮاري دﺳﺘﻮرات و‬
‫ﻫﻤﭽﻨﯿﻦ ﺷﺮطﻫﺎي زﯾﺎد در اﻧﺘﻬﺎي ﺗﺎﺑﻊ ﺑﺮﭼﺴﺐ ﺧﺮوج زده ﻣﯽﺷﻮد و ﺗﺎﺑﻊ از آن ﻧﻘﻄﻪ ﺧﺎرج ﺷﺪه و ﺗﻤﺎﻣﯽ ﻣﻨﺎﺑﻊ‬
‫را در ﯾﮏ ﻧﻘﻄﻪ آزاد ﻣﯽﮐﻨﺪ ﻣﺎﻧﻨﺪ ﻣﻮرد زﯾﺮ‪:‬‬

‫)( ‪int sampleFunction‬‬

‫{‬

‫…‬

‫;)( ‪x = new foo‬‬

‫‪..‬‬

‫) … ( ‪if‬‬

‫;‪goto END‬‬

‫;)( ‪y = new foo‬‬

‫;)( ‪z = new foo‬‬

‫…‬

‫) … ( ‪for‬‬

‫{‬

‫;) … ( ‪fp = fopen‬‬

‫…‬

‫) … ( ‪if‬‬

‫;‪goto END‬‬

‫}‬

‫‪END:‬‬

‫;‪if (x) delete x‬‬

‫;‪if (y) delete y‬‬

 ‫‪22‬‬ ‫ﺑﺮﻧﺎﻣﻪﻧﻮﯾﺴﯽ‬

‫;‪if (z) delet z‬‬

‫;)‪if (fp) fclose (fp‬‬

‫…‬

‫}‬

‫ﻫﻤﺎﻧﻄﻮر ﮐﻪ دﯾﺪه ﻣﯽﺷﻮد ﭼﻨﺎﻧﭽﻪ از دﺳﺘﻮر ‪ goto‬اﺳﺘﻔﺎده ﻧﻤﯽﺷﺪ ﺑﺮﻧﺎﻣﻪ ﻧﻮﯾﺲ ﻣﺠﺒﻮر ﺑﻮد در ﻧﻘﺎط ﺧﺮوج ﻫﺮ‬
‫ﺑﺎر ﮐﺪ ﺗﮑﺮاري ﻧﻮﺷﺘﻪ ﺗﺎ ﺑﺘﻮاﻧﺪ ﻣﻨﺎﺑﻊ را ﺑﻪ درﺳﺘﯽ آزاد ﮐﻨﺪ‪.‬‬

‫ﻫﻤﭽﻨﯿﻦ در ﺣﻠﻘﻪﻫﺎي ﺗﻮ در ﺗﻮ ﺑﺮاي ﺧﺮوج از ﺣﻠﻘﻪ ﻧﯿﺰ اﺳﺘﻔﺎده از ‪ goto‬ﺑﻼﻣﺎﻧﻊ اﺳﺖ اﻣﺎ ﻫﻤﻮاره ﺑﺎﯾﺪ ﺗﻮﺟﻪ‬
‫داﺷﺖ ﮐﻪ ﺳﺎﺧﺘﺎر ﺻﺤﯿﺢ ﮐﻤﺘﺮ ﻧﯿﺎزﻣﻨﺪ ﺑﻪ اﺳﺘﻔﺎده از ‪ goto‬ﺟﻬﺖ ﺧﺮوج از ﺣﻠﻘﻪ ﻣﯽﺷﻮد ﻟﺬا در ﻫﻨﮕﺎم اﺳﺘﻔﺎده‬
‫از اﯾﻦ روش ﺣﺘﻤﺎ ﻣﻄﻤﺌﻦ ﺑﺎﺷﯿﺪ راهﺣﻞ ﺑﻬﺘﺮي وﺟﻮد ﻧﺪارد‬

‫‪#include .21‬ﻫﺎ را دﺳﺘﻪﺑﻨﺪي ﮐﺮده و ﺑﺎ اوﻟﻮﯾﺖ ﻗﺮار دﻫﯿﺪ‪.‬‬

‫ﻫﻤﻮاره از آوردن ‪#include‬ﻫﺎ ﺑﺼﻮرت ﻧﺎﻣﻨﻈﻢ و درﻫﻢ ﺧﻮدداري ﮐﻨﯿﺪ‪ .‬زﯾﺮ اﯾﻦ اﻣﺮ ﺑﺎﻋﺚ ﻣﯽﺷﻮد ﺑﺮﺧﯽ ﺧﻄﺎﻫﺎ‬
‫در ﺟﺎﻫﺎﯾﯽ ﺧﻮد را ﻧﻤﺎﯾﺎن ﺳﺎزﻧﺪ ﮐﻪ ﺷﻤﺎ اﻧﺘﻈﺎر آن را ﻧﺪارﯾﺪ ﺑﻪ ﻧﻤﻮﻧﻪ زﯾﺮ ﺗﻮﺟﻪ ﮐﻨﯿﺪ‪.‬‬

‫‪/// sample.h‬‬

‫‪#ifndef RG_SAMPLE_H‬‬

‫‪#define RG_SAMPLE_H‬‬

‫‪class RGSample‬‬

‫{‬

‫…‬

‫}‬

‫‪#endif‬‬

‫‪///sample.cpp‬‬

‫"‪#include "sample.h‬‬
 ‫‪23‬‬ ‫ﺑﺮﻧﺎﻣﻪﻧﻮﯾﺴﯽ‬

‫"‪#include "stdio.h‬‬

‫…‬

‫ﮐﺎﻣﭙﺎﯾﻞ اﯾﻦ ﮐﺪ ﺑﺎﻋﺚ ﻣﯽﺷﻮد ﮐﺎﻣﭙﺎﯾﻠﺮ ﺑﻪ ﺷﻤﺎ ﺧﻄﺎﯾﯽ ﺑﺪﻫﺪ ﮐﻪ ﻣﻨﺸﺎ آن را در ﻓﺎﯾﻞ ‪ stdio.h‬اﻋﻼم ﮐﻨﺪ! ﭘﺮ‬
‫واﺿﺢ اﺳﺖ ﮐﻪ در اﯾﻦ ﻓﺎﯾﻞ از دﯾﺪ ﮐﺎﻣﭙﺎﯾﻠﺮ ﺧﻄﺎﯾﯽ ﻧﺒﺎﯾﺪ وﺟﻮد داﺷﺘﻪ ﺑﺎﺷﺪ اﻣﺎ دﻟﯿﻞ ﭼﯿﺴﺖ؟ در واﻗﻊ ﮐﺎﻣﭙﺎﯾﻠﺮ‬
‫ﺑﺎ ﻧﺪﯾﺪن ﻋﻼﻣﺖ ; در اﻧﺘﻬﺎي ﺗﻌﺮﯾﻒ ﮐﻼس ﺗﺎ ; ﺑﻌﺪي را ﺧﻮاﻧﺪه و آﻧﮕﺎه ﺧﻄﺎ را در آن ﻧﻘﻄﻪ اﻋﻼم ﻣﯽﮐﻨﺪ و اﯾﻦ‬
‫; در ﻓﺎﯾﻞ ‪ stdio.h‬دﯾﺪه ﺧﻮاﻫﺪ ﺷﺪ و ﺣﺎل آﻧﮑﻪ ﺧﻄﺎ در ﻓﺎﯾﻞ ‪ sample.h‬ﺑﻮده اﺳﺖ‪ .‬اﯾﻦ ﻣﻮﺿﻮع ﻣﯽﺗﻮاﻧﺪ ﺑﻪ‬
‫ﺳﺮدرﮔﻤﯽ ﺑﺮﻧﺎﻣﻪﻧﻮﯾﺲ ﻣﻨﺠﺮ ﺷﻮد‪.‬‬

‫ﺑﻨﺎﺑﺮاﯾﻦ ﺗﻮﺻﯿﻪ ﻣﯽﺷﻮد ﻫﺪر ﻓﺎﯾﻞﻫﺎ را دﺳﺘﻪ ﺑﻨﺪي ﮐﻨﯿﺪ و ﺑﯿﻦ ﻫﺮ دﺳﺘﻪ ﯾﮏ ﻓﺎﺻﻠﻪ ﻗﺮار دﻫﯿﺪ و آنﻫﺎ را ﺑﺮ‬
‫اﺳﺎس اﻃﻤﯿﻨﺎن ﺑﻪ ﺻﺤﺖ ﮐﺎرﮐﺮد ﺑﺎﻻﺗﺮ از ﺑﺎﻗﯽ ﻗﺮار دﻫﯿﺪ‪ .‬ﺑﻪ اﯾﻦ ﺗﺮﺗﯿﺐ ﻣﻄﻤﺌﻦ ﻫﺪر ﻓﺎﯾﻞﻫﺎي ﺳﯿﺴﺘﻤﯽ ﻗﺒﻞ‬
‫از ﻫﻤﻪ و ﻫﺪر ﻓﺎﯾﻞﻫﺎي ﺧﻮد ﺑﺮﻧﺎﻣﻪ در اﻧﺘﻬﺎ ﺑﺎﯾﺪ ﻗﺮار ﺑﮕﯿﺮد‪.‬‬

‫در ﻧﻤﻮﻧﻪ زﯾﺮ اﻟﮕﻮﯾﯽ ﻋﻤﻮﻣﯽ ﺑﺮاي اﯾﻦ ﻣﻮﺿﻮع ﺑﯿﺎن ﺷﺪه اﺳﺖ‪.‬‬

‫‪#include system header file‬‬

‫‪#include external library header file‬‬

‫‪#include library header file‬‬

‫‪#include program header file‬‬

‫و اﯾﻦ ﻫﻢ ﯾﮏ ﻧﻤﻮﻧﻪ‪:‬‬

‫>‪#include <stdio.h‬‬

‫>‪#include <stdlib.h‬‬
 ‫‪24‬‬ ‫ﺑﺮﻧﺎﻣﻪﻧﻮﯾﺴﯽ‬

‫>‪#include <QWidget‬‬

‫>‪#include <QObject‬‬

‫>‪#include <geos.h‬‬

‫>‪#include <ogr.h‬‬

‫"‪#include "sample.h‬‬

‫‪ .22‬از ‪ #include‬در ﻫﺪر ﻓﺎﯾﻞ اﺳﺘﻔﺎده ﻧﮑﻨﯿﺪ‪.‬‬

‫اﺳﺘﻔﺎده از ‪ #include‬در ﻫﺪر ﻓﺎﯾﻞ ﻣﻌﺎﯾﺐ زﯾﺮ را دارد‪:‬‬

‫‪ .1‬ﭼﻮن ﻫﺪر ﻓﺎﯾﻞﻫﺎ ﺧﻮد در ﻓﺎﯾﻞﻫﺎي ﺳﻮرس وارد ﻣﯽﺷﻮﻧﺪ ﺧﻮد ﺑﺎﻋﺚ ﻧﻘﺾ ﻗﺎﻧﻮن ‪ 21‬ﻣﯽﺷﻮﻧﺪ‪.‬‬
‫‪ .2‬ﺗﻘﺪم و ﺗﺎﺧﺮ ﺑﺮﺧﯽ ﻫﺪر ﻓﺎﯾﻞﻫﺎ ﺑﺎﻋﺚ رﺧﺪاد ﺧﻄﺎ در ﮐﺎﻣﭙﺎﯾﻠﺮ ﻣﯽﺷﻮد‪.‬‬
‫‪ .3‬ﻣﻤﮑﻦ اﺳﺖ ﻫﺪر ﻓﺎﯾﻞﻫﺎي ﻏﯿﺮ ﺿﺮوري در ﺳﻮرس وارد ﺷﺪه و در ﻧﺘﯿﺠﻪ اﯾﺠﺎد واﺑﺴﺘﮕﯽ ﻏﯿﺮ ﺿﺮوري‬
‫ﮐﺮده و زﻣﺎن ﮐﺎﻣﭙﺎﯾﻞ را ﺑﯿﻬﻮده اﻓﺰاﯾﺶ دﻫﺪ‪.‬‬

‫ﻫﺮ ﭼﻨﺪ ﮐﻪ اﯾﻦ ﻗﺎﻧﻮن ﺑﺎﻋﺚ ﺧﻮاﻫﺪ ﺷﺪ ﮐﻪ ﻟﯿﺴﺖ ﺑﻠﻨﺪي از ﻫﺪر ﻓﺎﯾﻞ در ﻫﺮ ﻓﺎﯾﻞ ﺳﻮرس دﯾﺪه ﺷﻮد اﻣﺎ داراي‬
‫ﻣﺰاﯾﺎي زﯾﺮ اﺳﺖ‪:‬‬

‫‪ .1‬واﺑﺴﺘﮕﯽﻫﺎي ﻫﺮ ﺳﻮرس ﻓﺎﯾﻞ در ﻫﻤﺎنﺟﺎ دﯾﺪه ﻣﯽﺷﻮد‪.‬‬

‫‪ .2‬ﻣﻬﻨﺪﺳﯽ ﻣﻌﮑﻮس ﺳﻮرس ﺳﺎدهﺗﺮ ﻣﯽﺷﻮد‪.‬‬

‫اﻟﺒﺘﻪ در ﺑﺮﺧﯽ ﻣﻮارد اﯾﻦ ﻗﺎﻧﻮن ﺑﺎﯾﺪ ﻧﻘﺾ ﺷﻮد ﻣﺎﻧﻨﺪ‪:‬‬

‫‪ .1‬در ﮐﺘﺎﺑﺨﺎﻧﻪﻫﺎ ﻫﺪر ﻓﺎﯾﻠﯽ ﺗﻌﺮﯾﻒ ﻣﯽﺷﻮد ﮐﻪ ﺗﻤﺎﻣﯽ ﻫﺪر ﻓﺎﯾﻞﻫﺎي دﯾﮕﺮ در آن ﻗﺮار ﻣﯽﮔﯿﺮﻧﺪ و در‬
‫ﻫﻨﮕﺎم اﺳﺘﻔﺎده از ﮐﺘﺎﺑﺨﺎﻧﻪ ﺗﻨﻬﺎ آن ﻫﺪر ﻓﺎﯾﻞ ﻧﯿﺎز اﺳﺖ‪.‬‬
‫‪ .2‬ﺑﺮﺧﯽ وﻗﺖﻫﺎ ﻣﻤﮑﻦ اﺳﺖ ﯾﮏ ﮐﻼس ﺧﻮد ﺑﻪ ﭼﻨﺪﯾﻦ ﻓﺎﯾﻞ ﺗﺒﺪﯾﻞ ﺷﻮد اﻣﺎ ﺟﻬﺖ ﻣﺪﯾﺮﯾﺖ راﺣﺖﺗﺮ ﺑﺮاي‬
‫آن ﯾﮏ ﻓﺎﯾﻞ ﻫﺪر و ﺳﻮرس در ﻧﻈﺮ ﻣﯽﮔﯿﺮﻧﺪ ﮐﻪ ﺗﻤﺎﻣﯽ ﻫﺪر ﻓﺎﯾﻞﻫﺎ و ﺳﻮرس ﻓﺎﯾﻞﻫﺎ در اﯾﻦ دو ﻓﺎﯾﻞ‬
‫وارد ﻣﯽﺷﻮﻧﺪ و ﮐﺎﻣﭙﺎﯾﻠﺮ ﻓﻘﻂ اﯾﻦ دو را ﮐﺎﻣﭙﺎﯾﻞ ﻣﯽﮐﻨﺪ‪.‬‬
 ‫‪25‬‬ ‫ﺑﺮﻧﺎﻣﻪﻧﻮﯾﺴﯽ‬

‫‪ .23‬در ﻫﺪر ﻓﺎﯾﻞ ﻫﯿﭽﮕﺎه ﭘﯿﺎدهﺳﺎزي اﻧﺠﺎم ﻧﺪﻫﯿﺪ‪.‬‬

‫ﻫﻤﻮاره ﺑﻪ ﯾﺎد داﺷﺘﻪ ﺑﺎﺷﯿﺪ ﮐﻪ ﻫﺮﺳﺨﻦ ﺟﺎﯾﯽ و ﻫﺮ ﻧﮑﺘﻪ ﻣﮑﺎﻧﯽ دارد ﭘﺲ ﺑﯽﻣﻮﻗﻊ و ﻻﻣﮑﺎن ﺻﺤﺒﺖ ﮐﺮدن‬
‫ﺑﺎﻋﺚ دردﺳﺮ اﺳﺖ؛ ﯾﻌﻨﯽ اﮔﺮ ﺷﻤﺎ در ﻫﺪر ﻓﺎﯾﻞ ﭘﯿﺎدهﺳﺎزي اﻧﺠﺎم دﻫﯿﺪ و ﭘﯿﺎدهﺳﺎزي ﺷﻤﺎ ﺧﻄﺎ داﺷﺘﻪ ﺑﺎﺷﺪ آﻧﮕﺎه‬
‫ﻣﻤﮑﻦ اﺳﺖ ﮐﺎﻣﭙﺎﯾﻠﺮ ﮐﻮﻫﯽ از ﺧﻄﺎ ﺑﻪ ﺷﻤﺎ ﺗﻘﺪﯾﻢ ﮐﻨﺪ‪ .‬ﭼﺮا؟ ﭼﻮن ﻫﺪر ﻓﺎﯾﻞ ﻣﻤﮑﻦ اﺳﺖ در ﭼﻨﺪﯾﻦ ﺳﻮرس‬
‫ﻓﺎﯾﻞ وارد ﺷﺪه ﺑﺎﺷﺪ و در ﻫﺮ ﮐﺪام ﺧﻮد ﻣﻨﺸﺎ ﺣﺪاﻗﻞ ﯾﮏ ﺧﻄﺎ ﺧﻮاﻫﺪ ﺷﺪ‪.‬‬

‫ﻋﻼوه ﺑﺮ آن ﻣﻤﮑﻦ اﺳﺖ ﻧﯿﺎز ﺷﻮد ﻫﺪر ﻓﺎﯾﻞ ﻣﻨﺘﺸﺮ‪ 5‬ﺷﻮد آﻧﮕﺎه ﺳﻮرس ﺷﻤﺎ ﻫﻢ ﻧﯿﺰ ﻣﻨﺘﺸﺮ ﻣﯽﺷﻮد‪.‬‬

‫‪ .24‬از ﭘﯿﺶ ﺗﻌﺮﯾﻒ )‪ (forward definition‬ﭘﺮﻫﯿﺰ ﮐﻨﯿﺪ‪.‬‬

‫ﭼﻨﺎﻧﭽﻪ ﻗﻮاﻧﯿﻦ ‪ 20‬و ‪ 21‬را ﺑﻪ درﺳﺘﯽ رﻋﺎﯾﺖ ﮐﻨﯿﺪ ﻧﯿﺎزي ﺑﻪ ﭘﯿﺶ ﺗﻌﺮﯾﻒ ﻧﺨﻮاﻫﯿﺪ داﺷﺖ‪ .‬اﺳﺘﻔﺎده از ﭘﯿﺶ‬
‫ﺗﻌﺮﯾﻒ ﺗﻨﻬﺎ در زﻣﺎﻧﯽ ﮐﻪ در اﺳﺘﻔﺎده از ﺳﺎﺧﺘﺎرﻫﺎ ﯾﺎ ﮐﻼسﻫﺎ اﯾﺠﺎد ﺣﻠﻘﻪ ﺷﺪه اﺳﺖ‪ ،‬ﻣﺠﺎز ﻣﯽﺑﺎﺷﺪ و در ﺳﺎﯾﺮ‬
‫ﻣﻮارد ﻧﺒﺎﯾﺪ اﯾﻦ ﮐﺎر را ﮐﺮد‪ .‬اﺳﺘﻔﺎده از ﭘﯿﺶ ﺗﻌﺮﯾﻒ ﻣﺸﮑﻼت زﯾﺮ را دارد‪:‬‬

‫‪ .1‬اﮔﺮ ﻧﺎم ﺳﺎﺧﺘﺎر ﯾﺎ ﮐﻼس ﺗﻐﯿﯿﺮ ﮐﻨﺪ ﺗﻘﺮﯾﺒﺎ ﻫﯿﭻ ﻣﺤﯿﻄﯽ وﺟﻮد ﻧﺪارد ﮐﻪ ﺑﺘﻮاﻧﺪ ﺑﺪون اﺳﺘﻔﺎده از اﺑﺰار‬
‫‪ search replace‬ﺑﺼﻮرت ﻫﻮﺷﻤﻨﺪاﻧﻪ ﺗﻤﺎﻣﯽ ﭘﯿﺶﺗﻌﺮﯾﻒﻫﺎ را ﺗﺼﺤﯿﺢ ﮐﻨﺪ‪.‬‬
‫‪ .2‬ﻣﻤﮑﻦ اﺳﺖ ﮐﻼﺳﯽ ﺣﺬف ﺷﻮد اﻣﺎ ﭘﯿﺶﺗﻌﺮﯾﻒ آن ﻫﻤﭽﻨﺎن در ﮐﺪ ﺑﻤﺎﻧﺪ ﮐﻪ ﺧﻮد ﻣﯽﺗﻮاﻧﺪ ﺑﺎﻋﺚ ﺧﻄﺎي‬
‫ﮐﺎﻣﭙﺎﯾﻠﺮ ﯾﺎ ﻟﯿﻨﮑﺮ ﺷﻮد‪.‬‬

‫‪Release - 5‬‬
 ‫‪26‬‬ ‫ﺑﺮﻧﺎﻣﻪﻧﻮﯾﺴﯽ‬

‫‪ 3‬ﺗﻮﺿﯿﺤﺎت‬

‫ﺗﻘﺮﯾﺒﺎ ﻫﯿﭻ ﮐﺘﺎب ﺑﺮﻧﺎﻣﻪﻧﻮﯾﺴﯽ وﺟﻮد ﻧﺪارد ﮐﻪ ﺑﻪ ﺷﺪت در آن ﺗﻮﺻﯿﻪ ﺑﻪ ﻧﻮﺷﺘﻦ ﺗﻮﺿﯿﺤﺎت در ﺑﺮﻧﺎﻣﻪ ﻧﮑﺮده ﺑﺎﺷﺪ‬
‫اﻣﺎ ﻣﻌﻤﻮﻻ ﻧﮑﺘﻪ ﻣﻬﻤﯽ ﮐﻪ ﺑﯿﺎن ﻧﻤﯽﺷﻮد اﯾﻦ اﺳﺖ ﮐﻪ ﻧﻮﺷﺘﻦ ﺗﻮﺿﯿﺤﺎت ﻧﯿﺰ ﺑﺎﯾﺪ ﺑﺮ اﺳﺎس ﻗﺎﻋﺪه و اﺻﻮل ﺑﺎﺷﺪ‪.‬‬
‫ﻧﻮﺷﺘﻦ ﺗﻮﺿﯿﺤﺎت ﺑﺪون ﻗﺎﻋﺪه ﻣﺎﻧﻨﺪ ﺧﻂﺧﻄﯽ ﮐﺮدن ﯾﮏ ﻣﺘﻦ اﺳﺖ ﮐﻪ ﻫﯿﭻ ﮐﻤﮑﯽ ﺑﻪ ﺧﻮاﻧﺎﯾﯽ ﻧﻤﯽﮐﻨﺪ‪.‬‬

‫در ﻧﻮﺷﺘﻦ ﺗﻮﺿﯿﺤﺎت ﺑﺎﯾﺪ از ﻗﺎﻋﺪهاي ﭘﯿﺮوي ﺷﻮد ﮐﻪ ﻋﻼوه ﺑﺮ اﯾﺠﺎد ﺗﻮﺿﯿﺤﺎت در ﺑﺮﻧﺎﻣﻪ اﻣﮑﺎن ﺗﻮﻟﯿﺪ ﻣﺴﺘﻨﺪات‬
‫ﻧﯿﺰ از آن وﺟﻮد داﺷﺘﻪ ﺑﺎﺷﺪ‪ .‬ﺑﺮ اﯾﻦ اﺳﺎس اﺳﺘﺎﻧﺪاردﻫﺎي زﯾﺎدي ﺑﺮاي ﻧﻮﺷﺘﻦ ﺗﻮﺿﯿﺤﺎت اﯾﺠﺎد ﺷﺪه اﺳﺖ ﮐﻪ‬
‫ﻣﻨﺠﺮ ﺑﻪ ﺗﻮﻟﯿﺪ ﻣﺴﺘﻨﺪات ﺑﺮﻧﺎﻣﻪ ﻧﯿﺰ ﻣﯽﺷﻮد ﻣﺎﻧﻨﺪ ‪.doxygen‬‬

‫‪ .25‬ﮐﺪ ﺧﻮد ﻣﺴﺘﻨﺪ‪ 6‬وﺟﻮد ﻧﺪارد ﻟﻄﻔﺎ ﺗﻮﺿﯿﺤﺎت ﺑﻨﻮﯾﺴﯿﺪ‪.‬‬

‫اﻣﺮوزه راﯾﺞ ﺷﺪه اﺳﺖ ﮐﻪ اﻓﺮاد ﻣﺪﻋﯽ ﻫﺴﺘﻨﺪ زﺑﺎنﻫﺎي ﺑﺮﻧﺎﻣﻪ ﻧﻮﯾﺴﯽ ﺧﻮد ﻣﺴﺘﻨﺪ ﻫﺴﺘﻨﺪ و ﻧﯿﺎزي ﻧﯿﺴﺖ در‬
‫ﮐﺪ ﺗﻮﺿﯿﺤﺎت ﺑﮕﺬارﻧﺪ اﻣﺎ ﺑﻪ ﯾﺎد داﺷﺘﻪ ﺑﺎﺷﯿﺪ‪:‬‬

‫‪ .1‬زﺑﺎن ﺑﺮﻧﺎﻣﻪ ﻧﻮﯾﺴﯽ ﻣﺘﻔﺎوت از زﺑﺎن ﮔﻔﺘﺎري ﺷﻤﺎ ﻣﯽﺑﺎﺷﺪ‪.‬‬

‫‪ .2‬زﺑﺎن ﺧﻮد ﻣﺴﺘﻨﺪ ﯾﻌﻨﯽ زﺑﺎن ﮔﻔﺘﺎري و ﺑﻪ ﻧﻈﺮ ﻧﻤﯽآﯾﺪ ﮐﺎﻣﭙﺎﯾﻠﺮي وﺟﻮد داﺷﺘﻪ ﺑﺎﺷﺪ ﮐﻪ زﺑﺎن ﮔﻔﺘﺎري‬
‫را ﺑﻔﻬﻤﺪ )ﺳﺮاغ دارﯾﺪ ﻣﻌﺮﻓﯽ ﮐﻨﯿﺪ!(‬
‫‪ .3‬اﮔﺮ زﺑﺎﻧﯽ ﺧﻮد ﻣﺴﺘﻨﺪ اﺳﺖ ﭼﺮا ﺗﻮﻟﯿﺪ ﮐﻨﻨﺪه آن ﺑﺮاي آن ﻣﺴﺘﻨﺪات ﻧﻮﺷﺘﻪ اﺳﺖ‪.‬‬

‫ﺑﻨﺎﺑﺮاﯾﻦ ﻣﻄﻤﺌﻦ ﺑﺎﺷﯿﺪ زﺑﺎن ﺧﻮد ﻣﺴﺘﻨﺪ وﺟﻮد ﻧﺪارد و ﺑﺎﯾﺪ ﺣﺘﻤﺎ در ﮐﺪ ﺧﻮد ﺗﻮﺿﯿﺤﺎت ﺑﻨﻮﯾﺴﯿﺪ‪.‬‬

‫‪ .26‬ﺗﻮﺿﯿﺢ واﺿﺤﺎت ﻧﺪﻫﯿﺪ‪.‬‬

‫ﻣﻬﻤﺘﺮﯾﻦ ﻫﺪف ﺗﻮﺿﯿﺤﺎت روﺷﻦ ﮐﺮدن و ﺳﺎده ﻧﻤﻮدن ﻓﻬﻢ ﮐﺪﻫﺎي ﭘﯿﭽﯿﺪه اﺳﺖ و ﮐﺴﯽ ﺑﻪ دﻧﺒﺎل درك ﮐﺪﻫﺎي‬
‫ﺳﺎده ﻧﻤﯽﺑﺎﺷﺪ‪.‬‬

‫‪max = ( y > x ? y:x); // find max value‬‬

‫ﺣﺘﯽ ﻓﺮدي ﻫﻢ ﮐﻪ ﯾﮏ ﺧﻂ ﮐﺪ ﻧﻨﻮﺷﺘﻪ ﺑﺎﺷﺪ ﺑﺪون ﺗﻮﺿﯿﺢ ﻫﻢ ﻣﯽﺗﻮاﻧﺪ ﺑﻔﻬﻤﺪ دﺳﺘﻮر ﺑﺎﻻ ﭼﻪ ﻣﯽﮐﻨﺪ ﭘﺲ آب‬
‫در ﻫﺎون ﻧﮑﻮﺑﯿﺪ‪.‬‬

‫‪self document - 6‬‬

 ‫‪27‬‬ ‫ﺑﺮﻧﺎﻣﻪﻧﻮﯾﺴﯽ‬

‫ﺑﺰرﮔﺎن ﻓﺮﻣﻮدهاﻧﺪ‪ » :‬ﻣﻦ ﺷﯿﻄﺎن اﺳﺖ«‪ .‬ﭘﺲ در زﻣﺎن ﻧﻮﺷﺘﻦ ﺗﻮﺿﯿﺤﺎت ﻧﮕﻮﯾﯿﺪ‪ » :‬ﻣﻦ در اﯾﻨﺠﺎ ﻣﻘﺪار ‪ ...‬را‬
‫ﻣﺤﺎﺳﺒﻪ ﻧﻤﻮدم«‪ .‬و ﻫﻤﯿﺸﻪ ﺗﺼﻮر ﮐﻨﯿﺪ دارﯾﺪ ﻣﺴﺘﻨﺪات ﮐﺪ را ﻣﯽﻧﻮﯾﺴﯿﺪ‪.‬‬

‫ﺑﻨﺎﺑﺮاﯾﻦ ﺳﻌﯽ ﮐﻨﯿﺪ در زﻣﺎن ﻧﻮﺷﺘﻦ ﺗﻮﺿﯿﺤﺎت اﻟﮕﻮرﯾﺘﻢ را ﺑﺼﻮرت واﺿﺢ ﺷﺮح دﻫﯿﺪ و ﮐﺎرﮐﺮد ﻫﺮ ﺧﻂ را ﺟﻠﻮي‬
‫آن ﻧﻨﻮﯾﺴﯿﺪ‪.‬‬

‫‪ .27‬از اﺳﺘﺎﻧﺪارد ﭘﯿﺮوي ﮐﻨﯿﺪ‪.‬‬

‫<‪>----------------‬‬

‫‪.28‬ﺳﻌﯽ ﮐﻨﯿﺪ از ﮐﻠﻤﺎت ﮐﻠﯿﺪي اﺳﺘﻔﺎده ﮐﻨﯿﺪ‪.‬‬

‫در ﻫﻨﮕﺎﻣﯽ ﮐﻪ ﺗﻮﺿﯿﺤﺎﺗﯽ ﺟﻬﺖ اﻃﻼﻋﺎ ﺳﺎﯾﺮ ﺑﺮﻧﺎﻣﻪ ﻧﻮﯾﺲﻫﺎ ﻣﯽﻧﻮﯾﺴﯿﺪ و ﻣﺎﯾﻠﯿﺪ ﺑﻪ آن ﺗﻮﺟﻪ ﮐﻨﻨﺪ ﺳﻌﯽ ﮐﻨﯿﺪ‬
‫از ﮐﻠﻤﺎت ﮐﻠﯿﺪي زﯾﺮ اﺳﺘﻔﺎد ﮐﻨﯿﺪ‪.‬‬

‫‪ : TODO:‬ﺟﻬﺖ ﺑﯿﺎن ﻣﻮاردي ﮐﻪ ﻧﺎﻗﺺ اﺳﺖ و ﯾﺎ ﺟﻬﺖ ﺑﻬﺒﻮد ﺑﺎﯾﺪ اﻧﺠﺎم ﺷﻮﻧﺪ‬ ‫‪.1‬‬
‫]‪ : BUG:[bug id‬ﺟﻬﺖ ﺗﻮﺿﯿﺢ ﺧﻄﺎ ﯾﺎ اﺷﮑﺎﻟﯽ ﮐﻪ در ﮐﺪ وﺟﻮد دارد اﻣﺎ راه ﺣﻠﯽ ﺑﺮاي آن ﻧﯿﺴﺖ ﯾﺎ‬ ‫‪.2‬‬
‫ﻫﻨﻮز ﭘﯿﺎده ﺳﺎزي ﻧﺸﺪه اﺳﺖ‪ .‬ﺑﺮاي ﻫﺮ ﺧﻄﺎ ﯾﮏ ﺷﻨﺎﺳﻪ اﯾﺠﺎ دﮐﻨﯿﺪ‪ .‬ﺑﻬﺘﺮﯾﻦ ﺷﻨﺎﺳﻪ ﻧﺎم ﺧﻮدﺗﺎن ﺑﻪ‬
‫ﻫﻤﺮاه ﯾﮏ ﺷﻤﺎره ﺗﺮﺗﯿﺒﯽ اﺳﺖ ﻣﺜﻼ ‪bahman02‬‬
‫‪ : KLUDGE:‬ﻫﺮﮔﺎه ﺑﺨﻮاﻫﯿﺪ ﺑﻪ ﺳﺎﯾﺮﯾﻦ اﻋﻼم ﮐﻨﯿﺪ ﮐﺪي ﮐﻪ ﻧﻮﺷﺘﻪ ﺷﺪه ﻧﺎزﯾﺒﺎ ﯾﺎ ﻧﺎﮐﺎراﻣﺪ اﺳﺖ و ﺑﺎﯾﺪ‬ ‫‪.3‬‬
‫ﻣﺠﺪدا ﺑﺮرﺳﯽ ﺷﻮد‪.‬‬
‫‪ : TRICKY:‬ﻫﺮﮔﺎه در ﻗﺴﻤﺘﯽ از ﮐﺪ از ﺗﺮﻓﻨﺪ ﺧﺎﺻﯽ اﺳﺘﻔﺎده ﮐﺮدهاﯾﺪ ﮐﻪ ﺳﺎﯾﺮﯾﻦ ﺑﺎ آن آﺷﻨﺎ ﻧﯿﺴﺘﻨﺪ‬ ‫‪.4‬‬
‫ﯾﺎ ﮐﺪي اﺳﺖ ﮐﻪ ﺑﻪ ﺗﻐﯿﯿﺮات ﺳﺎﯾﺮ ﻧﻘﺎط ﺑﺮﻧﺎﻣﻪ ﺣﺴﺎس اﺳﺖ ﺑﺎ اﺳﺘﻔﺎده از اﯾﻦ ﮐﻠﻤﻪ ﮐﻠﯿﺪي ﺳﺎﯾﺮﯾﻦ را‬
‫از آن ﺧﺒﺮ دار ﮐﻨﯿﺪ‪.‬‬
‫‪ : WARNING:‬ﻫﺮﮔﺎه در ﮐﺪ ﺧﻮد ﻧﻘﺼﯽ وﺟﻮد دارد ﮐﻪ درﺣﺎل ﺣﺎﺿﺮ ﻣﺸﮑﻠﯽ اﯾﺠﺎد ﻧﻤﯽﮐﻨﺪ اﻣﺎ‬ ‫‪.5‬‬
‫ﭘﺘﺎﻧﺴﯿﻞ اﯾﺠﺎد اﺷﮑﺎل دارد از اﯾﻦ ﮐﻠﻤﻪ اﺳﺘﻔﺎده ﮐﻨﯿﺪ‪.‬‬
‫‪ : COMPILER:‬اﮔﺮ در ﻗﺴﻤﺘﯽ از ﮐﺪ ﺧﻄﺎﯾﯽ وﺟﻮد دارد ﮐﻪ ﻧﺎﺷﯽ از ﮐﺎﻣﭙﺎﯾﻠﺮ اﺳﺖ و ﺷﻤﺎ ﻧﺘﻮاﻧﺴﺘﯿﺪ‬ ‫‪.6‬‬
‫آن را ﺑﺮﻃﺮف ﮐﻨﯿﺪ از اﯾﻦ ﮐﻠﻤﻪ ﺟﻬﺖ ﺗﻮﺿﯿﺤﺎت اﺳﺘﻔﺎده ﮐﻨﯿﺪ‪.‬‬

‫رﻋﺎﯾﺖ اﺳﺘﻔﺎده از ﮐﻠﻤﺎت ﮐﻠﯿﺪي ﺑﺎﻻ ﺳﺒﺐ ﺧﻮاﻫﺪ ﺷﺪ ﺳﺎﯾﺮﯾﻦ ﺑﺎ دﯾﺪن آن‪ ،‬ﺗﻮﺿﯿﺤﺎت ﺷﻤﺎ را ﻣﻄﺎﻟﻌﻪ ﮐﻨﻨﺪ و از‬
‫اﯾﺠﺎد ﺧﻄﺎ ﺟﻠﻮﮔﯿﺮﯾﯽ ﻧﻤﺎﯾﻨﺪ‪.‬‬
 ‫‪28‬‬ ‫ﺑﺮﻧﺎﻣﻪﻧﻮﯾﺴﯽ‬

‫‪ 4‬ﺗﻮﺻﯿﻪﻫﺎي ﺑﺮﻧﺎﻣﻪ ﻧﻮﯾﺴﯽ‬

‫در اﯾﻦ ﺑﺨﺶ ﺗﻮﺻﯿﻪﻫﺎي ﺑﺮرﺳﯽ ﻣﯽﺷﻮﻧﺪ ﮐﻪ در ﻧﮕﺎه اول ﻣﻤﮑﻦ اﺳﺖ ﺧﯿﻠﯽ ﺑﻪ اﺳﺘﺎﻧﺪارد ﮐﺪ ﻧﻮﯾﺴﯽ و ﯾﺎ‬
‫دﺳﺖﮐﻢ ﻇﺎﻫﺮ ﮐﺪ ارﺗﺒﺎﻃﯽ ﻧﺪاﺷﺘﻪ ﺑﺎﺷﺪ اﻣﺎ رﻋﺎﯾﺖ آنﻫﺎ ﺑﻪ ﺷﺪت ﺑﺎﻋﺚ ﺧﻮاﻧﺎﯾﯽ ﮐﺪ‪ ،‬ﭘﺎﯾﺪاري ﮐﺪ و ﺳﻬﻮﻟﺖ ﻓﻬﻢ‬
‫ﮐﺪ ﻣﯽﮔﺮدد‪.‬‬

‫‪ .29‬از ﺑﻪ ﮐﺎر ﺑﺮدن ﻓﻀﺎي ﻧﺎم‪ 7‬و اﻟﮕﻮ‪ 8‬ﺧﻮدداري ﮐﻨﯿﺪ‪.‬‬

‫ﻓﻀﺎي ﻧﺎم اﺑﺰار ﻣﻨﺎﺳﺒﯽ ﺑﺮاي دﺳﺘﻪ ﺑﻨﺪي اﺳﺖ اﻣﺎ اﺳﺘﻔﺎده از آن ﻣﺸﮑﻼت زﯾﺮ را ﻣﯽﺗﻮاﻧﺪ ﺑﻪ ﻫﻤﺮاه داﺷﺘﻪ ﺑﺎﺷﺪ‪:‬‬

‫‪ .1‬دﺳﺘﻮرات را ﺑﯿﻬﻮده ﻃﻮﻻﻧﯽ ﻣﯽﮐﻨﺪ‪ .‬ﻣﺎﻧﻨﺪ ‪mapserver::map::features::VSField‬‬

‫‪ .2‬اﺳﺘﻔﺎده از اﯾﻦ اﺑﺰار ﺑﺮاي دﺳﺘﻪﺑﻨﺪي ﻣﻤﮑﻦ اﺳﺖ ﺑﺮﻧﺎﻣﻪ ﻧﻮﯾﺲ را دﭼﺎر ﺧﻄﺎ ﮐﺮده و ﮐﻼﺳﯽ ﺑﺎ ﻧﺎم ﻣﺸﺎﺑﻪ‬
‫در دو ﻓﻀﺎي ﻧﺎم ﻣﺨﺘﻠﻒ اﯾﺠﺎد ﻧﻤﺎﯾﺪ ﮐﻪ ﺑﺮﻧﺎﻣﻪ را ﺧﻄﺎ ﺧﯿﺰ ﻧﻤﺎﯾﺪ‬

‫ﺑﻨﺎﺑﺮاﯾﻦ اﺳﺘﻔﺎده از ﻓﻀﺎي ﻧﺎم ﻏﯿﺮ ﺿﺮوري ﻣﯽﻧﻤﺎﯾﺪ‪.‬‬

‫اﻟﮕﻮﻫﺎ ﻧﯿﺰ اﺑﺰارﻫﺎي ﻣﻨﺎﺳﺒﯽ ﺑﺮاي ﺗﻮﻟﯿﺪ ﮐﻼسﻫﺎ ﻋﺎم ﻣﻨﻈﻮره ﯾﺎ ﭼﻨﺪ ﻣﻨﻈﻮره ﻧﻤﯽﺑﺎﺷﺪ‪ .‬ﭼﺮا ﮐﻪ اﯾﻦ ﮐﻼسﻫﺎ‬
‫ﻫﯿﭻ ﺑﻬﯿﻨﻪﺳﺎزي در ﮐﺪ اﯾﺠﺎد ﻧﺸﺪه و در زﻣﺎن ﮐﺎﻣﭙﺎﯾﻞ ﺣﺠﻢ ﮐﺪ اﻓﺰاﯾﺶ ﻣﯽﯾﺎﯾﺪ و ﻫﻤﯿﻨﻄﻮر در زﻣﺎن اﺷﮑﺎل‬
‫زداﯾﯽ اﻃﻼﻋﺎت ﻧﻮع ﻧﺎﻣﺸﺨﺺ اﺳﺖ‪ .‬ﻫﻤﭽﻨﯿﻦ ﺑﺎ اﺳﺘﻔﺎده از وراﺛﺖ اﺑﺰار ﺑﺴﯿﺎر ﻗﻮﯾﺘﺮي وﺟﻮد دارد ﮐﻪ ﻣﯽﺗﻮان‬
‫ﺟﺎﯾﮕﺰﯾﻦ آن ﻧﻤﻮد‪.‬‬

‫‪ .30‬ﺳﻌﯽ ﮐﻨﯿﺪ در ﺑﺮﻧﺎﻣﻪ اﺳﺘﺜﻨﺎ‪ 9‬ﺗﻮﻟﯿﺪ ﻧﮑﻨﯿﺪ‪.‬‬

‫ﺑﻪ ﯾﺎد داﺷﺘﻪ ﺑﺎﺷﯿﺪ زﻣﺎﻧﯽ ﮐﻪ اﺳﺘﺜﻨﺎ ﺗﻮﻟﯿﺪ ﻣﯽﮐﻨﯿﺪ ﺑﺎﯾﺪ در ﺟﺎﯾﯽ آن را ﻣﺪﯾﺮﯾﺖ ﮐﻨﯿﺪ و در آن ﻧﻘﻄﻪ ﻣﺠﺒﻮر‬
‫ﺧﻮاﻫﯿﺪ ﺷﺪ از ﺑﻠﻮك )( ‪ try {} catch‬اﺳﺘﻔﺎده ﮐﻨﯿﺪ‪ .‬اﯾﻦ ﺑﻠﻮك ﮐﺪ ﺷﻤﺎ را ﺑﺴﯿﺎر ﻧﺎﮐﺎراﻣﺪ ﻣﯽﮐﻨﺪ ﭼﺮا ﮐﻪ ﮐﺎﻣﭙﺎﯾﻠﺮ‬
‫ﻣﺠﺒﻮر اﺳﺖ ﺑﻪ ازاي ﻫﺮ ﺧﻂ‪ ،‬ﺧﻄﺎ ﺗﻮﻟﯿﺪ و ﻣﺘﻐﯿﺮﻫﺎ را ﺟﻬﺖ ﺗﻮﻟﯿﺪ اﺳﺘﺜﻨﺎ ﺑﺮرﺳﯽ ﮐﻨﺪ ﮐﻪ ﻣﯽﺗﻮان ﺗﺼﻮر ﻧﻤﻮد ﺗﺎ‬
‫ﭼﻪ ﺣﺪ ﮐﺎراﯾﯽ ﮐﺪ از ﺑﯿﻦ ﻣﯽرود‪.‬‬

‫ﻋﻼوه ﺑﺮ اﯾﻦ اﮐﺜﺮ ﺑﺮﻧﺎﻣﻪ ﻧﻮﯾﺲﻫﺎ ﭼﻨﺪان ﺧﻮد را درﮔﯿﺮ ﻣﺪﯾﺮﯾﺖ ﺧﻄﺎ ﻧﻤﯽﮐﻨﻨﺪ ﻟﺬا اﺳﺘﺜﻨﺎﻫﺎ ﺑﺎﻋﺚ ﻧﺎﭘﺎﯾﺪاري ﮐﺪ‬
‫ﺧﻮاﻫﺪ ﺷﺪ‪.‬‬

‫‪Namespace - 7‬‬
‫‪Template - 8‬‬
‫‪Exception - 9‬‬
 ‫‪29‬‬ ‫ﺑﺮﻧﺎﻣﻪﻧﻮﯾﺴﯽ‬

‫‪ .31‬از ﺗﻌﺮﯾﻒ ﮐﻼسﻫﺎي ﻣﻨﻔﺮد‪ 10‬و ﻣﺘﻐﯿﺮﻫﺎي اﯾﺴﺘﺎ‪ 11‬ﺟﺪدا ﺧﻮداري ﮐﻨﯿﺪ‪.‬‬

‫÷‬ ‫ﯾﮑﯽ از اﻫﺪاف ﺑﺮﻧﺎﻣﻪ ﻧﻮﯾﺴﯽ ﺷﯽ ﮔﺮا ﭘﻨﻬﺎن ﺳﺎزي اﻃﻼﻋﺎت و ﮐﭙﺴﻮﻟﻪ ﮐﺮدن آن اﺳﺖ اﻣﺎ ﮐﻼسﻫﺎي‬
‫ﻣﻨﻔﺮد و ﻣﺘﻐﯿﺮﻫﺎي اﯾﺴﺘﺎ اﯾﻦ ﻣﻮﺿﻮع را ﻧﻘﺾ ﻣﯽﮐﻨﻨﺪ‪ .‬اﺳﺘﻔﺎده از اﯾﻦ ﮐﻼسﻫﺎ ﯾﺎ ﻣﺘﻐﯿﺮﻫﺎ ﺑﺎﯾﺪ ﺑﺎ ﺗﻮﺟﯿﻪ ﻣﻨﺎﺳﺒﯽ‬
‫ﻫﻤﺮاه ﺑﺎﺷﺪ‪.‬‬

‫ﻋﻼوه ﺑﺮ آن در ﺑﺮﻧﺎﻣﻪﻫﺎي ﻣﺒﺘﻨﯽ ﺑﺮ ﻧﺦ )‪ (thread base programming‬اﯾﻦ ﻧﻮع ﮐﻼسﻫﺎ و ﻣﺘﻐﯿﺮﻫﺎ ﺑﻪ ﺷﺪت‬
‫ﺧﻄﺎﺧﯿﺰ ﺑﻮده و ﻣﻮﺟﺒﺎت ﻧﺎﭘﺎﯾﺪاري ﺑﺮﻧﺎﻣﻪ ﻣﯽﺑﺎﺷﻨﺪ‪.‬‬

‫‪ .32‬در ﺳﺎزﻧﺪهﻫﺎ ﭘﯿﺎدهﺳﺎزي اﻧﺠﺎم ﻧﺪﻫﯿﺪ‬

‫ﻫﻤﺎﻧﻄﻮر ﮐﻪ ﻣﯽداﻧﯿﺪ ﺳﺎزﻧﺪهﻫﺎ ﻧﻤﯽﺗﻮاﻧﻨﺪ ﺧﻄﺎ ﺑﺮﮔﺮداﻧﺪ و ﻫﺮﮔﺎه ﻓﺮاﺧﻮاﻧﯽ ﻣﯽﺷﻮﻧﺪ ﻓﻀﺎ را ﺑﺮاي ﻣﺘﻐﯿﺮ اﺷﻐﺎل‬
‫ﻣﯽﮐﻨﻨﺪ ﭘﺲ اﮔﺮ ﺧﻄﺎﯾﯽ در آنﻫﺎ رخ دﻫﺪ اﻣﮑﺎن ردﮔﯿﺮي آن وﺟﻮد ﻧﺪارد ﭘﺲ ﺳﻌﯽ ﮐﻨﯿﺪ در ﺳﺎزﻧﺪﻫﺎ ﺗﻨﻬﺎ‬
‫ﻣﻘﺪاردﻫﯽ اوﻟﯿﻪ ﮐﻨﯿﺪ و دﺳﺘﻮراﺗﯽ را اﺟﺮا ﮐﻨﯿﺪ ﮐﻪ ﺧﻄﺎ اﯾﺠﺎد ﻧﻤﯽﮐﻨﻨﺪ‪.‬‬

‫‪ .33‬ﺗﻮاﺑﻊ ﺣﺘﻤﺎ ﺷﻤﺎره ﺧﻄﺎ ﺑﺮﮔﺮداﻧﻨﺪ‪.‬‬

‫ﺑﺴﯿﺎر ﻣﻬﻢ اﺳﺖ ﮐﻪ ﻫﺮﮔﺎه ﺗﺎﺑﻌﯽ ﻓﺮاﺧﻮاﻧﯽ ﻣﯽﺷﻮد و در آن اﻟﮕﻮرﯾﺘﻤﯽ اﺟﺮا ﻣﯽﺷﻮد ﺑﻪ ﻧﺤﻮي ﻓﺮاﺧﻮاﻧﻨﺪه ﺑﺘﻮاﻧﺪ‬
‫از ﻧﺘﯿﺠﻪ ﮐﺎر ﻣﻄﻠﻊ ﺷﻮد ﻟﺬا ﺗﻮﺻﯿﻪ ﻣﯽﺷﻮد ﻣﺠﻤﻮﻋﻪاي از ﺧﻄﺎﻫﺎ ﺑﺮاي ﻫﺮ ﺗﺎﺑﻊ ﺗﻌﺮﯾﻒ ﺷﻮد و ﺗﺎﺑﻊ در ﺻﻮرت‬
‫اﺟﺮا ﻣﻮﻓﻘﯿﺖ آﻣﯿﺰ ﻣﻘﺪار ﺻﻔﺮ ﺑﺮﮔﺮداﻧﺪ و در ﻏﯿﺮ اﯾﻨﺼﻮرت ﺷﻤﺎره ﺧﻄﺎ را ﺑﺮﮔﺮداﻧﺪ‪ .‬اﻟﺒﺘﻪ در ﺑﺮﺧﯽ ﻣﻮاﻗﻊ ﺗﻮاﺑﻊ‬
‫ﺑﺎ ﺗﻌﯿﯿﻦ ﻣﺤﺪوده ﻧﯿﺰ ﺷﻤﺎره ﺧﻄﺎ ﺑﺮﻣﯽﮔﺮداﻧﻨﺪ ﻣﺜﻼ اﮔﺮ ﻣﻘﺪار ﺑﯿﺶ از ﺻﻔﺮ ﺑﺎﺷﺪ ﯾﻌﻨﯽ ﺟﻮاب ﺻﺤﯿﺢ و اﮔﺮ ﮐﻤﺘﺮ‬
‫از ﺻﻔﺮ ﺑﺎﺷﺪ ﯾﻌﻨﯽ ﺧﻄﺎ‪.‬‬

‫ﺑﻪ ﻫﺮ ﺣﺎل ﺑﺴﯿﺎر ﻣﻬﻢ اﺳﺖ ﮐﻪ ﻓﺮاﺧﻮاﻧﻨﺪه ﺑﻪ ﻧﺤﻮي از روﻧﺪ اﺟﺮاي ﺗﺎﺑﻊ ﻣﻄﻠﻊ ﺷﻮد ﭘﺲ ﺟﻌﺒﻪ ﺳﯿﺎه ﻧﺴﺎزﯾﺪ‪.‬‬

‫‪.34‬از ﻋﺒﺎرات رﯾﺎﺿﯽ اﺳﺘﻔﺎده ﮐﻨﯿﺪ‬

‫در اﻏﻠﺐ ﻣﻮاﻗﻊ ﺑﺮﻧﺎﻣﻪﻧﻮﯾﺲ ﻫﺎ ﺑﻪ ﺟﺎي ﺗﺠﺰﯾﻪ و ﺗﺤﻠﯿﻞ ﻣﺴﺎﻟﻪ و اراﺋﻪ راه ﺣﻞ ﻣﻨﺎﺳﺐ از دﺳﺘﻮرات ﻣﺘﻌﺪد ﺑﺮﻧﺎﻣﻪ‪-‬‬
‫ﻧﻮﯾﺴﯽ ﻣﺎﻧﻨﺪ … ‪ if, switch, for,‬اﺳﺘﻔﺎده ﻣﯽﮐﻨﻨﺪ در ﺣﺎﻟﯿﮑﻪ ﺑﺎ اﻧﺪﮐﯽ ﺗﺠﺰﯾﻪ و ﺗﺤﻠﯿﻞ ﺑﻪ راﺣﺘﯽ ﻣﯽﺗﻮان ﺑﺎ‬

‫‪Singleton - 10‬‬
‫‪Static - 11‬‬
 ‫‪30‬‬ ‫ﺑﺮﻧﺎﻣﻪﻧﻮﯾﺴﯽ‬

‫ﯾﮏ راﺑﻄﻪ رﯾﺎﺿﯽ دﺳﺘﻮرات ﻣﺘﻌﺪد را ﺣﺬف ﻧﻤﻮد‪ .‬ﻣﺜﻼ ﻓﺮض ﮐﻨﯿﺪ زاوﯾﻪ )‪ θ(teta‬ﻣﺸﺨﺺ اﺳﺖ و ﺑﺎﯾﺪ ﺗﻌﯿﯿﻦ‬
‫ﻧﻤﻮد در ﮐﺪام ﻧﺎﺣﯿﻪ ﻗﺮار دارد‪.‬‬

‫)‪if (teta > 0 && teta < 90‬‬

‫;‪area = 1‬‬

‫)‪if (teta > 90 && teta < 180‬‬

‫;‪area = 2‬‬

‫)‪if (teta > 180 && teta < 270‬‬

‫;‪area = 3‬‬

‫)‪if (teta > 270 && teta < 360‬‬

‫;‪area = 4‬‬

‫ﺑﻪ راﺣﺘﯽ ﻣﯽﺗﻮان دﯾﺪ ﺑﻪ ﺟﺎي ‪ 8‬ﺧﻂ ﺑﺎﻻ ﻣﯽﺗﻮان ﺧﻂ زﯾﺮ را ﺟﺎﯾﮕﺰﯾﻦ ﻧﻤﻮد‪.‬‬

‫;‪area = (int)(teta / 90.0) + 1‬‬

‫ﺑﻨﺎﺑﺮاﯾﻦ ﺑﺎ ﺗﺠﺰﯾﻪ و ﺗﺤﻠﯿﻞ ﻣﺴﺎﻟﻪ ﻣﯽﺗﻮان ﮐﺪ را ﮐﻮﺗﺎﻫﺘﺮ و ﺧﻮاﻧﺎﺗﺮ ﻧﻤﻮد‪ .‬راه اول ﺳﺎدهﺗﺮﯾﻦ راه و اوﻟﯿﻦ راﻫﯽ‬
‫اﺳﺖ ﮐﻪ ﺑﻪ ذﻫﻦ ﺑﺮﻧﺎﻣﻪﻧﻮﯾﺲ ﻣﯽرﺳﺪ ﻟﺬا ﻫﻤﻮاره اوﻟﯿﻦ راهﺣﻞ ﺑﻬﺘﺮﯾﻦ راهﺣﻞ ﻧﯿﺴﺖ‪.‬‬
 ‫‪31‬‬ ‫ﺑﺮﻧﺎﻣﻪﻧﻮﯾﺴﯽ‬

‫‪ 5‬ﻟﯿﺴﺖ ﺗﻮﺻﯿﻪﻫﺎ‬

‫‪ .1‬ﻧﺎم ﻣﺘﻐﯿﺮ را ﻣﺘﻨﺎﺳﺐ ﺑﺎ ﮐﺎرﺑﺮد آن ﺗﻌﺮﯾﻒ ﮐﻨﯿﺪ‪.‬‬

‫‪ .2‬ﺗﻤﺎﻣﯽ ﻣﺘﻐﯿﺮﻫﺎ در اﺑﺘﺪاي ﺗﺎﺑﻊ ﺗﻌﺮﯾﻒ ﺷﻮﻧﺪ‬

‫‪ .3‬ﻧﺎم ﻣﺘﻐﯿﺮ ﺑﺎ ﺣﺮوف ﮐﻮﭼﮏ ﺷﺮوع ﺷﻮد و در ﻣﺘﻐﯿﺮﻫﺎي ﭼﻨﺪ ﮐﻠﻤﻪاي ﺣﺮف اول ﻫﺮ ﮐﻠﻤﻪ‪ ،‬ﻏﯿﺮ‬
‫از ﮐﻠﻤﻪ اول‪ ،‬ﺑﺎ ﺣﺮوف ﺑﺰرگ ﺑﺎﺷﺪ‪.‬‬

‫‪ .4‬ﺑﺮاي ﻣﺘﻐﯿﺮﻫﺎﯾﯽ ﮐﻪ ﯾﮏ ﻫﺪف دارﻧﺪ ﻧﺎمﻫﺎي ﻣﺨﺘﻠﻒ و ﻣﻨﺎﺳﺐ اﻧﺘﺨﺎب ﮐﻨﯿﺪ‪.‬‬

‫‪ .5‬از ﭘﺴﻮﻧﺪ ‪ s‬ﺟﻬﺖ ﻣﺘﻐﯿﺮﻫﺎي ﮐﻪ ﺑﯿﺎﻧﮕﺮ ﺗﻌﺪاد ﻫﺴﺘﻨﺪ ﺻﺮﻓﻨﻈﺮ ﮐﻨﯿﺪ و ﺑﻪ ﺟﺎي آن از ﭘﺴﻮﻧﺪ ‪List‬‬
‫ﯾﺎ ﭘﯿﺸﻮﻧﺪ ‪ n‬اﺳﺘﻔﺎده ﮐﻨﯿﺪ‪.‬‬

‫‪ .6‬ﻃﻮل ﻧﺎم ﻣﺘﻐﯿﺮ ﻣﺘﻨﺎﺳﺐ ﺑﺎ ﺣﻮﺿﻪ دﯾﺪ آن ﺑﺎﺷﺪ‪.‬‬

‫‪ .7‬در ﻫﻨﮕﺎم ﺗﻌﺮﯾﻒ ﮐﺮدن اﺷﺎرهﮔﺮ * را ﺑﻪ ﻣﺘﻐﯿﺮ ﺑﭽﺴﺎﻧﯿﺪ ﻧﻪ ﺑﻪ ﻧﻮع آن‪.‬‬

‫‪ .8‬ﻧﺎم ﻣﺘﻐﯿﺮﻫﺎي ﮐﻼﺳﯽ ﺑﺎ ﭘﯿﺸﻮﻧﺪ ‪ m‬ﺷﺮوع ﺷﻮد‪.‬‬

‫‪ .9‬ﺷﻤﺎرﻧﺪهﻫﺎي ﺣﻠﻘﻪ را ‪ i, j, k‬ﺑﻨﺎﻣﯿﺪ و اﮔﺮ ﺑﯿﺶ از ﺳﻪ ﺳﻄﺢ ﺗﻮدرﺗﻮﯾﯽ داﺷﺘﯿﺪ از ‪ l, m, n‬ﺑﺮاي‬

‫ﺳﻄﻮح داﺧﻠﯽ اﺳﺘﻔﺎده ﮐﻨﯿﺪ‪.‬‬

‫‪ .10‬ﻧﺎم ﮐﻼسﻫﺎ‪ ،‬اﻧﻮاع ‪ type‬و ﺳﺎﺧﺘﺎرﻫﺎ ‪ structure‬ﺣﺘﻤﺎ ﺑﺎ ﺣﺮوف ﺑﺰرگ و ﺑﺎ ﭘﯿﺸﻮﻧﺪ ‪ RG‬ﺷﺮوع‬
‫ﺷﻮد‪.‬‬

‫‪ .11‬ﻧﺎم ﻣﺎﮐﺮوﻫﺎ ﺗﻤﺎﻣﯽ ﺑﺎ ﺣﺮوف ﺑﺰرگ و ﺑﺎ ﺧﻂ ﺗﯿﺮه زﯾﺮ _ ﮐﻠﻤﺎت از ﯾﮑﺪﯾﮕﺮ ﺟﺪا ﺷﻮﻧﺪ‪.‬‬

‫‪ .12‬ﻧﺎم ﺗﻮاﺑﻊ ﺑﺎ ﺣﺮوف ﮐﻮﭼﮏ ﺷﺮوع ﺷﺪه ‪،‬ﻣﺎﻧﻨﺪ ﻗﺎﻧﻮن ‪ ،3‬و ﺑﯿﺎن ﮐﻨﻨﺪه ﮐﺎرﮐﺮد ﺗﺎﺑﻊ ﺑﺎﺷﺪ‪.‬‬

‫‪ .13‬ﮐﺪ ﺧﻮد را ﺷﻠﻮغ ﻧﮑﻨﯿﺪ‪.‬‬

‫‪ .14‬از ﺷﮑﺴﺘﻦ ﺑﯽﻣﻮرد ﺧﻄﻮط ﭘﺮﻫﯿﺰ ﮐﻨﯿﺪ‪.‬‬

‫‪ .15‬از ﺑﻪ ﮐﺎرﺑﺮدن اﻋﺪاد ﺟﺎدوﯾﯽ ﭘﺮﻫﯿﺰ ﮐﻨﯿﺪ‪.‬‬

‫‪32‬‬ ‫ﺑﺮﻧﺎﻣﻪﻧﻮﯾﺴﯽ‬

‫‪ .16‬ﻓﻀﺎي ﺧﺎﻟﯽ )‪ (space‬اﺑﺰار ﺟﺎدوﯾﯽ زﯾﺒﺎ ﺳﺎزي اﺳﺖ‪.‬‬

‫‪ .17‬ﺗﻮاﺑﻌﯽ ﺑﺎ ﭼﻨﺪ ﻫﺰار ﺧﻂ و ﯾﺎ ﺣﺘﯽ ﭼﻨﺪﺻﺪ ﺧﻂ ﯾﻌﻨﯽ ﺷﮑﺴﺖ‪.‬‬

‫‪ .18‬از دﺳﺘﻮرات ﺗﻮدرﺗﻮ ﭘﺮﻫﯿﺰ ﮐﻨﯿﺪ‪.‬‬

‫‪ .19‬از ‪ goto‬اﺳﺘﻔﺎده ﻧﮑﻨﯿﺪ‪.‬‬

‫‪#include .20‬ﻫﺎ را دﺳﺘﻪﺑﻨﺪي ﮐﺮده و ﺑﺎ اوﻟﻮﯾﺖ ﻗﺮار دﻫﯿﺪ‪.‬‬

‫‪ .21‬از ‪ #include‬در ﻫﺪر ﻓﺎﯾﻞ اﺳﺘﻔﺎده ﻧﮑﻨﯿﺪ‪.‬‬

‫‪ .22‬در ﻫﺪر ﻓﺎﯾﻞ ﻫﯿﭽﮕﺎه ﭘﯿﺎدهﺳﺎزي اﻧﺠﺎم ﻧﺪﻫﯿﺪ‪.‬‬

‫‪.23‬از ﭘﯿﺶ ﺗﻌﺮﯾﻒ )‪ (forward definition‬ﭘﺮﻫﯿﺰ ﮐﻨﯿﺪ‪.‬‬

‫‪ .24‬ﮐﺪ ﺧﻮد ﻣﺴﺘﻨﺪ )‪ (self document‬وﺟﻮد ﻧﺪارد ﻟﻄﻔﺎ ﺗﻮﺿﯿﺤﺎت ﺑﻨﻮﯾﺴﯿﺪ‪.‬‬

‫‪ .25‬ﺗﻮﺿﯿﺢ واﺿﺤﺎت ﻧﺪﻫﯿﺪ‪.‬‬

‫‪ .26‬از اﺳﺘﺎﻧﺪارد ﭘﯿﺮوي ﮐﻨﯿﺪ‪.‬‬

‫‪ .27‬ﺳﻌﯽ ﮐﻨﯿﺪ از ﮐﻠﻤﺎت ﮐﻠﯿﺪي اﺳﺘﻔﺎده ﮐﻨﯿﺪ‪.‬‬

‫‪.28‬از ﺑﻪ ﮐﺎر ﺑﺮدن ﻓﻀﺎي ﻧﺎم )‪ (namespace‬و اﻟﮕﻮ )‪ (template‬ﺧﻮدداري ﮐﻨﯿﺪ‪.‬‬

‫‪ .29‬ﺳﻌﯽ ﮐﻨﯿﺪ در ﺑﺮﻧﺎﻣﻪ اﺳﺘﺜﻨﺎ )‪ (exception‬ﺗﻮﻟﯿﺪ ﻧﮑﻨﯿﺪ‪.‬‬

‫‪ .30‬از ﺗﻌﺮﯾﻒ ﮐﻼسﻫﺎي ﻣﻨﻔﺮد )‪ (singleton‬و ﻣﺘﻐﯿﺮﻫﺎي اﯾﺴﺘﺎ )‪ (static‬ﺟﺪدا ﺧﻮداري ﮐﻨﯿﺪ‪.‬‬

‫‪ .31‬در ﺳﺎزﻧﺪهﻫﺎ ﭘﯿﺎدهﺳﺎزي اﻧﺠﺎم ﻧﺪﻫﯿﺪ‬

‫‪ .32‬ﺗﻮاﺑﻊ ﺣﺘﻤﺎ ﺷﻤﺎره ﺧﻄﺎ ﺑﺮﮔﺮداﻧﻨﺪ‪.‬‬