குறியீட்டு விதிகள்: சரியான பெயர்கள், நல்ல மற்றும் கெட்ட கருத்துகளின் சக்தி

வேறொருவரின் குறியீட்டை நீங்கள் எவ்வளவு அடிக்கடி தோண்டி எடுக்க வேண்டியிருந்தது? இரண்டு மணிநேரத்திற்குப் பதிலாக, என்ன நடக்கிறது என்பதற்கான தர்க்கத்தை எளிமையாகப் புரிந்துகொள்ள நீங்கள் இரண்டு நாட்கள் செலவிடலாம். வேடிக்கையான விஷயம் என்னவென்றால், குறியீட்டை எழுதியவருக்கு, எல்லாம் தெளிவாகவும் முற்றிலும் வெளிப்படையானதாகவும் இருக்கும். இது ஆச்சரியமல்ல: எல்லாவற்றிற்கும் மேலாக, சரியான குறியீடு என்பது மிகவும் தெளிவற்ற கருத்தாகும், ஏனென்றால் ஒவ்வொரு டெவலப்பருக்கும் உலகம் மற்றும் குறியீட்டைப் பற்றிய சொந்த பார்வை உள்ளது. நானும் ஒரு சக ஊழியரும் ஒரே குறியீட்டைப் பார்த்து, அதன் சரியான தன்மை மற்றும் தூய்மையைப் பற்றி வெவ்வேறு கருத்துக்களைக் கொண்ட ஒரு சூழ்நிலையில் ஒன்றுக்கு மேற்பட்ட முறை நான் இருந்திருக்கிறேன்.தெரிந்ததாக தெரிகிறது, இல்லையா? இருப்பினும், கடைபிடிக்க வேண்டிய சில நேர சோதனைக் கொள்கைகள் உள்ளன. இறுதியில், அவை உங்களுக்கு சாதகமாக இருக்கும், ஏனென்றால் உங்கள் குறியீட்டை நீங்களே பெற விரும்பும் நிலையில் விட்டுவிட்டால், உலகம் கொஞ்சம் மகிழ்ச்சியாகவும் சுத்தமாகவும் மாறும். எங்கள் முந்தைய கட்டுரையில்(அல்லது மாறாக, சிறிய வழிகாட்டி) குறியீட்டு விதிகள் பற்றி, ஒரு அமைப்பை முழுவதுமாக எழுதுவதற்கான பரிந்துரைகள் மற்றும் பொருள்கள், இடைமுகங்கள், வகுப்புகள், முறைகள் மற்றும் மாறிகள் போன்ற அதன் அங்கமான பகுதிகளை எழுதுவதற்கான சிறிதளவு பரிந்துரைகளைப் பெற்றுள்ளோம். அதே கட்டுரையில், சில உறுப்புகளின் சரியான பெயரை நான் சாதாரணமாக குறிப்பிட்டேன். இன்று நான் இதைப் பற்றி பேச விரும்புகிறேன், ஏனென்றால் சரியான பெயர்கள் குறியீட்டைப் படிக்க பல மடங்கு எளிதாக்குகின்றன. சில பிரதிபலிப்புகள், குறியீட்டில் உள்ள கருத்துகளின் சிறிய எடுத்துக்காட்டுகள் மற்றும் இது நல்லதா இல்லையா என்பதைக் கருத்தில் கொண்டு சரியான குறியீட்டின் தலைப்பை நாங்கள் மூடுவோம். சரி, ஆரம்பிக்கலாம்.

சரியான பெயர்கள்

சரியான பெயர்கள் குறியீடு வாசிப்புத்திறனை மேம்படுத்துகின்றன, இதனால் குறியீட்டைப் பற்றி உங்களைப் பழக்கப்படுத்திக்கொள்ள வேண்டிய நேரத்தைக் குறைக்கிறது, ஏனெனில் ஒரு முறையை அதன் பெயர் தோராயமாக அதன் செயல்பாட்டை விவரிக்கும் போது பயன்படுத்துவது மிகவும் எளிதானது. குறியீட்டில் உள்ள அனைத்தும் பெயர்களைக் கொண்டுள்ளது (மாறிகள், முறைகள், வகுப்புகள், பொருள்கள், கோப்புகள் போன்றவை), எனவே சரியான, சுத்தமான குறியீட்டை உருவாக்கும் போது இந்த புள்ளி மிகவும் முக்கியமானது. மேலே உள்ளவற்றின் அடிப்படையில், பெயர் அர்த்தத்தை வெளிப்படுத்த வேண்டும், எடுத்துக்காட்டாக, மாறி ஏன் உள்ளது, அது என்ன செய்கிறது மற்றும் எவ்வாறு பயன்படுத்தப்படுகிறது. ஒரு மாறிக்கான சிறந்த கருத்து அதற்கு நல்ல பெயரைக் கொடுப்பது என்பதை நான் ஒன்றுக்கு மேற்பட்ட முறை கவனிக்கிறேன்.

"ஷெர்லாக்" என்ற தொலைக்காட்சி தொடரிலிருந்து (2010-2017)

பெயரிடும் இடைமுகங்கள்

