सह-कार्यकर्ताओं के साथ व्यवहार करना जिनके पास सुसंगत कोडिंग शैली नहीं है?

Question

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

• अलग नामकरण सम्मेलनों और खिताब (का मिश्रण underscore_styleऔर camelCaseऔर UpperCamelऔर CAPSसभी एक ही समारोह में अधिक या कम पर विभिन्न चर के यादृच्छिक लागू)
• विचित्र और असंगत रिक्ति, उदाहरण के लिए Functioncall (arg1 ,arg2,arg3 );
• टिप्पणियों और चर नामों में बहुत सारे गलत शब्द

हमारे पास एक अच्छा कोड समीक्षा प्रणाली है जहां मैं काम करता हूं, इसलिए हम सबसे खराब सामान को देखने और ठीक करने के लिए प्राप्त करते हैं। हालाँकि, कोड की समीक्षा भेजना वास्तव में बहुत बुरा लगता है, जिसमें "यहाँ स्पेस जोड़ें" की 50 पंक्तियाँ शामिल हैं। 'itatorator' को सही ढंग से लिखें। इस कैपिटलाइज़ेशन को बदलें। आदि।

आप इस व्यक्ति को इस प्रकार के विवरणों के साथ अधिक सावधान और सुसंगत रहने के लिए कैसे प्रोत्साहित करेंगे?

Comments

"सुंदर प्रिंटर" मदद करते हैं। इसके अलावा, क्या आपकी फर्म में स्टाइल गाइड है?

— चिरसायकॉक

उन सहकर्मियों के बारे में क्या जिनके पास कोई व्याकरण नहीं है? ;)

— मुदादिब

@JSBangs: प्री-कमिट स्टाइल स्टाइलर इंस्टॉल करें और इसे कमिट करने से मना करें। यह उन्हें जल्दी से सही ढंग से प्रारूपित करने के लिए मिलेगा। या पूर्व-लिखें हुक है चलाने के आप के लिए एक फ़ॉर्मेटर। कुछ सामान दिखेगा लेकिन यह अजीब से बेहतर है "भयानक" मेरे हिसाब से बेहतर है।

— हाइलम

एक और विचार - यह छोटा लग सकता है, लेकिन एक उद्देश्य के लिए इसकी क्षुद्रता (यह मानते हुए कि एक) एक कोडिंग मानक है और यह ख) बाकी सभी सहमत हैं और इसका पालन करते हैं)

— मर्फ़

इस प्रोग्रामर की पृष्ठभूमि क्या है? लगता है जैसे उसने कई अलग-अलग कंपनियों के लिए बहुत सारे अलग-अलग कोड स्वरूपण सम्मेलनों के लिए काम किया है, और उसके मस्तिष्क ने उन सभी को एक गड़बड़ गड़बड़ में बदल दिया है। :-)

— कार्सन ६३०००

Answer 1

एक कोडिंग कन्वेंशन पर सहमत

भले ही यह एक पेजर हो। मेरा सुझाव है कि पूरी टीम बैठती है और सभी बुनियादी कामकाजी कोडिंग सम्मेलन पर सहमत होते हैं जिसका उपयोग पूरी टीम कर सकती है।

Comments

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

— मर्फ़

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

— हाइलम

Answer 2

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

मुझे लगता है कि अगर आप खुद इन चीजों को ठीक करते हैं, जैसे कि निमशिम्प्सकी ने सुझाव दिया, तो आप इस व्यक्ति को हमेशा के लिए साफ कर देंगे।

Answer 3

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

ऐसे पेशे के लिए जहां आपके सिंटैक्स को काम करने के लिए 100% सही होना चाहिए, किसी भी वास्तविक डेवलपर के लिए एक साफ, सुसंगत कोड शैली नहीं होने का कोई बहाना नहीं है। और कुछ भी आलस्य और आलस्य है। मैं हमेशा सवाल करता हूं कि क्रियान्वयन में कोड की शुद्धता सही है।

Answer 4

हमारे पास एक अच्छा कोड समीक्षा प्रणाली है जहां मैं काम करता हूं, इसलिए हम सबसे खराब सामान को देखने और ठीक करने के लिए प्राप्त करते हैं। हालाँकि, कोड की समीक्षा भेजना वास्तव में बहुत बुरा लगता है, जिसमें "यहाँ स्पेस जोड़ें" की 50 पंक्तियाँ शामिल हैं। 'itatorator' को सही ढंग से लिखें। इस कैपिटलाइज़ेशन को बदलें। आदि।

