यदि मेरी टीम में कम कौशल है, तो क्या मुझे अपने कोड के कौशल को कम करना चाहिए? [बन्द है]

Question

उदाहरण के लिए, डिफ़ॉल्ट मान प्राप्त करने के लिए JS में एक सामान्य स्निपेट है:

function f(x) {
    x = x || 'default_value';
}

इस तरह के स्निपेट को मेरी टीम के सभी सदस्यों द्वारा आसानी से नहीं समझा जा सकता है, उनका जेएस स्तर कम है।

क्या मुझे इस चाल का उपयोग नहीं करना चाहिए? यह साथियों द्वारा कोड को कम पठनीय बनाता है, लेकिन किसी भी जेएस देव के अनुसार निम्न से अधिक पठनीय है:

function f(x) {
    if (!x) {
        x = 'default_value';
    }
}

निश्चित रूप से, अगर मैं इस ट्रिक का उपयोग करता हूं और एक सहयोगी इसे देखता है, तो वे कुछ सीख सकते हैं। लेकिन मामला अक्सर यह होता है कि वे इसे "चालाक बनने की कोशिश" के रूप में देखते हैं।

तो, क्या मुझे अपने कोड का स्तर कम करना चाहिए, अगर मेरे साथियों का स्तर मुझसे कम है?

Comments

मेरा मानना ​​है कि "क्या आपको मुहावरेदार कोड लिखना चाहिए और लोगों को उस स्तर पर मजबूर करना चाहिए? या गैर-मुहावरेदार कोड लिखना चाहिए जो सब कुछ स्पष्ट रूप से बताए?"

अपने कोड के कौशल स्तर को कम मत करो! मैंने अधिक उन्नत प्रोग्रामर्स के कोड को पढ़ने से बहुत कुछ सीखा। एक ऐसी संस्कृति बनाएं जहां, यदि आपके साथी कुछ समझ नहीं पाते हैं, तो उन्हें पूछने (और सीखने) के लिए प्रोत्साहित किया जाता है। बस सुनिश्चित करें कि आप सुसंगत हैं।

— कोस्टा कोंटोस

क्या आपके पास कोड समीक्षाएं हैं? यह उनके लिए कोड के बारे में सवाल पूछने के लिए एक उत्कृष्ट स्थान होगा।

— thegrinner

कोडिंग कौशल का एक हिस्सा स्पष्टता है, जो आपके "दर्शकों" को ध्यान में रखता है। यह विशेष मुहावरा शिक्षण के लायक लगता है, लेकिन निश्चित रूप से ऐसे मामले होंगे जहां यह अधिक पारदर्शी कोडिंग शैली का उपयोग करने के लिए अधिक समझ में आएगा।

— लार्स

क्या इसका मतलब सिर्फ यह है कि कौन सोचता है कि दूसरा उदाहरण बेहतर गुणवत्ता का है और इसके बाद पहला उदाहरण क्रिस्टल क्लियर है? दूसरे उदाहरण की तरह लगता है कि अधिक पठनीय है, तो लघु हाथ वाला संस्करण जो पहला निर्वासन है। क्या ऐसे उपकरण नहीं हैं जो स्वचालित रूप से मानव निर्मित कोड को जावास्क्रिप्ट के लिए अनुकूलित करेंगे? मेरे जावास्क्रिप्ट अनुभव के आधार पर वास्तव में जो कोड चलाया जाता है वह सुंदर होना ही नहीं है, जितना संभव हो उतना प्रभावी होना चाहिए।

— रामहाउंड

Answer 1

ठीक है, यहाँ इस बड़े और जटिल विषय पर मेरा ध्यान जाता है।

---

अपनी कोडिंग शैली रखने के लिए नियम:

• x = x || 10जावास्क्रिप्ट विकास में चीजें मुहावरेदार हैं और आपके कोड और आपके द्वारा उपयोग किए जाने वाले बाहरी संसाधनों के कोड के बीच संगतता का एक रूप प्रदान करती हैं।
• उच्च स्तर का कोड अक्सर अधिक अभिव्यंजक होता है, आप जानते हैं कि आपको क्या मिलता है और उच्च प्रशिक्षित पेशेवरों में पढ़ना आसान है।
• आप अपनी नौकरी का अधिक आनंद लेंगे। मैं व्यक्तिगत रूप से सुंदर कोड बना रहा हूं। मुझे लगता है कि इससे मुझे अपने काम में बहुत संतुष्टि मिलती है।
• आम तौर पर यह अधिक पठनीय शैली बनाता है। भाषा के मुहावरों के साथ चिपकना बहुत मूल्यवान हो सकता है - वे अक्सर एक कारण के लिए मुहावरे होते हैं।

अपना कोडिंग स्टाइल रखने के लिए विपक्ष:

• निचले स्तर के प्रोग्रामर को बनाए रखना कठिन होगा। ये अक्सर आपके कोड को बनाए रखने वाले लोग होते हैं और जिन लोगों को आपके द्वारा लिखे गए सामान को पढ़ना होता है।
• कोड के अनुरक्षक, अक्सर जावास्क्रिप्ट कोड अन्य भाषाओं से आते हैं। आपके प्रोग्रामर जावा या C # में सक्षम हो सकते हैं, लेकिन यह नहीं समझ सकते कि जावास्क्रिप्ट कब और कैसे भिन्न होता है। ये बिंदु अक्सर मुहावरेदार होते हैं - एक तुरंत लागू फ़ंक्शन अभिव्यक्ति (IIFE) इस तरह के निर्माण का एक उदाहरण है।

---

मेरी निजी राय

आपको अपने कोड के कौशल को कम नहीं करना चाहिए। आपको ऐसा कोड लिखने की इच्छा होनी चाहिए जो स्पष्ट, स्पष्ट और संक्षिप्त हो। यदि आपको अपनी टीम के स्तर के बारे में कोई संदेह है - तो उन्हें शिक्षित करें । लोग जितना आप सोच सकते हैं उससे अधिक सीखने के लिए तैयार हैं, और आश्वस्त होने पर नए निर्माणों को अनुकूलित करने के लिए तैयार हैं।