இடைமுகங்கள் பொதுவாக ஒரு பெரிய எழுத்தில் தொடங்கும் பெயர்களைக் கொண்டுள்ளன மற்றும் கேமல்கேஸில் எழுதப்படுகின்றன. ஒரு இடைமுகத்தை எழுதும் போது, ​​அதை ஒரு இடைமுகமாக (உதாரணமாக, IUserService) குறிப்பிட "I" முன்னொட்டைச் சேர்ப்பது நல்ல நடைமுறையாகக் கருதப்படுகிறது, ஆனால் அது மிகவும் அசிங்கமாகவும் கவனத்தை சிதறடிப்பதாகவும் தெரிகிறது. இதுபோன்ற சமயங்களில், முன்னொட்டை (UserService) தவிர்த்துவிட்டு, அதன் செயலாக்கத்தின் பெயருக்கு பின்னொட்டாக "Impl" ஐச் சேர்ப்பது நல்லது (எ.கா. UserServiceImpl). அல்லது கடைசி முயற்சியாக, செயல்படுத்தலின் பெயருடன் "C" முன்னொட்டைச் சேர்க்கவும் (எ.கா. CUserService).

வகுப்புகளின் பெயர்கள்

இடைமுகங்களைப் போலவே, வகுப்புப் பெயர்களும் பெரிய எழுத்துக்கள் மற்றும் கேமல்கேஸைப் பயன்படுத்துகின்றன. நாம் ஒரு ஜாம்பி பேரழிவை எதிர்கொண்டாலும் பரவாயில்லை, முடிவு நெருங்கிவிட்டாலும் பரவாயில்லை — ஒருபோதும், ஒருபோதும், ஒரு வகுப்பின் பெயர் வினைச்சொல்லாக இருக்கக்கூடாது! வகுப்பு மற்றும் பொருள் பெயர்கள் பெயர்ச்சொற்கள் அல்லது கூட்டு பெயர்ச்சொற்களாக இருக்க வேண்டும் (பயனர்கட்டுப்பாட்டு, பயனர் விவரங்கள், பயனர் கணக்கு மற்றும் பல). ஒவ்வொரு வகுப்பின் பெயரின் முடிவிலும் பயன்பாட்டின் சுருக்கத்தை நீங்கள் இணைக்கக்கூடாது, ஏனெனில் அது தேவையற்ற சிக்கலை மட்டுமே சேர்க்கும். எடுத்துக்காட்டாக, எங்களிடம் பயனர் தரவு இடம்பெயர்வு பயன்பாடு இருந்தால், ஒவ்வொரு வகுப்பிலும் "UDM" ஐச் சேர்க்க வேண்டாம், அதாவது UDMUserDetails, UDMUserAccount, UDMUserController.

முறை பெயர்கள்

வழக்கமாக, முறையின் பெயர்கள் ஒரு சிறிய எழுத்துடன் தொடங்குகின்றன, ஆனால் அவை ஒட்டக வழக்கு பாணியையும் (camelCase) பயன்படுத்துகின்றன. மேலே, வர்க்கப் பெயர்கள் ஒருபோதும் வினைச்சொற்களாக இருக்கக்கூடாது என்று சொன்னோம். இங்கே நிலைமை நேர்மாறானது: முறைகளின் பெயர்கள் வினைச்சொற்கள் அல்லது வினை சொற்றொடர்களாக இருக்க வேண்டும்: findUserById, findAllUsers, createUser மற்றும் பல. ஒரு முறையை உருவாக்கும் போது (அத்துடன் மாறிகள் மற்றும் வகுப்புகள்), எனவே குழப்பத்தைத் தவிர்க்க ஒரு நிலையான பெயரிடும் மரபுகளைப் பயன்படுத்தவும். எடுத்துக்காட்டாக, ஒரு பயனரைக் கண்டறிய, ஒரு முறைக்கு getUserById அல்லது findUserById என்று பெயரிடலாம். மேலும் ஒரு விஷயம்: முறைகளின் பெயர்களில் நகைச்சுவையைப் பயன்படுத்த வேண்டாம், ஏனென்றால் மற்றவர்கள் நகைச்சுவையைப் புரிந்து கொள்ள மாட்டார்கள். இதன் விளைவாக, அவர்கள் முறை என்ன செய்கிறது என்பதைப் புரிந்துகொள்ளத் தவறிவிடலாம்.

மாறி பெயர்கள்