मैं इसे स्वयं बदलूंगा और फिर कोड में एक विनम्र टिप्पणी जोड़ूंगा।

यह मानता है कि पहले से ही एक स्टाइल गाइड है जैसा कि कहा गया है:

हमारे पास एक अच्छा कोड समीक्षा प्रणाली है

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

Comments

यह बहुत तेजी से पुराना हो जाता है।

— रॉबर्ट हार्वे

यह संभवतः आपके लिए ई-मेल भेजने की तुलना में तेज़ है, और समस्या के ठीक होने के लिए समग्र रूप से तेज़ है, लेकिन यह पहले की तुलना में समस्या न होने की तुलना में धीमी है।

— हाइलम

Answer 5

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

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

कृपया ध्यान दें कि मैं यहाँ स्पेगेटी / काउबॉय स्टाइल कोडिंग की वकालत नहीं कर रहा हूँ, वास्तव में मैंने कुछ बहुत अच्छी तरह से फॉर्मेट की गई स्पेगेटी कोड (4-5 स्क्रीन वाले फंक्शन बॉडीज, अलग-अलग सोर्स कोड फ़ाइलों के चारों ओर बिखरे हुए ग्लोबल वैरिएबल, आम तौर पर नामों के पिक्स) देखे हैं। , आदि)।

Comments

आप इस तरह के कोड के बारे में क्या कहते हैं: stackoverflow.com/questions/6221098/save-mapview-as-a-bitmap/… क्या आपको अभी भी लगता है कि जिस प्रोग्रामर ने इस "शैली" के साथ सौदा किया है, वह एक बुरा किसान है अगर वह इसके साथ गंभीर समस्या है?

— वॉरेनफैथ

@WarrenFaith, आप शायद मेरे तीसरे पैराग्राफ को फिर से देखना चाहते हैं, विशेष रूप से इस टुकड़े को यहाँ: "कृपया ध्यान दें कि मैं यहाँ स्पेगेटी / काउबॉय स्टाइल कोडिंग की वकालत नहीं कर रहा हूँ ..."।

— जस

Answer 6

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

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

Answer 7

मैं जिस कोड के बारे में बात कर रहा हूं, वह आमतौर पर तकनीकी रूप से सही है, यथोचित संरचित है, और यहां तक ​​कि एल्गोरिदमिक रूप से सुरुचिपूर्ण भी हो सकता है ...

खुश रहो कि तुम्हें वह सब मिल गया। अधिकांश प्रोग्रामर शायद आपको उस सूची में पहली चीज देंगे। मुझे लगता है कि चर नामकरण और रिक्ति के बारे में चिंता करने के लिए कम से कम महत्वपूर्ण बात है।

Comments

प्रोग्रामर कोड लिखने की तुलना में अधिक समय पढ़ने वाले कोड में बिताते हैं। यदि कोड अपठनीय है, तो इसे बढ़ाने या बनाए रखने की लागत बहुत बड़ी हो जाती है। और यदि चर नाम असंगत, गलत वर्तनी वाले और गैर-वर्णनात्मक हैं, तो यह कोड को अपठनीय बनाता है।

— दीमा

@ डिमा, सच है, लेकिन वह कोड जो काम करता है और सुरुचिपूर्ण है, पहले से ही कोड की तुलना में पढ़ना आसान है जो टूटा हुआ है और असंगत है।

— jjnguy

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

— दीमा

@ दीमा, मैं सहमत हूं कि चर में वर्णनात्मक नाम होना चाहिए। ओपी का उल्लेख नहीं है कि नाम खराब हैं, बस वे असंगत हैं।

— jjnguy

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

— दिमा

Answer 8

लगता है जैसे आपको एक शैली सम्मेलन को स्थापित करने और सहमत होने की आवश्यकता है। यदि आपके पास ऐसी लाइब्रेरी नहीं है, जिसमें 3 स्पेस इंडेंट्स हैं, तो अन्य जिनमें 4 हैं, कुछ जो कैमल केस का उपयोग करते हैं और अन्य जो अंडरस्कोर_केस का उपयोग करते हैं।

Answer 9

क्या परिवर्तन आप अपनी व्यक्तिगत प्राथमिकताएँ करना चाहते हैं या आपके पास पालन करने के लिए एक वास्तविक मानक है? यदि आपके पास वास्तविक मानक नहीं है, तो ऐसा न करें। पहले एक मानक तय किया। फिर आप ऐसे सॉफ़्टवेयर प्राप्त कर सकते हैं, जो कोड को स्टैन्डर्ड सेटिंग्स (अच्छी तरह से कुछ चीजों के कम से कम) के लिए रीफ़ैक्टर करने के लिए सेट किया जा सकता है।