अगर उन्हें लगता है कि आप 'सिर्फ चालाक हैं,' अपनी बात पर बहस करने की कोशिश करें। यह मानने के लिए तैयार रहें कि आप कभी-कभी गलत हैं, और कोई बात नहीं, शैलियों को अपने काम के माहौल में लगातार बनाए रखने की कोशिश करें। ऐसा करने से शत्रुता से बचने में मदद मिलेगी।

सबसे महत्वपूर्ण बात लगातार बने रहना है।

एक टीम के कोड को लिखा जाना चाहिए जैसे कि एक व्यक्ति ने इसे कोडित किया था। आपको कोडिंग दिशानिर्देशों पर पूरी तरह से सहमत होना होगा। आपको उन दिशानिर्देशों का पालन करना चाहिए। यदि कोडिंग दिशानिर्देश निर्दिष्ट करते हैं कि वैकल्पिक मापदंडों को पढ़ना 'कम चतुर' तरीके से किया जाना चाहिए, तो वह तरीका है।

Comments

मुझे पता है कि सीखना एक निरंतर बात है, लेकिन क्या वास्तव में इस विकासकर्ता का काम अपने साथी कर्मचारियों को प्रशिक्षित करना है? उनके लिए सबसे उपयुक्त प्रशिक्षण खोजना वास्तव में प्रबंधन का काम होना चाहिए।

— corsiKa

@corsiKa उन डेवलपर्स को "सशुल्क प्रशिक्षण" (यानी प्रशिक्षण प्रबंधन कर्मचारियों को भेजना होगा) के माध्यम से किसी भाषा की सभी आयतों को जानने की संभावना नहीं है। मैं इसे एक रोगग्रस्त कार्यस्थल मानता हूं जब सहकर्मी एक दूसरे से नहीं सीखते हैं। ऐसा नहीं है कि ओपी को उन्हें कक्षा प्रशिक्षण देना होगा। जब वे अटके हों, तो लोग केवल सवाल पूछ सकते हैं, और जैसा कि ऊपर टिप्पणी में बताया गया है, उस तरह के ज्ञान को साझा करने के लिए कोड समीक्षा अच्छी हो सकती है।

— मेटलमेस्टर

ओपी (और अन्य) द्वारा निर्धारित उदाहरणों से उनके साथी कर्मचारियों को अपने दम पर सीखना चाहिए। अन्यथा, वे अपने वर्तमान ज्ञान से आगे नहीं बढ़ेंगे। ओपी को उन्हें व्यक्तिगत रूप से प्रशिक्षित करने के लिए हर दिन घंटों बाहर रहना चाहिए, लेकिन कोड की समीक्षा और एक सामयिक ब्राउन-बैग सत्र हर किसी की मदद कर सकता है (ठीक है, हर कोई जो सीखना चाहता है, वह है)।

— alroc

@ कोरसीका ने सहमति व्यक्त की कि वरिष्ठ देव संहिता की समीक्षा अपने आप में पर्याप्त प्रशिक्षण नहीं है, हालांकि यह उन चीजों की पहचान करने का एक अच्छा तरीका हो सकता है जिन्हें जूनियर देव को बाद में देखना चाहिए।

— डैन लियोन

@ जिम काफी, एक वैध दृष्टिकोण है। मैंने कभी यह तर्क नहीं दिया कि पठनीयता राजा है। मुझे कई भाषाओं का उपयोग करने पर सख्त आपत्ति है जैसे कि वे एक ही भाषा थी। सैकड़ों घंटे की डिबगिंग में एक आपत्ति 'अर्जित' की। जबकि मैं इस बात से पूरी तरह सहमत हूं कि पठनीयता राजा है, मेरा मानना ​​है कि आप इसी तरह कई भाषाओं में कोड का इलाज नहीं कर सकते। इसके अलावा, मुझे लगता है कि अधिकांश 'खराब प्रतिष्ठा' जावास्क्रिप्ट के कारण ठीक है। लोगों को उम्मीद है कि यह कुछ-अन्य-भाषा की तरह व्यवहार करेगा लेकिन ऐसा नहीं है। मैं मानता हूं कि पठनीयता मिशन महत्वपूर्ण है। बेहतर कोड हमेशा अधिक पठनीय होता है :)

— बेंजामिन ग्रुएनबाम

Answer 2

अच्छी तरह से टिप्पणी करें

क्या आपको अपने कोड का कौशल कम करना चाहिए? जरूरी नहीं, लेकिन आपको अपनी टिप्पणियों का कौशल निश्चित रूप से उठाना चाहिए । अपने कोड में अच्छी टिप्पणियों को शामिल करना सुनिश्चित करें, खासकर उन वर्गों के आसपास जो आपको लगता है कि अधिक जटिल हो सकते हैं। इतनी सारी टिप्पणियों का उपयोग न करें कि कोड का पालन करना कठिन हो जाता है, लेकिन प्रत्येक अनुभाग के उद्देश्य को स्पष्ट करना सुनिश्चित करें।

वास्तविकता यह है कि टिप्पणियों के साथ थोड़ा और अधिक क्रियाशील होना कम कुशल टीम के सदस्यों के साथ उपयोगी हो सकता है, लेकिन सबसे कम कौशल वाले लोग उन्हें अनदेखा करते हैं, खासकर यदि बहुत अधिक है, तो इसे ज़्यादा मत करो।

शैली की बात?