பெரும்பாலான சந்தர்ப்பங்களில், மாறி பெயர்கள் ஒரு சிறிய எழுத்துடன் தொடங்குகின்றன, மேலும் இது ஒரு உலகளாவிய மாறிலியாக இருக்கும் போது தவிர, CamelCase ஐப் பயன்படுத்துகிறது. இதுபோன்ற சந்தர்ப்பங்களில், பெயரின் அனைத்து எழுத்துக்களும் பெரிய எழுத்தில் எழுதப்பட்டு, வார்த்தைகள் அடிக்கோடி ("_") மூலம் பிரிக்கப்படுகின்றன. வசதிக்காக, மாறிகளுக்கு பெயரிடும்போது அர்த்தமுள்ள சூழலைப் பயன்படுத்தலாம். வேறு வார்த்தைகளில் கூறுவதானால், ஒரு மாறி பெரிய ஒன்றின் பகுதியாக இருக்கும்போது, ​​எடுத்துக்காட்டாக, முதல் பெயர், கடைசி பெயர் அல்லது நிலை. இதுபோன்ற சந்தர்ப்பங்களில், இந்த மாறி எந்தப் பொருளைச் சேர்ந்தது என்பதைக் குறிக்கும் முன்னொட்டை நீங்கள் சேர்க்கலாம். எடுத்துக்காட்டாக: userFirstName, userLastName, userStatus. முற்றிலும் மாறுபட்ட அர்த்தங்களைக் கொண்டிருக்கும் போது, ​​மாறிகளுக்கு ஒத்த பெயர்களை நீங்கள் தவிர்க்க வேண்டும். மாறி பெயர்களில் பயன்படுத்தப்படும் சில அடிக்கடி எதிர்கொள்ளும் எதிர்ச்சொற்கள் இங்கே:

• ஆரம்பம்/முடிவு
• முதல்/கடைசி
• பூட்டப்பட்டது/திறக்கப்பட்டது
• குறைந்தபட்சம்/அதிகபட்சம்
• அடுத்தது/முந்தையது
• பழமை புதுமை
• திறக்கப்பட்டது/மூடப்பட்டது
• தெரியும்/கண்ணுக்கு தெரியாதது
• ஆதாரம்/இலக்கு
• ஆதாரம்/இலக்கு
• மேல் கீழ்

குறுகிய மாறி பெயர்கள்

எங்களிடம் x அல்லது n அல்லது அது போன்ற மாறிகள் இருக்கும்போது, ​​​​குறியீட்டை எழுதிய நபரின் நோக்கத்தை நாம் உடனடியாகப் பார்க்க மாட்டோம். n என்ன செய்கிறது என்பது தெளிவாகத் தெரியவில்லை. அதைக் கண்டுபிடிப்பதற்கு மிகவும் கவனமாக சிந்திக்க வேண்டும் (இதன் பொருள் நேரம், நேரம், நேரம்). எடுத்துக்காட்டாக, பொறுப்பான பயனரின் ஐடியைக் குறிக்கும் புலம் எங்களிடம் உள்ளது என்று வைத்துக்கொள்வோம். x அல்லது வெறுமனே ஐடி போன்ற சில மாறிப் பெயருக்குப் பதிலாக, இந்த மாறிக்கு "responsibleUserId" என்று பெயரிடுவோம், இது உடனடியாக வாசிப்புத்திறன் மற்றும் தகவல் உள்ளடக்கத்தை மேம்படுத்துகிறது. அதாவது, n போன்ற குறுகிய பெயர்கள் சிறிய முறைகளில் உள்ளூர் மாறிகளாக இடம் பெறுகின்றன, இந்த மாறியை உள்ளடக்கிய குறியீட்டின் தொகுதி இரண்டு கோடுகள் மட்டுமே உள்ளது, மேலும் முறையின் பெயர் அங்கு என்ன நடக்கிறது என்பதை சரியாக விவரிக்கிறது. அத்தகைய மாறியைப் பார்க்கும்போது, ​​ஒரு டெவலப்பர் இது இரண்டாம் நிலை முக்கியத்துவம் வாய்ந்தது மற்றும் மிகக் குறைந்த நோக்கத்தைக் கொண்டுள்ளது என்பதை புரிந்துகொள்கிறார். இதன் விளைவாக, நோக்கம் ஒரு மாறி பெயரின் நீளத்தின் மீது ஒரு குறிப்பிட்ட சார்பு உள்ளது: பெயர் நீளமானது, உலகளாவிய மாறி மற்றும் நேர்மாறாகவும். உதாரணமாக, கடைசியாக சேமித்த பயனரை தேதியின்படி கண்டறியும் முறை:

public User findLastUser() {
   return findAllUsers().stream()
           .sorted((x, y) -> -x.getCreatedDate().compareTo(y.getCreatedDate()))
           .findFirst()
           .orElseThrow(() -> new ResourceNotFoundException("No user exists"));
}

இங்கே நாம் ஸ்ட்ரீமை வரிசைப்படுத்த குறுகிய பெயரிடப்பட்ட மாறிகள் x மற்றும் y ஐப் பயன்படுத்துகிறோம், பின்னர் அவற்றை மறந்துவிடுகிறோம்.

உகந்த நீளம்

பெயரின் நீளம் என்ற தலைப்பில் தொடரலாம். உகந்த பெயர் நீளம் n மற்றும் அதிகபட்ச எண்கள்OfUsersInTheCurrentGroup க்கு இடையில் உள்ளது. வேறு வார்த்தைகளில் கூறுவதானால், குறுகிய பெயர்கள் அர்த்தமின்மையால் பாதிக்கப்படுகின்றன, அதே சமயம் மிக நீளமான பெயர்கள் படிக்கக்கூடிய தன்மையைச் சேர்க்காமல் நிரலை நீட்டிக்கின்றன, மேலும் ஒவ்வொரு முறையும் அவற்றை எழுதுவதற்கு நாங்கள் மிகவும் சோம்பேறியாக இருக்கிறோம். n போன்ற குறுகிய பெயரைக் கொண்ட மாறிகளுக்கு மேலே விவரிக்கப்பட்ட வழக்கைத் தவிர, நீங்கள் சுமார் 8-16 எழுத்துகள் நீளத்துடன் ஒட்டிக்கொள்ள வேண்டும். இது ஒரு கடுமையான விதி அல்ல, ஒரு வழிகாட்டுதல்.

