मुझे एहसास है कि यह कुछ व्यक्तिपरक है, लेकिन मुझे एक या दूसरे के लिए एक अच्छा मामला नहीं मिल सकता है:
यह "कुछ करना चाहिए"
यह "कुछ करता है"
शैली के समर्थकों ने उल्लेख किया है कि यह आपको वास्तव में सवाल करने के लिए मजबूर करता है कि आप क्या हासिल करने की कोशिश कर रहे हैं, जबकि अवरोधकों को यह केवल निरर्थक लगता है।
क्या इस पर आम सहमति है या यह विशुद्ध रूप से शैली का विषय है?
जवाबों:
कानूनी अंग्रेजी में आपका स्वागत है।
"चाहिए" == "करेगा" == संविदात्मक दायित्व का उपयोग करना। यह एक वैधानिकता है। यह "पूछताछ" करने के लिए नेतृत्व नहीं करता है। यह एक औपचारिक संविदात्मक दायित्व के रूप में वाक्य को चिह्नित करता है।
"Will" == "will" == अच्छा विचार का उपयोग करना। यह एक वैकल्पिक सुविधा के रूप में वाक्य को चिह्नित करता है।
पूछताछ सुविधा, संगठन, मदद, विश्वास निर्माण का हिस्सा है। शब्द की पसंद का विवेक नहीं।
संशोधक के बिना एक नंगे क्रिया का उपयोग करना औपचारिक आवश्यकता के रूप में वाक्य को थोड़ा कठिन बनाता है। और सुपर-कॉम्प्लेक्स क्रियाओं के मामले में, यह पता लगाने के लिए थोड़ा सा पासा हो सकता है कि इसे कैसे संयुग्मित किया जाए।
आसान - क्रियाओं जैसे "सूचित करना" या "बनाने के लिए"।
सिस्टम ईमेल के माध्यम से सूचित करता है। (क्रिया "सूचित करने के लिए" संयुग्मित है "सिस्टम" के लिए "सूचित करता है" - जो भी है।)
प्रणाली ईमेल के माध्यम से सूचित करेगी। ("सूचित करने के लिए" बन जाता है "सूचित करेगा" - संयुग्मन नहीं। बहुत सरल।)
हार्ड - क्रिया वाक्यांश जैसे "लॉग इन" या डोमेन-विशिष्ट क्रिया वाक्यांश जैसे "निकालने, शुद्ध करने, बदलने, कटौती करने और लोड करने के लिए" या "संभावना" जैसी एक संज्ञा जिसे क्रिया कहा गया है। अब जो वाक्यांश कई क्रियाओं में दफन है, उसे संयुग्मित करना कठिन है: प्रत्येक क्रिया को संयुग्मित करें? या लंबे वाक्यांश को समझने की कोशिश करें जैसे कि यह एक शब्द था? चूंकि किसी भी संज्ञा को अंग्रेजी में क्रिया कहा जा सकता है, इसलिए यह जानना मुश्किल है कि उन बनी हुई क्रियाओं को कैसे जोड़ा जाए।
जब उपयोगकर्ता क्लिक करता है, तो सिस्टम एक्सट्रैक्ट, क्लीन, ट्रांसफॉर्म, डिडुप्लिकेट और लोड। (अंग्रेजी तुच्छ रूप से किसी भी संज्ञा वाक्यांश की क्रिया करता है।) या यह अर्क, सफाई, परिवर्तन, डुप्लिकेट और लोड है?
जब उपयोगकर्ता क्लिक करता है, तो सिस्टम को अर्क, शुद्ध करना, बदलना, डुप्लिकेट और लोड करना चाहिए। (छिपा हुआ वाक्यांश बरकरार है, क्रिया संयुग्मन के बारे में कोई रहस्य नहीं है।)
["क्या?" आप कहते हैं, "किसी भी संज्ञा को अंग्रेजी में क्रिया कहा जा सकता है?"। हाँ। कोई भी संज्ञा। मैं उस पर पत्थर मारने जा रहा हूं। मैंने अक्सर उस पर पत्थरबाजी की है। यहां तक कि विनिर्देशों को उस पर पत्थर लगाना चाहिए।]
विशुद्ध रूप से शैलीगत पसंद की बात है। यह पूछने के लिए उबलता है, क्या आप / आपके ग्राहक वर्तमान या भविष्य के तनाव के बारे में सोचना पसंद करते हैं?
क्वालिफायर्स जैसे "चाहिए" या "विल" का मतलब भविष्य के तनाव से है, लेकिन यह नरम है और वर्तमान काल में सोचने पर काफी अच्छी तरह से पढ़ता है। एक क्वालीफायर का अभाव निश्चित रूप से वर्तमान काल (यानी इस क्षण सही) को इंगित करता है।
मैं एक क्वालीफायर का उपयोग करना पसंद करता हूं क्योंकि यह दोनों मामलों में निष्क्रिय रूप से अच्छी तरह से पढ़ता है, जबकि क्वालिफायर की कमी विकास के दौरान थोड़ा अजीब तरीके से पढ़ती है जब सब कुछ भविष्य में तनावपूर्ण होता है।
किसी भी मामले में, यदि आप एक क्वालिफायर का उपयोग करने का निर्णय लेते हैं, तो मैं दृढ़ता से "चाहिए" के बजाय "चाहिए" का उपयोग करने की सलाह देता हूं । "क्या मुझे वैकल्पिक होने के रूप में व्याख्या की जा सकती है (इसके विपरीत एस.लॉट के दावे के बावजूद), लेकिन किसी भी अस्पष्टता को पूरी तरह से हटा दिया जाना चाहिए" - का स्पष्ट रूप से मतलब "वैकल्पिक नहीं" होना चाहिए।
और क्योंकि मैं अभी तक टिप्पणी नहीं कर सकता (कर्म की कमी), यह एस / कॉट के बारे में एक प्रतिक्रिया होनी चाहिए। स्पष्टीकरण के लिए यह लेख देखें ।
मैं तीसरे व्यक्ति का उपयोग करने के पक्ष में हूं , बिना क्वालीफायर के वर्तमान काल ।
मेरा मुख्य तर्क यह है कि: एक परीक्षा एक कहानी है।
एक कहानी में दृश्य होते हैं। प्रत्येक दृश्य का वर्णन करता है:
उदाहरण:
DESCRIBE :
getReceiptफ़ंक्शनसंपर्क : रसीद मौजूद है
आईटी : रसीद लौटाता है
एक अच्छी कहानी की तरह, एक अच्छी परीक्षा को पढ़ना आसान है।
एक कहानी आपको बताती है कि कार्यक्रम क्या करता है, जैसे
दूसरी ओर, एक क्वालीफायर का उपयोग करके (इससे कोई फर्क नहीं पड़ता कि यह "चाहिए" या "होना चाहिए") परीक्षण को दावे की सूची में बदल देता है, उदाहरण के लिए:
कोई निरंतर कहानी नहीं है: आपका दिमाग जोर की सूची का मूल्यांकन कर रहा है।
यह व्यक्तिपरक है, लेकिन प्राकृतिक भाषा (एक कहानी) पढ़ना जोर की सूची पढ़ने की तुलना में सरल है।
मेरी राय में, आपको हमेशा 'चाहिए' का इस्तेमाल करना चाहिए।
रीजनिंग - बीडीडी के साथ, जब आप टेस्ट लिख रहे होते हैं, तो सॉफ्टवेयर अभी तक वह नहीं करता है जो आप करना चाहते हैं, इसलिए यह कहना कि "कुछ करता है" झूठा है। यह "कुछ करना चाहिए", और परीक्षण तब तक पास होंगे जब तक कि यह कुछ करना जारी रखता है।
से behaviour-driven.org शीर्षक "GettingTheWordsRight" :
संक्षेप में, जिन शब्दों का हम चीजों का वर्णन करने के लिए उपयोग करते हैं, वे उन चीजों को प्रभावित करते हैं जिनमें हम (और अन्य) उन चीजों के बारे में सोचते हैं। यह सिर्फ शब्दार्थ के बारे में क्षुद्र होने का एक सरल प्रश्न नहीं है, क्योंकि कुछ शब्द उनके साथ बारीकियों को ले जाते हैं जो प्रभावित करते हैं कि हम एक बौद्धिक और भावनात्मक स्तर पर वाक्यांश के अर्थ की व्याख्या कैसे करते हैं। हमारी भाषा वर्णनात्मक शब्दों और वाक्यांशों से समृद्ध है इसलिए ऐसे शब्दों का उपयोग करना उचित लगता है जो उन तत्वों के इरादे को स्पष्ट रूप से बताएंगे जिन्हें हम कोड में वर्णन करना चाहते हैं।
बीडीडी के मामले में, मैं व्यक्तिगत रूप से हूं जो परीक्षणों का नामकरण करते समय लगभग हमेशा शब्द का उपयोग करना चाहिए , क्योंकि इसका उपयोग यह बताता है कि जबकि एक निश्चित परिणाम प्रदान करने के लिए परीक्षण का इरादा है, अन्य अप्रत्याशित परिणाम उत्पन्न हो सकते हैं, जिससे निपटा जाना चाहिए यदि परीक्षा परिणाम वैध माना जाता है। आप शायद उन शब्दों का उपयोग कर सकते हैं जो अपेक्षित या आवश्यक हैंइसी तरह, हालांकि ये शब्द एक अधिक जरूरी दृष्टिकोण हैं, जैसे कि परीक्षण के नाम का अर्थ गलत हो सकता है "परीक्षण में कुछ भी गलत नहीं है, मान लें कि कार्यान्वयन गड़बड़ है", जबकि * का अर्थ है कि परीक्षण की संभावना है सही हो, फिर भी त्रुटि के लिए फिर से जाँच करने की आवश्यकता हो सकती है यदि परीक्षण के परिणाम नहीं जोड़ते हैं। मुझे यह पसंद है, क्योंकि यह आपकी सोच को प्रभावित करता है जैसे कि आप खुले दिमाग को अपने कोड के रूप में रखने के लिए प्रोत्साहित होते हैं, जो बहुत ही है जब आप अपने कोड को डीबग करने का प्रयास करते हैं और एक धारणा के कारण त्रुटियों के लिए खुद को गलत स्थान पर देखने की कोशिश करते हैं तो आप अटकने से बचना चाहते हैं।
हालाँकि, मैंने देखा है कि शब्द के 'धार्मिक' अनुप्रयोग को विफल होना चाहिए, जब इसे परीक्षण नामों के लिए उपसर्ग के रूप में लागू किया गया है, क्योंकि इसने प्रोग्रामर को एक परीक्षण नाम प्रदान करने के लिए कुछ मानसिक और भाषाई जिम्नास्टिक से गुजरने के लिए मजबूर किया है। सार्थक था, और ऐसे मामलों में इसका मतलब है कि शब्दों को सही पाने की मंशा इसकी अपेक्षाओं को पूरा नहीं करती है, और परीक्षणों के परिणामस्वरूप स्वयं को समझना मुश्किल हो जाता है। स्थिति इस तरह की अप फसलों, मैं आमतौर पर शब्द का प्रयोग करेंगे चाहिएपरीक्षण विधि के नाम के भीतर किसी भी स्थान पर, यह सुनिश्चित करने के लिए कि नाम अपनी पद्धति को सरल और स्पष्ट रूप से बताता है। मैं निश्चित रूप से एक विशेष शब्द के उपयोग को लागू नहीं करूंगा, अगर अन्य शब्द दिए गए संदर्भ में समान रूप से उपयुक्त हैं। ट्रिक हालांकि उन शब्दों को चुनने के लिए है जो कोड में किसी चीज़ का प्रतिनिधित्व करने वाले तर्क के लिए कोई जगह नहीं छोड़ते हैं, और यह आपको उन चीजों के बारे में सोचने के लिए उकसाता है जो आपके कोड को केवल निहितार्थ पर भरोसा किए बिना करना है।