आपके द्वारा दिया गया उदाहरण कुछ बुनियादी है, बल्कि शैलीगत भी है। हर चर डिफ़ॉल्ट के आसपास एक टिप्पणी बनाए रखने और पढ़ने के लिए बहुत थकाऊ होगा। इसके बजाय, शैलीगत या दोहराया शॉर्टकट या कोड पैटर्न शायद एक मानक के रूप में स्थापित होने चाहिए। यदि आपको लगता है कि पैरामीटर डिफॉल्ट का ऐसा रूप सभी को समझना चाहिए और हर बार उपयोग किया जाना चाहिए, तो इन विचारों को लिख लें और उन्हें अपनी टीम की अगुवाई में ले जाएं। यह संभव है कि आपके साथियों को पढ़ाने के लिए यह सब एक सरल बैठक होगी जहां आप प्रस्तावित मानकों पर चर्चा करते हैं।

जैसा कि एक अन्य उत्तर में पहले ही कहा गया है, इसे लगातार रखें ।

सिखाओ एक आदमी को मछली ...

अपने साथियों को पढ़ाना शायद सबसे अच्छा तरीका है जिससे आप सभी को शामिल कर सकते हैं। यह स्पष्ट करें कि यदि किसी के पास कमिट लॉग या टाइमस्टैम्प में आपके नाम के साथ कोड के एक टुकड़े पर कोई प्रश्न है, तो उन्हें इसके बारे में पूछने के लिए स्वतंत्र महसूस करना चाहिए। यदि आपकी टीम में कोड समीक्षाएं हैं, तो यह आपके टीम के साथियों के लिए किसी भी संभावित भ्रामक (अहम) टिप्पणी करने का एक शानदार अवसर है । यदि आपकी टीम में कोड समीक्षाएं नहीं हैं, तो क्यों नहीं? यह करने के लिए!

हालांकि आपको सावधान रहने की जरूरत है। आप लोगों को पढ़ाने के लिए हमेशा आस-पास नहीं हो सकते हैं और आप यह भी भूल सकते हैं कि मूल रूप से आप किसी दिए गए अनुभाग में क्या करने की कोशिश कर रहे थे।

"चतुर" ट्रिक्स

अपने टीम के साथियों की क्षमताओं को ध्यान में रखना निश्चित रूप से महत्वपूर्ण है, लेकिन बनाए रखने योग्य कोड को लिखने का मतलब अक्सर उन समस्याओं के आर्कन शॉर्टकट्स का उपयोग नहीं करना है जिनके अधिक सामान्य समाधान हो सकते हैं। यह तब भी महत्वपूर्ण है जब आपके टीम के साथी बुद्धिमान हों। आप कोड को समझने में या सूक्ष्म लेकिन महत्वपूर्ण साइड इफेक्ट्स को याद करने के लिए बहुत लंबा समय नहीं लेना चाहते हैं। सामान्य तौर पर, उपयुक्त विकल्प होने पर "चतुर" चाल से बचने के लिए सबसे अच्छा है। आपको कभी नहीं पता होगा कि लाइन के नीचे कोड को बनाए रखने के लिए कौन हो सकता है - अक्सर खुद के पुराने संस्करणों को इन ट्रिक्स के विवरण या कारण याद नहीं होंगे।

यदि आप पाते हैं कि आपको एक चतुर चाल को लागू करना चाहिए, तो कम से कम सलाह के बाद आगे बढ़ें ...

चुम्मा

जब संदेह हो, तो इसे सरल रखें । कोड सरल है या नहीं, जरूरी नहीं कि प्रोग्रामर स्किल के अनुरूप हो, जैसा आप सोच सकते हैं। वास्तव में एक समस्या के सबसे शानदार समाधान सबसे सरल हैं, और कुछ अधिक जटिल समाधान TheDailyWFF पर समाप्त होते हैं । अपने कोड को सरल और संक्षिप्त रखने से कुछ अधिक समझदार लेकिन संभवतः सहज ज्ञान युक्त निर्णय लेने में आसानी हो सकती है।

Comments

मुद्दा यह है कि भाषा की विशेषताओं को "चतुर चाल" के रूप में देखा जाता है, तब भी जब मुझे लगता है कि वे स्पष्ट रूप से नहीं हैं। कभी किसी बंद को देखा है? कभी एक IIFE देखा है? कभी एक फ़ंक्शन संदर्भ कॉलबैक के रूप में देखा गया है? वे भाषा की विशेषताएं हैं जो हर अनुभवी जेएस देव जानता है। फिर भी वे कम अनुभवी जेएस देवों के लिए "चतुर चाल" हैं।

— फ्लोरियन मार्गाइन

@FlorianMargaine मुझे लगता है कि आपको शब्दावली बदलने पर काम करने की आवश्यकता है, अर्थात: ये "चतुर चाल" नहीं हैं, ये भाषा की अधिक उन्नत विशेषताएं हैं ... 1 तात्पर्य है कि आपका कोड आसानी से समझ में नहीं आता / बुरी बात है, 2 का अर्थ है 'मेरे' कोडिंग कौशल को सीखने और सुधारने का एक अवसर (कैसे दूसरों को अपनी शब्दावली बदलने के लिए? टिप्पणियाँ, प्रश्नों को प्रोत्साहित करें, कोड लेखों की व्याख्या करें कि ये विशेषताएं कैसे उपयोगी हैं, आदि ...)

— एंड्रयू बिकर्टन

यदि यह आपके किसी भी सिरदर्द को कम करता है, तो निराशा का एक हिस्सा भाषा के रूप में जावास्क्रिप्ट हो सकता है ... इसका कोई मतलब नहीं है। यह अमेरिका, यहां पोस्ट करने वाले लोगों के लिए समझ में आता है, क्योंकि हमने इसे लंबे समय से किया है। लेकिन कोई फर्क नहीं पड़ता कि हमने भाषा को "अच्छी तरह से" काम करने के लिए बनाया है, तटस्थ आंखों के लिए यह सिर्फ समझ में नहीं आता है। अन्य नोट में; आप दुख की बात है, अनुभवी देवों को काम पर रखने के मूल्य का प्रदर्शन कर सकते हैं, या अधिमानतः, नए प्रतिमानों को सीखने के लिए उच्च इच्छा के साथ 'किसी भी भाषा' डेवलपर्स।