சிறிய வேறுபாடுகள்

பெயர்களில் உள்ள நுட்பமான வேறுபாடுகளை நான் குறிப்பிடாமல் இருக்க முடியாது. இதுவும் ஒரு மோசமான நடைமுறையாகும், ஏனெனில் இந்த வேறுபாடுகள் வெறுமனே குழப்பத்தை ஏற்படுத்தலாம் அல்லது அவற்றைக் கவனிக்க அதிக நேரம் செலவிட வேண்டியிருக்கும். எடுத்துக்காட்டாக, InvalidDataAccessApiUsageException மற்றும் InvalidDataAccessResourceUsageException ஆகியவற்றுக்கு இடையேயான வித்தியாசத்தை ஒரு பார்வையில் கண்டறிவது கடினம். சிற்றெழுத்து L மற்றும் O ஐப் பயன்படுத்தும் போது அடிக்கடி குழப்பம் ஏற்படலாம், ஏனெனில் அவை 1 மற்றும் 0 என எளிதில் தவறாகப் புரிந்து கொள்ளப்படலாம். சில எழுத்துருக்களில் வேறுபாடு மிகவும் தெளிவாகவும், சிலவற்றில் குறைவாகவும் இருக்கும்.

பொருள்

நாம் பெயர்களை அர்த்தமுள்ளதாக்க வேண்டும், ஆனால் ஒத்த சொற்கள் மூலம் தெளிவின்மையை உருவாக்கக்கூடாது, எடுத்துக்காட்டாக, UserData மற்றும் UserInfo உண்மையில் ஒரே பொருளைக் கொண்டுள்ளன. இந்த வழக்கில், நமக்கு எந்த குறிப்பிட்ட பொருள் தேவை என்பதைப் புரிந்து கொள்ள குறியீட்டை ஆழமாக தோண்டி எடுக்க வேண்டும். பயனுள்ள தகவல்களைத் தெரிவிக்காத வார்த்தைகளைத் தவிர்க்கவும். எடுத்துக்காட்டாக, firstNameString இல், நமக்கு ஏன் சரம் என்ற சொல் தேவை? இது உண்மையில் தேதி பொருளாக இருக்க முடியுமா? நிச்சயமாக இல்லை. எனவே, நாம் வெறுமனே முதல் பெயரைப் பயன்படுத்துகிறோம். பூலியன் மாறிகளையும் குறிப்பிட விரும்புகிறேன். எடுத்துக்காட்டாக, கொடி நீக்கப்பட்டது என்ற பூலினை எடுத்துக் கொள்ளுங்கள். கொடி என்ற சொல்லுக்கு அர்த்தம் இல்லை. அதை நீக்கப்பட்டது என்று அழைப்பது மிகவும் நியாயமானது.

தவறான தகவல்

தவறான பெயரிடும் மரபுகளைப் பற்றியும் சில வார்த்தைகளைச் சொல்ல விரும்புகிறேன். எங்களிடம் பயனர் செயல்பாடு பட்டியல் என்ற மாறி உள்ளது என்று வைத்துக்கொள்வோம், ஆனால் இது ஒரு பட்டியலாக இருப்பதற்குப் பதிலாக, இது வேறு ஏதேனும் கொள்கலன் வகை அல்லது தனிப்பயன் சேமிப்பக பொருள். இது சராசரி புரோகிராமரைக் குழப்பலாம்: இதை userActivityGroup அல்லது userActivities என அழைப்பது நல்லது.

தேடு

குறுகிய மற்றும் எளிமையான பெயர்களில் உள்ள குறைபாடுகளில் ஒன்று, பெரிய அளவிலான குறியீட்டில் அவற்றைக் கண்டுபிடிப்பது கடினம் — எதைக் கண்டுபிடிப்பது எளிதாக இருக்கும்: "பெயர்" அல்லது "NAME_FOR_DEFAULT_USER"? இரண்டாவது விருப்பம், நிச்சயமாக. பெயர்களில் அடிக்கடி வரும் வார்த்தைகளை (எழுத்துக்களை) நாம் தவிர்க்க வேண்டும், ஏனெனில் அவை தேடலின் போது பொருந்தக்கூடிய கோப்புகளின் எண்ணிக்கையை மட்டுமே அதிகரிக்கும், இது நல்லதல்ல. புரோகிராமர்கள் குறியீட்டை எழுதுவதை விட அதிக நேரம் செலவழிக்கிறார்கள் என்பதை நான் உங்களுக்கு நினைவூட்ட விரும்புகிறேன், எனவே உங்கள் பயன்பாட்டின் கூறுகளை பெயரிடுவதில் கவனமாக இருங்கள். ஆனால் ஒரு நல்ல பெயரைக் கண்டுபிடிக்க முடியாவிட்டால் என்ன செய்வது? ஒரு முறையின் பெயர் அதன் செயல்பாட்டை நன்கு விவரிக்கவில்லை என்றால் என்ன செய்வது? இங்குதான் கருத்துக்கள் மேடையில் நுழைகின்றன.