यदि आपके पास एक मानक है, तो इसे कोड समीक्षा में लागू करना शुरू करें। यदि आप इसे कोड समीक्षा में लागू नहीं करते हैं तो मानक होने का कोई मतलब नहीं है। इसका मतलब रखरखाव में बहुत सारे अतिरिक्त काम होंगे क्योंकि लोगों को पुराने कोड को ठीक करना होगा जो इसे छूने पर मानक रूप से पूरा नहीं करते थे।

यहां तक ​​कि एक मानक के बिना, चर नामों में गलत वर्तनी को ठीक करने पर जोर देते हैं (मैं विशेष रूप से टिप्पणियों के बारे में चिंता नहीं करेगा) क्योंकि वे हर किसी को ड्राइव करेंगे जो कोड को हमेशा के लिए छूता है।

Answer 10

कोडिंग मानकों को पहचानने की आवश्यकता है ताकि हर कोई जानता है कि वे क्या हैं और फिर उन्हें लागू करने की आवश्यकता है। नियमों का पालन नहीं करने के परिणाम होने चाहिए।

यहां कुछ चीजें दी गई हैं, जिनसे कुछ प्रोत्साहन मिल सकता है:

1. कोड समीक्षा थकाऊ और आवश्यकता से अधिक लंबी होगी।
2. कोड को अधिक बार अस्वीकार कर दिया जाएगा।
3. अनुसूचियों को पूरा नहीं किया जाएगा।

यदि इस व्यक्ति को इस बारे में चिंता करने की ज़रूरत नहीं है क्योंकि कोई भी आपके नियमों को लागू नहीं करता है या यदि वे अनुत्पादक हैं (और कोई भी उस बारे में कुछ भी नहीं करता है) तो वे परवाह नहीं करते हैं, इसके बारे में आप बहुत कुछ नहीं कर सकते हैं।

Answer 11

मुझे यह सुझाव देने के लिए लुभाया जाएगा कि आप एक निजी चैट करें और देखें कि क्या आप दोनों इसका मूल कारण ढूंढ सकते हैं:

1. क्या सहकर्मी को हड़काया गया है और क्योंकि किसी को कोड चाहिए था कल वह व्यक्ति जितनी तेजी से काम कर रहा है उतना कुछ पाने की कोशिश कर रहा है? यह इस व्यक्ति को अपने काम में गति से अधिक गुणवत्ता पर ध्यान केंद्रित करने के लिए सूचित करने का एक अवसर हो सकता है। यदि यह प्रति-उत्पादक नहीं है, तो "अपना समय ले लो," जैसे मंत्र उपयोगी हो सकते हैं।

2. व्यक्ति अपने काम को कैसे देखता है? यदि गर्व की भावना है, तो आपके पास एक को बेहतर बनाने के लिए उपयोग करने के लिए एक कोण हो सकता है। यदि यह सिर्फ एक काम है जो बिलों का भुगतान करता है, तो परिवर्तन प्राप्त करना बहुत कठिन हो सकता है। क्या वे जानते हैं कि वे एक महान काम नहीं कर रहे हैं, लेकिन इसके बहुत करीब हैं?

3. क्या यह व्यक्ति सम्मेलनों से असहमत है और विरोध में कोड करने की कोशिश कर रहा है? यदि ऐसा है, तो आपको एक बड़ी समस्या हो सकती है, लेकिन यह पता लगाने के लायक है कि क्या यह मामला है या व्यक्ति केवल आलसी है? यहां किस प्रकार की प्रेरणा उपयोगी हो सकती है, उदाहरण के लिए, आप व्यक्ति को सुधारने के लिए लालच, गर्व, या कुछ अन्य उपाध्यक्ष की अपील कर सकते हैं। यह डरपोक है लेकिन संभवत: प्रभावी है अगर अच्छा आदमी मार्ग की कोशिश कर रहा है एक कहीं नहीं मिलता है।

4. दोस्तों को कैसे जीतें और प्रभावित करें लोगों के पास कुछ सुझाव हैं जो प्रेरक होने के रूप में काम कर सकते हैं, जैसे कि सुधार की प्रशंसा करना और व्यक्ति को बनाए रखने के लिए एक अच्छी प्रतिष्ठा देना।