— कटान ३१४

@FlorianMargaine मैं मुख्य रूप से जावास्क्रिप्ट में भी काम करता हूं, मुझे पता है कि आप जो दर्द महसूस कर रहे हैं। मैंने टीम के साथियों को शिक्षित करने की कोशिश करके यह संपर्क किया है। क्रॉकफोर्ड जावास्क्रिप्ट वीडियो ( 1 , 2 ) मदद करते हैं। मुझे नहीं लगता कि जिन चीजों को आपने सूचीबद्ध किया है, वे "चतुर" ट्रिक्स के तहत आती हैं- आपके टीम के साथियों को उन्हें सीखना चाहिए- लेकिन उन चीजों में से कुछ जो आप उन भाषा सुविधाओं के साथ करते हैं, वे "चतुर" का सबसे खराब प्रकार हो सकती हैं। अनुभवी देवों को नियुक्त करने के लिए आपकी कंपनी को कैसे विश्वास दिलाया जाए, यह पूरी तरह से एक और सवाल है ...

— Corion

टिप्पणियाँ हमेशा अच्छी नहीं होती हैं। मैंने कुछ समय पहले "क्लीन कोड" पढ़ा और उन्होंने टिप्पणी के बारे में कुछ बिंदुओं को उत्कृष्ट बताया। यदि आप अपने कोड को समझाने के लिए टिप्पणी लिखने की आवश्यकता महसूस करते हैं, तो एक अच्छा मौका है कि कोड बुरी तरह से लिखा गया है। यदि कोड अधिक अभिव्यंजक था, तो एक टिप्पणी अतिश्योक्तिपूर्ण है। हर बार जब आप एक टिप्पणी लिखने वाले होते हैं, तो एक पल के लिए विचार करें कि क्या रिफैक्टरिंग एक बेहतर विकल्प हो सकता है। यदि कोड अभिव्यंजक है, तो इसका उद्देश्य स्पष्ट करना अनावश्यक हो जाता है। इसके अलावा, यदि कोड बदला जाता है तो टिप्पणियाँ भ्रामक या बस गलत हो सकती हैं लेकिन टिप्पणियों को मिलान के लिए अद्यतन नहीं किया जाता है।

— पप्पा

Answer 3

जेएस में एक समारोह बनाने के लिए एक बड़ा विरोध प्रतीत होता है। इस उकसावे के कारण लोग चालाक बनने की कोशिश करते हैं और हास्यास्पद चाल का इस्तेमाल करते हैं ताकि सामान को एक पंक्ति में रखा जा सके जैसे कि फ़ंक्शन कॉल होता। बेशक एक कॉल में फ़ंक्शन नाम अतिरिक्त प्रलेखन के रूप में भी कार्य करता है। हम एक टिप्पणी को एक व्यंजक अभिव्यक्ति के साथ संलग्न नहीं कर सकते क्योंकि तब यह करने के बिंदु को हरा देगा इसलिए हम इसे "js मुहावरा" कहते हैं और अचानक यह समझ में आता है।

जावास्क्रिप्ट बेहद सुलभ है, ज्यादातर लोग नाश्ते के लिए विशिष्टताओं को नहीं खाते हैं जैसे हम करते हैं। इसलिए वे कभी नहीं समझ पाएंगे कि मुहावरे की छिपी हुई धारणाएं और धार के मामले क्या हैं।

x = x || 'default_value';

औसत जो या तो यह समझ नहीं पाएगा या यह याद रखेगा कि यह डिफ़ॉल्ट मान के लिए मुहावरा है। दोनों हानिकारक हैं, वास्तव में उत्तरार्द्ध और भी अधिक हानिकारक है। वह यहाँ मान्यताओं और धार के मामलों को नहीं समझेगा। वह विनिर्देश को पढ़ने और इसे कभी समझने की परवाह नहीं करेगा।

जब मैं उस कोड को देखो मैं देख रहा हूँ "अगर यह nullया undefined, तो यह डिफ़ॉल्ट मान पर सेट करें। हालांकि यह भी परोक्ष व्यवहार करेगा +0, -0, NaN, false, और ""के रूप में उपयुक्त नहीं मान। मुझे याद है करना होगा कि 3 महीने अब से जब कि जरूरतों बदलने के लिए। मैं शायद इसे भूल जाऊंगा। "

निहित धारणा भविष्य में एक बग पैदा होने की संभावना है और जब आपका कोडबेस इस तरह से चाल से भरा होता है तो कोई मौका नहीं है कि आप उन सभी को अपने सिर में रख रहे हैं जब भी आप सोच रहे हैं कि संशोधन क्या प्रभावित करेगा। और यह "JS pro" के लिए है, औसत joe ने बग लिखा होगा भले ही आवश्यकताओं को शुरू करने के लिए एक मिथ्या मूल्य को स्वीकार करना था।

आपके नए स्निपेट में अधिक परिचित वाक्यविन्यास हैं लेकिन फिर भी उपरोक्त समस्या है।

आप इसके साथ जा सकते हैं:

function f(x) {
    x = valueOrDefault(x, "default_value");
}

अब आपके पास किनारे के मामलों को संभालने के लिए बहुत जटिल तर्क हो सकते हैं और क्लाइंट कोड अभी भी सुंदर और पठनीय दिखता है।

---

अब, आप कैसे उन्नत भाषा सुविधा के बीच अंतर करते हैं जैसे एक फ़ंक्शन को तर्क के रूप में पास करना या जैसे एक चतुर चाल || "default"?

चालाक चाल हमेशा कुछ छिपी हुई मान्यताओं के तहत काम कर रहे हैं जिन्हें अनदेखा किया जा सकता है जब कोड शुरू में बनाया गया था। मुझे एक IIFE को कभी और नहीं बदलना होगा क्योंकि एक आवश्यकता बदल गई, यह हमेशा रहेगी। शायद 2020 में जब मैं वास्तविक मॉड्यूल का उपयोग कर सकता हूं, लेकिन हाँ।