கருத்துகள்

பொருத்தமான கருத்தை விட சிறந்தது எதுவுமில்லை, ஆனால் வெற்றிடமான, காலாவதியான அல்லது தவறான கருத்துகள் போன்ற தொகுதிகளை எதுவும் ஒழுங்கீனம் செய்யாது. அவர்கள் இரட்டை முனைகள் கொண்ட வாளாக இருக்கலாம், இல்லையா? இருப்பினும், நீங்கள் கருத்துகளை சந்தேகத்திற்கு இடமின்றி நல்லது என்று கருதக்கூடாது, மாறாக குறைவான தீமையாக கருத வேண்டும். எல்லாவற்றிற்கும் மேலாக, ஒரு கருத்து என்பது குறியீட்டில் தெளிவாக வராத சிந்தனைக்கு ஈடுசெய்யும் ஒரு வழியாகும். எடுத்துக்காட்டாக, ஒரு முறை மிகவும் குழப்பமானதாக இருந்தால், ஒரு முறையின் சாரத்தை எப்படியாவது தெரிவிக்க அவற்றைப் பயன்படுத்துகிறோம். இந்த சூழ்நிலையில், விளக்கக் குறிப்புகளை எழுதுவதை விட குறியீட்டை சரியாக மறுபரிசீலனை செய்வது நல்லது. பழைய கருத்து, மோசமான கருத்து, ஏனெனில் குறியீடு வளரும் மற்றும் உருவாகிறது, ஆனால் கருத்துகள் அப்படியே இருக்கலாம். ஒரு கருத்து உருவாக்கப்பட்டதிலிருந்து அதிக நேரம் கடந்துவிட்டதால், அது கேள்விக்குரியதாக இருக்கலாம். தவறான கருத்துக்கள், கருத்துகள் இல்லாததை விட மிகவும் மோசமானவை, ஏனென்றால் அவை குழப்பமானவை மற்றும் ஏமாற்றும், தவறான எதிர்பார்ப்புகளை அளிக்கின்றன. எங்களிடம் மிகவும் தந்திரமான குறியீடு இருந்தாலும், அதை கருத்து தெரிவிப்பதை விட அதை மீண்டும் எழுத வேண்டும்.

கருத்துகளின் வகைகள்

• சட்டக் கருத்துகள் — சட்ட காரணங்களுக்காக ஒவ்வொரு மூலக் கோப்பின் தொடக்கத்திலும் உள்ள கருத்துகள், எடுத்துக்காட்டாக:

  
  * Copyright (c) 2007, 2013, Oracle and/or its affiliates. All rights reserved.
  * ORACLE PROPRIETARY/CONFIDENTIAL. Use is subject to license terms.
  

• தகவலறிந்த கருத்துகள் - குறியீட்டின் விளக்கத்தைக் குறிக்கும் கருத்துகள் (கூடுதல் தகவலை வழங்குதல் அல்லது குறியீட்டின் கொடுக்கப்பட்ட பிரிவின் நோக்கத்தை விளக்குதல்).

  உதாரணத்திற்கு:

  
  /*
  * Combines the user from the database with the one passed for updating
  * When a field in requestUser is empty, it is filled with old data from foundUser
  */
  private User mergeUser(User requestUser, User foundUser) {
         return new User(
         foundUser.getId(),
         requestUser.getFirstName() == null ? requestUser.getFirstName() : foundUser.getFirstName(),
         requestUser.getMiddleName() == null ? requestUser.getMiddleName() : foundUser.getMiddleName(),
         requestUser.getLastName() == null ? requestUser.getLastName() : foundUser.getLastName(),
         requestUser.getAge() == null ? requestUser.getAge() : foundUser.getAge()
         );
         }
  

  இந்த விஷயத்தில், நீங்கள் கருத்துகள் இல்லாமல் செய்யலாம், ஏனெனில் முறையின் பெயர் மற்றும் அதன் அளவுருக்கள், மிகவும் வெளிப்படையான செயல்பாட்டுடன் இணைந்து, தங்களை நன்கு விவரிக்கின்றன.

• எச்சரிக்கை கருத்துகள் — ஒரு செயலின் விரும்பத்தகாத விளைவுகளைப் பற்றி மற்ற டெவலப்பர்களை எச்சரிக்கும் கருத்து (உதாரணமாக, ஒரு சோதனை ஏன் @புறக்கணிப்பு எனக் குறிக்கப்பட்டது என்பதைப் பற்றி எச்சரிக்கவும்):

  
  // Takes too long to run
  // Don't run if you don't have a lot of time
  @Ignore
  @Test
  public void someIntegrationTest() {
         ……
         }
  