निजी तौर पर ऐसा क्यों किया जाए, इसके कुछ कारण यहां दिए गए हैं:

1. अपमान, आलोचना या अन्य अप्रियता के लिए एक अच्छा मौका है, जो खुले में बाहर की ओर एक दरवाजे के पीछे बेहतर तरीके से रखा जाता है जहां कोई महसूस कर सकता है कि उनके चरित्र की हत्या की जा रही है।

2. आप इस दूसरे व्यक्ति को थोड़ा खोलने के लिए प्रोत्साहित करना चाहते हैं। यहां एक चुनौती यह है कि कुछ लोग इतने पहरेदार हैं कि उन्हें अपनी दीवारों को नीचे ले जाने में लंबा समय लग सकता है।

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

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

Answer 12

हमारे पास एक JUnit परीक्षण है जो समस्याओं को स्वरूपित करने के लिए देखता है। यह निर्माण के भाग के रूप में चलता है। मैं लगातार अगर, जबकि या के लिए और उद्घाटन कोष्ठक के बीच एक स्थान को छोड़ कर बिट मिलता है। हमारा कोड लगातार प्रारूपित है, यद्यपि।

http://code.google.com/p/kawala/wiki/BadCodeSnippetsRunner

Answer 13

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

Answer 14

यदि आप एक्लिप्स का उपयोग करते हैं, तो जावा संपादकों के लिए सहेजें क्रियाओं को सक्षम करें, और हर किसी को इसका उपयोग करने के लिए कहें। यह हर सेव पर फ़ॉर्मेटिंग मुद्दों को ठीक करता है, लेकिन खराब कैपिटलाइज़ेशन को ठीक नहीं करता है। हालांकि यह काफी मददगार हो सकता है!

Answer 15

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

Answer 16

जबरदस्त हंसी। आपको मेरे कोड से बिल्कुल नफरत होगी। मैं अपने जीवन को बचाने के लिए जादू नहीं कर सकता और मुझे परवाह नहीं है।

लेकिन मुझे पता है कि कुछ लोग वास्तव में उन चीजों की परवाह करते हैं।

मेरा सुझाव है कि आप उस बदसूरत कोड को लिखने वाले व्यक्ति को आग लगा दें यदि वे नहीं बदलते हैं तो किसी ऐसे व्यक्ति को ढूंढें जो चीजों को वास्तव में सुंदर बनाता है और आशा करता है कि वे कोड लिख सकते हैं

आमतौर पर तकनीकी रूप से सही, यथोचित संरचित होता है, और यहां तक ​​कि एल्गोरिदमिक रूप से सुरुचिपूर्ण भी हो सकता है

और अगर वे नहीं कर सकते हैं तो कम से कम आप ग्राहक को टूटे हुए सुंदर कोड दिखा सकते हैं और उस पर उन्हें बेच सकते हैं!

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

Comments

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

— दीमा

यह "नाजुक संवेदनशीलता" की तुलना में थोड़ा अधिक है, लेकिन उत्पादकता मैं किसी को अलग-अलग कोडिंग शैलियों के साथ बुरा नहीं मानता, कभी-कभी किसी स्थान को भूल जाता है, आदि ... हम सही नहीं हैं। लेकिन जब पूरी फाइल लगती है कि यह एक अंडरग्रेड, डब्ल्यू / असंगत लाइन रिक्ति, स्थिति, इंडेंटिंग और सामान्य कोड प्रवाह लिखा गया है, तो मैं बस "अस्वीकार" (या वापस) बटन को बहुत जल्दी से हिट करूंगा।

— केश

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

— ०४

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

— ElGringoGrande 12

Answer 17

मेरा समाधान जब आउटसोर्स किए गए संसाधनों के साथ काम करना, जो फॉर्मेटिंग के बारे में &% $ # नहीं देते थे (या उस मामले के लिए आसानी से रोके जाने वाले कीड़े) तो बिल्ड सर्वर को लागू करना था। मैंने एक सीआई सर्वर जॉब बनाई जो हर रात चलती थी जो कोड को चेक करती थी, जालोपी और खोजबीन चलाते थे और फिर कोड को वापस चेक करते थे। एक बार जब दूसरी टीम को पता चला कि मानक कोड सम्मेलनों का उपयोग नहीं करने से उनका काम कठिन हो जाएगा, तो उन्होंने उनका उपयोग करना शुरू कर दिया। मानक प्रारूप बनाए रखने के लिए आईडीई।