| 0या ~~numफर्श के लिए उपयोग किए जाने वाले कार्गो पंथ संस्करण सकारात्मक और 32-बिट हस्ताक्षरित पूर्णांक सीमा मानता है।

|| "default" सभी मिथ्या मानों को समान माना जाता है जैसे कि किसी तर्क को पारित नहीं करना।

और इसी तरह।

Comments

आप एक उदाहरण पर ध्यान केंद्रित कर रहे हैं। IIFE, क्लोजर, फ़ंक्शन संदर्भ जैसे सामान का उपयोग करने के बारे में क्या? यह मेरे प्रश्न का मुख्य बिंदु है।

— फ्लोरियन मार्गाइन

@FlorianMargaine आपको नहीं लगता कि मैंने दूसरे भाग में पर्याप्त रूप से संबोधित किया है?

— एस्लेइजा जूल

खैर, यह इस बारे में कुछ नहीं कहता है कि मैं उस स्थिति को कैसे संभाल सकता हूं जहां मैं "उन्नत भाषा सुविधा" का उपयोग करता हूं, जो टीम के साथी "चतुर" के रूप में गलत समझते हैं।

— फ्लोरियन मार्गाइन

मुझे यह उत्तर पसंद है +1, मुझे लगता है कि यह सवाल का एक बड़ा हिस्सा याद करता है, लेकिन यह गहराई से इसके बारे में अन्य भागों और परिदृश्यों के बारे में बात करता है और अन्य टीम डेवलपर्स में समस्याओं को समझाता है, जो आपके बिना पढ़े बिना मार्गदर्शन के अपने दम पर ऐसी अवधारणाओं को उठाते हैं। कोड।

— बेंजामिन ग्रुएनबाउम

@FlorianMargaine का मतलब है कि आप वास्तव में अपने कार्यस्थल पर अभ्यास की स्थिति को कैसे संभाल सकते हैं जहां आप IIFE का उपयोग कर रहे हैं और कोई सोचता है कि यह एक चतुर चाल है? जैसे मैंने समझाया, चूंकि कोई छिपी हुई धारणा नहीं है, "वैरिएबल ग्लोबल नहीं होगा" जैसा एक संस्मरण औसत के लिए ठीक काम करेगा।

— एस्लेइज़ा

Answer 4

आपको अपने प्रोग्रामिंग कौशल को कम नहीं करना चाहिए , लेकिन आपको कोड लिखने के तरीके को समायोजित करने की आवश्यकता हो सकती है । लक्ष्य, लगभग सभी से ऊपर, अपने कोड को उन लोगों को स्पष्ट करना है जिन्हें इसे पढ़ना और बनाए रखना होगा।

दुर्भाग्य से यह एक निर्णय कॉल का एक सा हो सकता है कि क्या कोई विशेष शैली "चतुर" या सिर्फ उन्नत उपयोग है। प्रश्न में कोड इसका एक अच्छा उदाहरण है - आपका समाधान आवश्यक रूप से दूसरे से बेहतर नहीं है। कुछ यह तर्क देंगे, कुछ असहमत होंगे। चूंकि दोनों समाधानों में प्रभावी रूप से समान रनटाइम प्रदर्शन होता है (पढ़ें: उपयोगकर्ता को कभी भी अंतर नहीं पता होगा), इस शैली को चुनें कि टीम एक पूरे के रूप में सबसे अधिक आरामदायक है।

कुछ उदाहरणों में आपको उन्हें कोड करने के बेहतर तरीके सिखाने की आवश्यकता होती है, लेकिन अन्य समय में आपको स्पष्टता के हित में समझौता करने की आवश्यकता होती है।

Comments

+1। न तो विशिष्ट उदाहरण जो ओपी ने दिया है वह दूसरे की तुलना में बेहतर है, वे केवल अलग हैं।

— रॉस पैटरसन ने

बहुत अच्छा जवाब @ ब्रायन-ओक्ले। चीयर्स

— एंडी के

Answer 5

यह पहले से ही एक अन्य उत्तर में कहा जा सकता है, लेकिन मैं इस प्रश्न का उत्तर अपने स्वयं के आदेश देना चाहूंगा।

सामान्य दिशानिर्देश

जब आप किसी टीम पर काम करते हैं, तो आप एक कोड के टुकड़े के लक्षित दर्शक नहीं होते हैं। आपके दर्शक आपकी टीम के डेवलपर्स हैं। वे अच्छे कारण के बिना कोड नहीं लिख सकते।

1. जब तक कोई विशिष्ट नकारात्मक पक्ष नहीं होता है, तब तक सभी कोड एक विशिष्ट पैटर्न या दिशानिर्देश के बाद लिखे जाने चाहिए जो डेवलपर्स द्वारा आसान रखरखाव की अनुमति देगा जो इसे बनाए रखेंगे। (एक चेतावनी: खराब पैटर्न का पालन सिर्फ इसलिए कि वे वर्तमान में कोड बेस में हैं भयानक अभ्यास है।)
2. यदि आप किसी भाषा विशेष के मुहावरे का उपयोग करने का एक अच्छा कारण पा सकते हैं जो लक्ष्य दर्शकों द्वारा आसानी से पढ़ने योग्य नहीं है, तो एक टिप्पणी जोड़ें। यदि आप पाते हैं कि आपको हर दूसरी पंक्ति में एक टिप्पणी जोड़ने की आवश्यकता है, तो आप अपने दर्शकों द्वारा अधिक पठनीय होने के लिए अपने कोड को फिर से लिखना चाह सकते हैं। मैं मुहावरेदार होने के लिए मुहावरेदार होना मूल्यवान नहीं समझता।

विशिष्ट उदाहरण