• TODO - எதிர்காலத்தில் செய்ய வேண்டிய ஒன்றைப் பற்றிய குறிப்பு, ஆனால் சில காரணங்களால் இப்போது செய்ய முடியாது. இது ஒரு நல்ல நடைமுறைதான், ஆனால் இது போன்ற கருத்துக்கள் தொடர்பற்றவைகளை அகற்றவும் ஒழுங்கீனத்தைத் தவிர்க்கவும் தொடர்ந்து மதிப்பாய்வு செய்யப்பட வேண்டும்.

  ஒரு உதாரணம் இருக்கும்:

  
  // TODO: Add a check for the current user ID (when the security context is created)
  
  @Override
  public Resource downloadFile(File file) {
         return fileManager.download(file);
         }
  

  பதிவிறக்கச் செயல்பாட்டைச் செய்யும் பயனரின் (பாதுகாப்புச் சூழலில் இருந்து யாருடைய ஐடியைப் பிரித்தெடுப்போம்) சேவ் செயலைச் செய்தவருடன் ஒப்பிட்டுப் பார்க்க வேண்டும் என்பதை இங்கே கவனிக்கிறோம்.

• வலுவூட்டும் கருத்துகள் - முதல் பார்வையில் முக்கியமற்றதாகத் தோன்றும் சூழ்நிலையின் முக்கியத்துவத்தை வலியுறுத்தும் கருத்துகள்.

  உதாரணமாக, சில ஸ்கிரிப்ட்களுடன் சோதனை தரவுத்தளத்தை நிரப்பும் முறையின் ஒரு பகுதியைக் கவனியுங்கள்:

  
  Stream.of(IOUtils.resourceToString("/fill-scripts/" + x, StandardCharsets.UTF_8)
         .trim()
         .split(";"))
         .forEach(jdbcTemplate::update);
  // The trim() call is very important. It removes possible spaces at the end of the script
  // so that when we read and split into separate requests, we don't end up with empty ones
  

• Javadoc கருத்துகள் — குறிப்பிட்ட செயல்பாட்டிற்கான API ஐ விவரிக்கும் கருத்துகள். ஆவணப்படுத்தப்பட்ட API வேலை செய்வது மிகவும் எளிதானது என்பதால், மிகவும் பயனுள்ள கருத்துகள் இருக்கலாம். மற்ற வகை கருத்துகளைப் போலவே அவையும் காலாவதியானதாக இருக்கலாம். எனவே, ஆவணங்களுக்கான முக்கிய பங்களிப்பு கருத்துகளால் அல்ல, ஆனால் நல்ல குறியீட்டால் செய்யப்படுகிறது என்பதை மறந்துவிடாதீர்கள்.

  பயனரைப் புதுப்பிப்பதற்கான மிகவும் பொதுவான முறையின் எடுத்துக்காட்டு இங்கே:

  
  /**
  * Updates the passed fields for a user based on its id.
       *
  * @param id id of the user to be updated
  * @param user user with populated fields for updating
  * @return updated user
  */
         User update(Long id, User user);
  

மோசமான கருத்துக்கள்

• முணுமுணுப்பு கருத்து - பொதுவாக அவசரமாக எழுதப்படும் கருத்துகள் மற்றும் அதன் பொருள் அவற்றை எழுதிய டெவலப்பருக்கு மட்டுமே புரியும், ஏனெனில் அவர் மட்டுமே கருத்து குறிப்பிடும் நுணுக்கமான சூழ்நிலையை உணர்கிறார்.

  இந்த உதாரணத்தைக் கவனியுங்கள்:

  
  public void configureSomeSystem() {
         try{
         String configPath = filesLocation.concat("/").concat(CONFIGURATION_FILE);
         FileInputStream stream = new FileInputStream(configPath);
         } catch (FileNotFoundException e) {
         // If there is no configuration file, the default configuration is loaded 
        }
  }
  

  இந்த அமைப்புகளை ஏற்றுவது யார்? அவை ஏற்கனவே ஏற்றப்பட்டதா? இந்த முறை விதிவிலக்குகளைப் பிடித்து இயல்புநிலை அமைப்புகளை ஏற்ற வேண்டுமா? கணினியின் மற்ற பகுதிகளை ஆய்வு செய்வதன் மூலம் மட்டுமே பதிலளிக்கக்கூடிய பல கேள்விகள் எழுகின்றன.

