குறியீட்டு நடை வழிகாட்டி

இந்த வழிகாட்டியானது BeeWare Docs Tools-க்கான குறியீட்டை எழுதுவதற்கான தகவல்களையும் வழிகாட்டுதல்களையும் உள்ளடக்கியுள்ளது.

குறியீட்டு நடை

BeeWare எங்கள் குறியீட்டுத் தொகுப்பில் PEP 8-ஐப் பின்பற்றுகிறது, ஆனால் வரி நீளம் 79 எழுத்துக்களிலிருந்து 88 எழுத்துக்களாக விரிவுபடுத்தப்பட்டுள்ளது. சாத்தியமான இடங்களில் PEP 8 மரபுகளை அமல்படுத்த நாங்கள் Ruff-ஐப் பயன்படுத்துகிறோம். உங்கள் குறியீட்டை நீங்கள் கமிட் செய்யும்போது, ப்ரீ-கமிட் Ruff உட்பட சில சோதனைகளை நடத்தும். முடிந்தவரை, இது உங்கள் குறியீட்டை எங்கள் வடிவமைப்பு மற்றும் பாணித் தரநிலைகளுக்கு ஏற்றவாறு தானாகவே வடிவமைக்கும். சில IDE-களைச் சேமிக்கும்போதே Ruff-ஐத் தானாகவே இயக்க நீங்கள் அமைக்கலாம், இது இந்தச் செயல்முறைக்கு உதவும்.

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

இதன் ஒரு வெளிப்பாட்டை பெயரிடும் மரபுகளில் காணலாம். BeeWare நூலகங்கள் அடிக்கடி மற்ற மொழிகளுடன் இணைக்கப்பட வேண்டும். மற்ற மொழிகளுக்கான ராப்பர்களை உருவாக்கும்போது, பைத்தானின் பெயரிடும் மரபுகளைப் பின்பற்றுவதை விட, இலக்கு மொழியின் பெயரிடும் மரபுகளைப் பின்பற்றுவது விரும்பத்தக்கது (சில சமயங்களில், அவசியமானது). உதாரணமாக, ஜாவா குறியீட்டை அழைக்கும்போது அல்லது குறிப்பிடும்போது, PEP 8-இன் mixedCase விருப்பத்தைப் பின்பற்றுவதை விட, ஜாவாவின் snake_case விருப்பத்தைப் பின்பற்ற வேண்டும்.

API பெயரிடுதல், மாறிகள் போன்றவற்றிற்கு நாங்கள் அமெரிக்க எழுத்துப்பிழை விதிகளைப் பின்பற்றுகிறோம்.

PEP 8-இல் BeeWare-க்குரிய சில கூடுதல் மாற்றங்களும் உள்ளன:

PEP 484-ஐப் பின்பற்றும் வகைக் குறிப்பு விருப்பத்தேர்வாக இருந்தாலும், குறிப்பாக எந்தவொரு பொது API பரப்புகளிலும் அது வலுவாகப் பரிந்துரைக்கப்படுகிறது.

சரியான டைப் ஹிண்ட்கள் மற்றும் ஒரு ஸ்பிங்க்ஸ் டாಕ್ஸ்ட்ரிங் உடன் கூடிய ஒரு ஸ்டாண்டர்ட் ஃபங்ஷன் வரையறையின் உதாரணம் கீழே காட்டப்பட்டுள்ளது:

def function_name(param1: int, param2: str) -> bool:
"""வகைகள் மற்றும் ஒரு docstring உடன் கூடிய எடுத்துக்காட்டுச் செயல்பாடு.

:param param1: முதல் பராமீட்டர்.
:param param2: இரண்டாவது பராமீட்டர்.

:returns: திரும்பப்பெறும் மதிப்பு. வெற்றி பெற்றால் True, மற்றபடி False.
"""

நீண்ட செயல்பாட்டு அழைப்புகளைப் பிரித்தல்

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

my_function(
    arg1, arg2, arg3
)

இந்த பாணியைப் பயன்படுத்தக் கூடாது. அதற்கு பதிலாக, கடைசி வாதத்தில் ஒரு பின்புற கோமா (trailing comma) சேர்த்து, ஒவ்வொரு வாதத்தையும் ஒரு வரியில் பிரிக்கவும்:

my_function(
    arg1,
    arg2,
    arg3,
)

நீண்ட சரங்களைப் பிரிப்பது

ஒரு சர வாதம் (string argument) வரி நீளத் தேவைகளைப் பூர்த்தி செய்ய வரிகளில் பிரிக்கப்பட வேண்டியிருக்கும்போது, அந்தச் சரங்கள் ஒற்றை வாதம் என்பதைத் தெளிவுபடுத்த, இணைக்கப்பட்ட சர மாறிகளைக் (concatenated string literals) கோட்டைக்குறிக்குள் (parentheses) வைக்கவும். அதாவது, நாங்கள் இதை விரும்புகிறோம்:

my_function(
    (
 "இது மிகவும் நீண்ட சரமாகும்"
 "இது இரண்டு வரிகளுக்குப் பிரிக்கப்பட்டுள்ளது"
    ),
    second_argument,
)

மேலே:

my_function(
    "இது இரண்டு வரிகளுக்குப் பிரிக்கப்பட்ட ஒரு மிக நீண்ட சரமாகும்",
    second_argument,
)

தவிர்க்க வேண்டியவை

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

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

கருத்துகளை எழுதும் போது, "we" போன்ற முதலாம் ஆண்பால் பலவாசகப் பெயர்ச்சொற்களைப் பயன்படுத்துவதைத் தவிர்க்கவும் (உதாரணமாக, "We loop over" என்பதற்குப் பதிலாக "Loop over" என எழுதவும்).

சோதனை டாக்குஸ்ட்ரிங்குகளில், ஒவ்வொரு சோதனையும் வெளிப்படுத்தும் எதிர்பார்க்கப்படும் நடத்தையைக் குறிப்பிடவும். "Tests that" அல்லது "Ensures that" போன்ற முன்னுரைகளைச் சேர்க்க வேண்டாம்.

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

def test_foo():
 """ஒரு சோதனை டாக்குஸ்ட்ரிங் இதுபோல இருக்கும் (#123456)."""