हमारे कोड बेस में बड़ी संख्या में पर्ल स्क्रिप्ट हैं। हम आम तौर पर केवल बहुत ही सरल ऑपरेशन के लिए पर्ल का उपयोग करते हैं और कोड के विशाल बहुमत को जावा डेवलपर्स द्वारा लिखा जाता है, इसलिए इसे जावा की तरह स्टाइल किया जाता है। हमारे पास पर्ल स्क्रिप्ट्स का एक सेट है और एक फ्रेमवर्क जो एक 'पर्ल गुरु' द्वारा लिखा गया था, जिसने तब से हमारी फर्म को छोड़ दिया है। इस कोड में कई अस्पष्ट पर्ल मुहावरे हैं और हमारे डेवलपर्स में से कोई भी, स्वयं सहित, इस पर्ल कोड को विस्तारित प्रयास से नहीं पढ़ सकता है। हम अक्सर इसके लिए उसे शाप देते हैं। :)

Answer 6

यदि आप अच्छा कोड लिखते हैं, लेकिन आपको लगता है कि आपके वर्तमान या भविष्य के सहयोगियों को इसका अनुसरण करने में कठिनाई हो सकती है, तो आपको इसे समझाने के लिए एक संक्षिप्त टिप्पणी जोड़ना चाहिए।

इस तरह, आप उनकी व्यक्तिगत बुद्धिमत्ता का अपमान किए बिना या समूह चर्चा में किसी को भी शर्मिंदा किए बिना उन्हें कुछ सिखा सकते हैं।

Answer 7

मैं आपके उदाहरण को एक चाल नहीं कहूंगा, लेकिन सिर्फ मुहावरेदार हूं। यदि आपको इसका उपयोग करना चाहिए, तो यह निर्भर करता है कि IMHO आपकी टीम के वर्तमान स्तर पर बहुत अधिक नहीं है, लेकिन यदि (कम से कम कुछ) आपकी टीम के साथी कुछ नए मुहावरों को सीखने के लिए तैयार हैं। बेशक, आपको उनके साथ इस विषय पर चर्चा करनी चाहिए और उन पर इस शैली को लागू नहीं करना चाहिए। और आपको उन्हें हर दिन 5 नई चीजें या "ट्रिक्स" सीखने के लिए नहीं कहना चाहिए। लेकिन ईमानदारी से, अगर आपके पास केवल टीम के साथी कुछ नया सीखने के लिए तैयार नहीं हैं, तो भी यह इस मुहावरे से बहुत सरल और छोटा है, आपको एक अलग टीम में बदलने पर विचार करना चाहिए।

Answer 8

इस सवाल और उसके बाद के जवाबों और चर्चाओं को पढ़कर लगता है कि यह दो बिंदु हैं। पहला: क्या उन्नत भाषा सुविधाओं का उपयोग करना ठीक है? दूसरा: मैं ऐसा कैसे प्रकट कर सकता हूं जैसे कि मैं 'दिखावा' कर रहा हूं?

पहले मामले में, यह सुधार और उन्नत सुविधाओं का उपयोग करने के लिए समझ में आता है। उदाहरण के लिए: C # में आपको Linq या Lambda अभिव्यक्तियों का उपयोग करने की आवश्यकता नहीं है, लेकिन ज्यादातर लोग ऐसा इसलिए करते हैं क्योंकि यह कोड को स्पष्ट और समझने में आसान बनाता है, एक बार जब आप वास्तव में जानते हैं कि यह क्या कर रहा है। पहले तो यह सिर्फ अजीब लग रहा है।

लोग पैटर्न के लिए अभ्यस्त हो जाते हैं और कई मामलों में लोग काम करने के लिए बस काम करने के निर्धारित तरीके का उपयोग करते हैं। मैं इसके लिए अगले आदमी के रूप में दोषी हूं। हम सबकी डेडलाइन होती है। कुछ मामलों में आप नए विचारों और सोच के नए तरीकों को पेश करने के लिए दोषी हैं! यह दूसरे बिंदु पर आता है और संभवतः यही वह जगह है जहां आप सबसे अधिक प्रतिरोध का सामना कर रहे हैं।

वेबसाइट का उपयोग करने वाले व्यक्ति के लिए वे परवाह नहीं करते हैं कि वे किस शैली का उपयोग करते हैं इसकी परवाह है क्या यह काम करता है? क्या यह जल्दी है? इसलिए, यदि आपके रास्ते में कोई प्रदर्शन लाभ नहीं है, तो आपके द्वारा दिए गए उदाहरण में कोई सही तरीका या गलत तरीका नहीं है। क्या आपका तरीका कोड को अधिक पठनीय बनाता है या नहीं? एक बार आपके सहकर्मियों को इसका उपयोग करने के बाद यह हो सकता है।

तो, आप इन परिवर्तनों को कैसे पेश करते हैं? कोशिश करें और अपने सहयोगियों के साथ इन पंक्तियों पर चर्चा करें: क्या आप जानते हैं कि इस फ़ंक्शन को इस तरह लिखा जा सकता है? विचारों की 'क्रॉस-परागण' की अनुमति देने के लिए कोड समीक्षा और जोड़ी प्रोग्रामिंग अच्छा समय हो सकता है। मेरे लिए यह कहना मुश्किल है कि मैं क्या करूं क्योंकि मुझे नहीं पता कि आप जिस वातावरण में काम कर रहे हैं, मैं नहीं जानता कि मुझे लगता है कि कुछ प्रोग्रामर बहुत रक्षात्मक और परिवर्तन के लिए प्रतिरोधी हो सकते हैं। फिर से मैं इसके लिए दोषी हूं। इस प्रकार के प्रोग्रामर के साथ काम करने का सबसे अच्छा तरीका यह है कि कुछ समय बिताने के लिए यह सीखने में कि उन्हें क्या करना है, उनकी पृष्ठभूमि सीखें और फिर उनकी शैलियों और अनुभवों की तुलना करें और उनकी तुलना करें। इसमें समय लगता है लेकिन यह समय अच्छी तरह से व्यतीत होता है। यदि संभव हो तो कोशिश करें और उन्हें प्रोत्साहित करें।