• தேவையற்ற கருத்துகள் - குறியீட்டின் கொடுக்கப்பட்ட பிரிவில் என்ன நடக்கிறது என்பது தெளிவாக இருப்பதால், எந்த சொற்பொருள் சுமையையும் சுமக்காத கருத்துகள். வேறு வார்த்தைகளில் கூறுவதானால், குறியீட்டை விட கருத்து வாசிப்பது எளிதானது அல்ல.

  ஒரு உதாரணத்தைப் பார்ப்போம்:

  
  public class JdbcConnection{
  public class JdbcConnection{
     /**
      * The logger associated with the current class
      */
     private Logger log = Logger.getLogger(JdbcConnection.class.getName());
  
     /**
      * Creates and returns a connection using the input parameters
      */
     public static Connection buildConnection(String url, String login, String password, String driver) throws Exception {
         Class.forName(driver);
         connection = DriverManager.getConnection(url, login, password);
         log.info("Created connection with db");
         return connection;
     }
  

  இப்படிப்பட்ட கருத்துக்களால் என்ன பயன்? அவர்கள் விவரிக்கும் அனைத்தும் ஏற்கனவே தெளிவாக உள்ளன.

• நம்பகத்தன்மையற்ற கருத்துகள் - உண்மைக்குப் புறம்பான மற்றும் தவறாக வழிநடத்தும் கருத்துகள் (தவறான தகவல்). உதாரணமாக, இங்கே ஒன்று.

  
  /**
  * Helper method. Closes the connection with the scanner if isNotUsing is true
  */
  private void scanClose(Scanner scan, boolean isNotUsing) throws Exception {
     if (!isNotUsing) {
         throw new Exception("The scanner is still in use");
     } scan.close();
  }
  

  இந்தக் கருத்தில் என்ன தவறு? கருத்து நமக்குத் தெரிவிப்பது போல், isNotUsing தவறானது, மாறாக அல்ல, இணைப்பு மூடப்படும் என்பதில் இது நமக்குக் கொஞ்சம் பொய்யானது.

• கட்டாயக் கருத்துகள் — கட்டாயமாகக் கருதப்படும் கருத்துகள் (எ.கா. Javadoc கருத்துகள்), ஆனால் உண்மையில் சில நேரங்களில் அதிகமாக குவிந்து, நம்பகத்தன்மையற்றவை மற்றும் தேவையற்றவை (இந்த கருத்துகள் உண்மையில் தேவையா என்பதை நீங்கள் சிந்திக்க வேண்டும்).

உதாரணமாக:

/**
* Create a user based on the parameters
* @param firstName first name of the created user
* @param middleName middle name of the created user
* @param lastName last name of the created user
* @param age age of the created user
* @param address address of the created user
* @return user that was created
*/
User createNewUser(String firstName, String middleName, String lastName, String age, String address);

இந்த கருத்துகள் இல்லாமல் இந்த முறை என்ன செய்கிறது என்பதை நீங்கள் புரிந்து கொள்ள முடியுமா? பெரும்பாலும், ஆம், எனவே கருத்துகள் இங்கே அர்த்தமற்றவை.

• பதிவு கருத்துகள் - ஒவ்வொரு முறை திருத்தப்படும்போதும் தொகுதியின் தொடக்கத்தில் சில நேரங்களில் சேர்க்கப்படும் கருத்துகள் (மாற்றப் பதிவு போன்றது).

  
  /**
  * Records kept since January 9, 2020;
  **********************************************************************
  * 9 Jan 2020: Providing a database connection using JDBC Connection;
  * 15 Jan 2020: Adding DAO-level interfaces for working with the database;
  * 23 Jan 2020: Adding integration tests for the database;
  * 28 Jan 2020: Implementation of DAO-level interfaces;
  * 1 Feb 2020: Development of interfaces for services,
  * in accordance with the requirements specified in user stories;
  * 16 Feb 2020: Implementation of service interfaces
  * (implementation of business logic related to the work of the database);
  * 25 Feb 2020: Adding tests for services;
  * 8 Mar 2020: Celebration of International Women's Day (Terry is drunk again);
  * 21 Mar 2020: Refactoring the service layer;
  */
  

  இந்த அணுகுமுறை ஒருமுறை நியாயப்படுத்தப்பட்டது, ஆனால் பதிப்பு கட்டுப்பாட்டு அமைப்புகளின் வருகையுடன் (உதாரணமாக, Git), இது குறியீட்டின் தேவையற்ற ஒழுங்கீனம் மற்றும் சிக்கலாக மாறியது.

• ஆதர்ஷிப் கருத்துகள் — குறியீட்டை எழுதிய நபரைக் குறிப்பிடுவதே நோக்கமாக இருக்கும் கருத்துகள், எனவே நீங்கள் அவரை/அவளைத் தொடர்புகொண்டு எப்படி, என்ன, ஏன் என்று விவாதிக்கலாம், எ.கா:

  
  * @author Bender Bending
  

  மீண்டும், பதிப்புக் கட்டுப்பாட்டு அமைப்புகள் யார் எந்தக் குறியீட்டை எப்போது சேர்த்தது என்பதை சரியாக நினைவில் கொள்கிறது, எனவே இந்த அணுகுமுறை தேவையற்றது.

• கருத்து தெரிவிக்கப்பட்ட குறியீடு - ஒரு காரணத்திற்காக அல்லது மற்றொரு காரணத்திற்காக கருத்து தெரிவிக்கப்பட்ட குறியீடு. இது மோசமான பழக்கங்களில் ஒன்றாகும், ஏனென்றால் நீங்கள் எதையாவது கருத்து தெரிவித்து அதை மறந்துவிடுவீர்கள், பின்னர் மற்ற டெவலப்பர்களுக்கு அதை நீக்க தைரியம் இல்லை (எல்லாவற்றிற்கும் மேலாக, அது மதிப்புமிக்கதாக இருந்தால் என்ன செய்வது?).

  
  //    public void someMethod(SomeObject obj) {
  //    .....
  //    }
  

  இதன் விளைவாக, கருத்து வெளியிடப்பட்ட குறியீடு குப்பை போல் குவிகிறது. எந்தவொரு சந்தர்ப்பத்திலும் நீங்கள் அத்தகைய குறியீட்டை விட்டுவிடக்கூடாது. உங்களுக்கு உண்மையிலேயே தேவைப்பட்டால், பதிப்பு கட்டுப்பாட்டு அமைப்பு பற்றி மறந்துவிடாதீர்கள்.

• வெளிப்படையான கருத்துக்கள் - அதிகப்படியான சிக்கலான முறையில் எதையாவது விவரிக்கும் கருத்துகள்.

  
  /*
      * Start with an array large enough to store
      * all the data bytes (plus filter bytes) with a cushion, plus 300 bytes
      * for header data
      */
  this.dataBytes = new byte[(this.size * (this.deep + 1) * 2)+300];
  

  ஒரு கருத்து குறியீட்டை விளக்க வேண்டும். அதற்கு விளக்கம் தேவையில்லை. எனவே இங்கே என்ன தவறு? "வடிகட்டி பைட்டுகள்" என்றால் என்ன? அந்த "+ 1" எதைப் பற்றியது? ஏன் சரியாக 300?

நீங்கள் ஏற்கனவே கருத்துகளை எழுத முடிவு செய்திருந்தால், இங்கே சில குறிப்புகள் உள்ளன:

1. பராமரிக்க எளிதான பாணிகளைப் பயன்படுத்தவும்: மிகவும் ஆடம்பரமான மற்றும் கவர்ச்சியான பாணிகளைப் பராமரிப்பது எரிச்சலூட்டும் மற்றும் நேரத்தை எடுத்துக்கொள்ளும்.
2. ஒற்றை வரிகளைக் குறிக்கும் வரியின் இறுதிக் கருத்துகளைப் பயன்படுத்த வேண்டாம்: இதன் விளைவாக கருத்துகளின் பெரிய குவியலாகும். மேலும் என்னவென்றால், ஒவ்வொரு வரிக்கும் ஒரு அர்த்தமுள்ள கருத்தை சிந்திப்பது கடினம்.
3. நீங்கள் ஒரு கருத்தை எழுதும் போது, ​​"ஏன்" என்ற கேள்விக்கு பதிலளிக்க முயற்சிக்கவும், "எப்படி" அல்ல.
4. சுருக்கப்பட்ட தகவல்களைத் தவிர்க்கவும். நான் மேலே சொன்னது போல், கருத்துக்கு விளக்கம் தேவையில்லை: கருத்து தானே விளக்கம்.
5. அலகுகள் மற்றும் மதிப்பு வரம்புகளைக் குறித்துக் கொள்ள நீங்கள் கருத்துகளைப் பயன்படுத்தலாம்.
6. அவர்கள் விவரிக்கும் குறியீட்டிற்கு அருகில் கருத்துகளை வைக்கவும்.

இறுதியாக, சிறந்த கருத்து எந்தக் கருத்தும் இல்லை என்பதை உங்களுக்கு நினைவூட்ட விரும்புகிறேன், மாறாக உங்கள் விண்ணப்பம் முழுவதும் திறமையான பெயரிடலைப் பயன்படுத்துவது. ஒரு விதியாக, பெரும்பாலான நேரங்களில் நாங்கள் ஏற்கனவே உள்ள குறியீட்டுடன் வேலை செய்வோம், அதை பராமரித்து நீட்டிக்கிறோம். மோசமான குறியீடு ஒரு தடையாக இருப்பதால், இந்த குறியீடு படிக்க எளிதாகவும் புரிந்துகொள்ளக்கூடியதாகவும் இருக்கும்போது இது மிகவும் வசதியானது. இது வேலைகளில் ஒரு குறடு எறிவது போன்றது, மேலும் அவசரம் அதன் உண்மையுள்ள துணை. எங்களிடம் எவ்வளவு மோசமான குறியீடு இருக்கிறதோ, அவ்வளவு செயல்திறன் குறைகிறது. இதன் பொருள் நாம் அவ்வப்போது மறுபரிசீலனை செய்ய வேண்டும். ஆனால் தொடக்கத்திலிருந்தே அடுத்த டெவலப்பர்கள் உங்களைக் கண்டுபிடித்து கொல்ல விரும்பாத குறியீட்டை எழுத முயற்சித்தால், நீங்கள் அதை அடிக்கடி மறுபரிசீலனை செய்ய வேண்டியதில்லை. புதிய சார்புகள் மற்றும் இணைப்புகளைச் சேர்ப்பதன் மூலம் தயாரிப்பின் நிபந்தனைகள் மற்றும் தேவைகள் தொடர்ந்து மாறுவதால், அது இன்னும் அவசியமாக இருக்கும். சரி, இன்று எனக்கு அவ்வளவுதான் என்று நினைக்கிறேன். இதுவரை படித்த அனைவருக்கும் நன்றி :)