Comments

यदि आपको लगता है कि आपके लिए C # वातावरण में जो कुछ भी है, उसकी जांच करना आपके लिए आसान होगा, तो मुझे संदेह है कि ओपी बुरा नहीं मानेगा - मुझे यकीन नहीं है। यह सवाल जावास्क्रिप्ट के बारे में नहीं है :) अपने कोड में वैकल्पिक पैरामीटर, या लैम्ब्डा देने की कल्पना करें क्योंकि अन्य टीम डेवलपर्स इसे नहीं समझते हैं - क्या आप ऐसा करेंगे? मुझे लगता है कि आप यहां कुछ दिलचस्प विचार उठाते हैं, लेकिन अगर आप उस विशिष्ट भाषा के बारे में चिंता करना बंद कर देते हैं जो आप इसे और अधिक आकर्षक तरीके से लिख सकते हैं :)

— बेंजामिन ग्रुएनबाम

मैं मुख्य रूप से C # के साथ काम करता हूं इसलिए यह वह उदाहरण था जो दिमाग में सबसे आसानी से उछला। आप एक उत्कृष्ट बिंदु बनाते हैं, इस संबंध में कि क्या मैं उपयोगी भाषा सुविधाओं को सिर्फ इसलिए छोड़ दूंगा क्योंकि दूसरों को उनके बारे में पता नहीं है। इसका जवाब नहीं होगा, लेकिन निश्चित रूप से मुश्किल बिट दूसरों को इस नए तरीके के फायदे देखने के लिए मिल रहा है, जो फ्लोरियन की मुख्य समस्या लगती है।

— डैनियल हॉलिन्रेके

Answer 9

बस रॉयल McBee कंप्यूटर कॉर्प के लिए काम नहीं जाना है, क्योंकि जो कहना है कि आप अनुभवहीन प्रोग्रामर नहीं हैं।

निश्चित रूप से, यह लिखने के लिए बढ़िया है कि यह बहुत संक्षिप्त और संक्षिप्त है और यह एक जावास्क्रिप्ट वातावरण में उपयोगी हो सकता है (अच्छी तरह से, जब तक कि कोई व्यक्ति ब्राउज़रों को डाउनलोड करने के लिए एक जेएस कंपाइलर का उत्पादन नहीं करता है, लेकिन यह एक और कहानी है)।

हालाँकि, जो महत्वपूर्ण है, वह आपके कोड को लाइव करने के लिए आपके द्वारा लिए गए कुछ मिनटों के लिए रहने की क्षमता है। निश्चित रूप से, इसका त्वरित और आसान है और आप इसे बाहर निकाल सकते हैं और आगे बढ़ सकते हैं, लेकिन अगर आपको इसे सालों बाद वापस आना है, तो आप सोच सकते हैं कि "किस muppet ने यह लिखा है", और यह महसूस करें कि यह आप ही थे! (मैंने ऐसा किया है, निश्चित रूप से ज्यादातर लोगों के पास भी है .. मैं अत्यधिक आक्रामक समय सीमा, ईमानदार को दोष देता हूं)।

यह ध्यान में रखने वाली एकमात्र महत्वपूर्ण बात है, इसलिए जब मैं हाँ कहूँगा - उस विशेष ऑपरेटर के साथ चलें यदि यह काम करता है और स्पष्ट है, और आपके 'अनुभवहीन' देव (हालांकि, उनके लिए अपमानजनक है, तो मुझे बहुत पता है अनुभवहीन देव जो सभी ऑपरेटरों और ट्रिक्स को जानते हैं क्योंकि उन्होंने विभिन्न वेब पेज ट्यूटोरियल और संदर्भों को याद किया है, वे सबसे खराब कोड लिखते हैं, भले ही वे हर छोटी चाल जानते हों ... संयोग से अधिक हो सकता है)

वैसे भी, यदि आप मेल की कहानी पढ़ सकते हैं, तो आपको एहसास होगा कि किसी भी कोड में ट्रिक्स सबसे अच्छी बात नहीं है, भले ही मेल पहले क्रम का एक वास्तविक प्रोग्रामर था। यह किसी भी तर्क के लिए भुगतान किया जाता है जहां कोई कहता है कि वे अच्छे कोड लिख सकते हैं और बाकी सभी को बनाए रखने के लिए और अधिक सीखने की जरूरत है।

Comments

मैं एक भी प्रोग्रामर को नहीं जानता, जो अपने कोड पर वापस नहीं गया (एक महीने पहले से!) और चला गया "किसने यह लिखा है"। हम हमेशा शैली में विकसित होते हैं (कम से कम हम कोशिश करते हैं)। इस विशिष्ट मामले में ओपी मानक कोड लिख रहा है, न कि डब्ल्यूटीफ़िश कोड। ओपी "चतुर" कोड या "शांत होने के लिए छोटा" कोड लिखने पर चर्चा नहीं कर रहा है, यह मुहावरेदार जेएस है।

— बेंजामिन ग्रुएनबाम

Answer 10

खैर, शुरुआत के लिए जो मुझे बुनियादी जेएस की तरह दिखता है।

लेकिन सामान्य तौर पर - आपको चतुर हैक्स का उपयोग नहीं करना चाहिए, paraphrase के लिए "डिबगिंग प्रोग्रामिंग की तुलना में दोगुना कठिन है। यदि आप कोड को जितना हो सके उतना चालाक लिखते हैं, तो आप इसे डीबग करने में असमर्थ हैं।"

इसका मतलब यह नहीं है कि आपको कोड से बचना चाहिए क्योंकि अन्य लोग इसे नहीं समझेंगे - आपको कोड को स्पष्ट और सुसंगत तरीके से लिखना चाहिए। लेकिन आपके लिए स्पष्ट मानदंड होना चाहिए "क्या मैं इसे एक वर्ष में पहली बार पढ़ने पर समझूंगा", "क्या कोई इसे समझ नहीं सकता है"।

स्पष्ट तरीके से लिखें, कि आपको समझने में कोई कठिनाई नहीं है और दूसरों को अपने कौशल को बढ़ाने पर काम करने दें - दूसरों को कुछ काल्पनिक परेशानी से बचाने के लिए खुद को बाधा न दें।

Answer 11

मैं अपने टीम के साथियों के साथ चर्चा करूँगा कि हम किस तरह के कोडिंग मानकों को रखना चाहते हैं क्योंकि यह अधिकतर इस बारे में है कि दर्जनों तरीकों से किया जा सकता है कि हमारे कोड आधार के लिए कैसे किया जाए। यदि कोई सहमति है तो एक उत्तर में मेरा प्रारंभिक प्रयास होगा।

अगर वहाँ नहीं है, तो मैं संभवतः इस बात पर विचार करूँगा कि प्रस्तावित मानक किस तरह की समझ में आता है और मैंने प्रबंधन और टीम के साथ इसे मंजूरी दे दी है। यहाँ विचार यह सुनिश्चित करने के लिए है कि प्रबंधन इस विचार के साथ ठीक है और मैं सिर्फ अपनी बात नहीं कर रहा हूँ और फिर बाकी सभी को इसे लेने के लिए मजबूर कर रहा हूँ।

मैं इस सवाल को और अधिक देखना चाहता हूं कि आपकी टीम के पास किस तरह के मानक और व्यवहार हैं, न कि केवल कौशल स्तर के बजाय क्योंकि कोड का मूल्यांकन करने के कई तरीके हैं। दूसरों को कितनी अच्छी तरह बनाए रख सकते हैं यह उन मानदंडों में से एक है।

Answer 12

समस्या यह है कि आप स्रोत की अच्छी पठनीयता चाहते हैं, लेकिन पठनीयता देखने वाले की नज़र में है।

मेरा सुझाव है कि इस समस्या को हल करने के लिए हमें बेहतर उपकरणों की आवश्यकता है। कुछ भी जटिल नहीं है, आप बुरा मानें, हमारे पास 50 से अधिक वर्षों तक इसे करने की तकनीक है। संपादक में एक पार्सर को शामिल करें, और संपादक को सेक्स के रूप में स्रोत को बचाएं (हाँ, बिल्कुल लिस्प की तरह)। फिर स्रोत पढ़ा जाता है, संपादक इसे वाक्य रचना और टाइपोग्राफिक में जानता है (आप जानते हैं, रिक्त स्थान, टैब, अल्पविराम), उपयोगकर्ता वरीयताएँ बनाते हैं।

इस तरह, आप टाइप कर सकते हैं और पढ़ सकते हैं x = x || 10और अन्य प्रोग्रामर इसे पढ़ेंगे

if (0 == x) { x = 10;}

emacs के पास आसानी से करने के लिए सभी टुकड़े हैं।

Comments

इस मामले में हम जानते हैं कि देखने वाले कौन हैं। वे हमारे सहकर्मी हैं। मुझे लगता है कि आम तौर पर वाक्यांश का उपयोग तब किया जाता है जब आप अपने दर्शकों को नहीं जानते हैं।

— dcaswell

Answer 13

कोड को गूंगा करने के बजाय, टीम की गुणवत्ता में सुधार क्यों नहीं? प्रशिक्षण, कोचिंग, शिक्षा और बेहतर काम पर रखने के अभ्यास निरंतर सुधार सुनिश्चित करने की दिशा में बहुत कुछ कर सकते हैं।
स्टेटिज्म, कोड सड़ने, सुधारने और नवाचार करने से इंकार करना क्योंकि कोई व्यक्ति आत्म-सुधार पर काम नहीं करना चाहता है, केवल रेखा के नीचे परेशानी का कारण बनता है, और बाद में जल्द ही।

निश्चित रूप से आपके द्वारा दिखाए जाने वाले विशिष्ट मामले में, आप केवल चतुर और जानबूझकर मोटे कोड लिखने की कोशिश कर रहे हैं, जो कि एक अच्छा विचार नहीं है। कोड सबसे पहले और सबसे महत्वपूर्ण होना चाहिए, आसानी से समझा जा सकता है, यह दिखाने के लिए नहीं लिखा जाता है कि आप कम से कम संभव बयानों में कुछ बनाने में कितने चतुर हैं (विशेष मामलों को छोड़कर, जैसे कि जहां अधिक बयानों को अस्वीकार्य रूप से खराब प्रदर्शन की ओर ले जाया जाएगा, जिस स्थिति में कॉपीराइट टिप्पणियाँ कहते हैं के लिये)।

Comments

इस मामले में, मैं चालाक नहीं हूँ। मैं किसी भी अनुभवी देव के लिए मुहावरेदार कोड लिख रहा हूं। क्या आप देख रहे हैं कि मैं अब संघर्ष क्यों कर रहा हूँ? :)

— फ्लोरियन मार्गाइन

आपका पहला पैराग्राफ ऑन है, लेकिन -1 क्योंकि आपका दूसरा पैराग्राफ मार्क से हटकर है। यह कहना गलत है कि यह उदाहरण चतुर होने का एक जानबूझकर किया गया प्रयास है। यह वास्तव में बहुत स्पष्ट है, और इससे भी महत्वपूर्ण बात यह है कि यह एक मुहावरेदार शैली है जिस पर कई अच्छे जावास्क्रिप्ट डेवलपर्स सहमत हैं। यह डिफ़ॉल्ट फ़ंक्शन मापदंडों के लिए जावास्क्रिप्ट में एकमात्र मुहावरा नहीं है, लेकिन यह एक आम है।

— बेन ली