लंबे समय से आयोजित, गलत प्रोग्रामिंग मान्यताओं [बंद]

Question

मैं जूनियर (और शायद वरिष्ठ) सॉफ्टवेयर इंजीनियरों द्वारा की गई सामान्य त्रुटियों और खराब धारणाओं में कुछ शोध कर रहा हूं।

आपकी सबसे लंबे समय तक आयोजित धारणा क्या थी जिसे अंततः सुधारा गया था?

उदाहरण के लिए, मैंने गलत समझा कि पूर्णांक का आकार एक मानक नहीं है और इसके बजाय भाषा और लक्ष्य पर निर्भर करता है। राज्य के लिए थोड़ा शर्मनाक है, लेकिन यह वहाँ है।

निर्भय बनों; आपके पास क्या दृढ़ विश्वास था, और लगभग कितने समय तक आपने धारणा बनाए रखी? यह एक एल्गोरिथ्म, एक भाषा, एक प्रोग्रामिंग अवधारणा, परीक्षण, या प्रोग्रामिंग, प्रोग्रामिंग भाषाओं या कंप्यूटर विज्ञान के बारे में कुछ और हो सकता है।

Comments

आप रुचि हो सकती है doi.acm.org/10.1145/1364782.1364795 doi.acm.org/10.1145/984458.984495 doi.acm.org/10.1145/1142031.1142053

— साइमन गिब्स

Answer 1

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

ब्लॉग पढ़ना, स्टैक ओवरफ्लो और प्रोग्रामिंग किताबें हमेशा मुझे यह महसूस करवाती थीं कि मैं उन चीजों के पीछे वक्र हूं, जिन्हें सभी प्रोग्रामर को सहज रूप से जानना चाहिए।

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

Comments

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

— जब्बासो

यह समझने में भी मदद करता है कि वे ब्लॉगर अपने सिर के ऊपर से सब कुछ नहीं लिख रहे हैं। अच्छे ब्लॉगर अपने विषयों पर शोध करते हैं और पोस्ट लिखते समय नई चीजें सीखते हैं।

— जॉनफैक्स

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

— ब्रैड

@Zilupe: उस के लिए आमीन। मैंने कुछ अंतर्राष्ट्रीय सम्मेलन पत्र-पत्रिकाओं को प्रकाशित किया है। कुछ लोगों की नज़र में, यह अच्छा लग रहा था। जब तक आपको एहसास हुआ कि यह वास्तव में एक पेपर प्रकाशित करने के लिए बहुत प्रयास नहीं करता है। हम कोई जीनियस नहीं हैं। हम हर किसी की तरह हैं। हमने गलतियाँ कीं, और हम बकवास कागजात प्रकाशित करते हैं। खैर, असली प्रतिभाओं के कुछ अल्पसंख्यक समूह को छोड़कर ...

— हाओ वूई लिम

+1 अच्छी बात यह मैंने पढ़ी। मैंने सोचा केवल मैं ही हूं।

— रेंडेल

Answer 2

वे लोग जानते थे कि वे क्या चाहते हैं।

सबसे लंबे समय तक मैंने सोचा था कि मैं लोगों के साथ बात करूंगा, वे एक समस्या या वर्कफ़्लो का वर्णन करेंगे और मैं इसे कोड में डालूँगा और इसे स्वचालित करूँगा। हर बार ऐसा होता है, जो उन्हें लगता है कि वे चाहते थे कि वास्तव में वे नहीं चाहते थे।

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

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

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

Comments

या जो वे चाहते थे उसे देखने के बाद जो पहले चाहते थे उसे बदल दें। लोग अपना मन बदलना पसंद करते हैं। मुझे पता है, cuz मैं एक व्यक्ति हूं।

— जे। पोलफर

आप उन्हें वही दे रहे थे जो उन्होंने मांगा था, न कि वे जो चाहते थे।

— ब्रेंट बैस्ले

क्यों उबाऊ निर्विवाद नहीं-जवाब इतना अधिक मतदान हो?

— nes1983

वाह। लगता है जैसे किसी को गले लगाने की जरूरत है।

— bzlm

मेरे भगवान @ शिकायत करने वाले लोग, स्टैकओवरफ्लो प्रतिनिधि एक प्रतियोगिता नहीं है। यदि आपको जवाब में मजा आया है तो अपवोट करें क्योंकि आप ईर्ष्या कर रहे हैं क्योंकि आपने इसे पहले पोस्ट नहीं किया था।

— दिमित्री फ़ारकोव

Answer 3

मुझे पता है कि प्रदर्शन समस्या प्रोफाइल के बिना कहाँ है

Comments

मुझे लगता है कि यही कारण है कि समय से पहले अनुकूलन इतना सामान्य स्थान है।

— हाओ वूई लिम

+1 वाह, किसी ने एक उत्तर शामिल किया जो तुच्छ या ऑफ-टॉपिक नहीं था।

— मार्क रोजर्स

मुझे कुछ गोलियाँ मिली हैं जो समय से पहले अनुकूलन के साथ मदद करनी चाहिए ...

— एंडीएम

Answer 4

कि मेरे पास फंक्शन / मेथड से केवल एक ही एग्जिट पॉइंट होना चाहिए।

Comments

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

— त्रिनको

इसके साथ कौन आया, वैसे? यह एक प्रोग्रामिंग शहरी कथा की तरह है।

— ब्रैड

जिन लोगों को अन्य लोगों के कोड को डीबग करना होता है वे लोग आते हैं।

— गेटोरैक्स

मुझे लगता है कि यह आम तौर पर आयोजित किया जाता है लेकिन गलत विचार गलतफहमी पर आधारित है। जब आप किसी फ़ंक्शन से बाहर निकलते हैं, तो आपको हमेशा उसी बिंदु पर लौटना चाहिए । यह BASIC जैसी भाषाओं में एक महत्वपूर्ण नियम था, जिसने इसे लागू नहीं किया था: उदाहरण के लिए, नियम का अर्थ था, कि आपको GOTO के बजाय GOSUB का उपयोग करना चाहिए। C # या Java जैसी भाषाओं में, जो विधियाँ कहती हैं, यह स्वचालित है। लेकिन क्योंकि यह स्वचालित है, मुझे लगता है कि यह तार्किक "केवल एक वापसी-बिंदु" से निरर्थक "केवल एक निकास बिंदु" तक रूपांतरित है।

— रेयान लुंडी

C जैसी भाषाओं से जहां यो को मैन्युअल रूप से रीसस जारी करने की आवश्यकता है। कई एक्ज़िट पॉइंट्स, रिसोर्स स्रोतों को लीक करने का एक अच्छा मौका था। IMO का अपवादों वाली भाषाओं से कोई मतलब नहीं है, क्योंकि आप अक्सर अपने निकास बिंदुओं को नहीं जानते हैं, या एक बयान के बीच में हैं। - इन भाषाओं में, वह सब "पठनीयता के लिए संरचना" है।

— peterchen

Answer 5

उस गैर-प्रॉक्टर ने समझा कि मैं किस बारे में बात कर रहा हूं।

Comments

समझ / देखभाल ..

— निक

मेरे पास अभी भी एक बार ऐसा है ... मुझे लगा कि कम से कम मेरी पत्नी को अब तक ठीक से समझ में आने लगा होगा: P

— workmad3

ओह डियर, मुझे डर है कि मैं अभी इसे सीख सकता हूं!

— उस दिन

हाँ, कभी-कभी मैं अपने दर्शकों को भूल जाता हूं और लोगों के एक झुंड के साथ समाप्त होता है wtih कोरे चेहरे पर लग रहा है, जो मुझे घूर रहा है, यह अच्छा है जब लोग एक रुचि दिखाते हैं

— Petey B

यह पेशे के साथ मेरी सबसे बड़ी हताशा है।

— एंड्रेस जान टैक

Answer 6

वह बगफ्री सॉफ्टवेयर संभव था।

Comments

+1, हालांकि नासा ने लगभग इसे प्रबंधित किया

— पैट्रिक मैकडोनाल्ड ने

हां, लेकिन "लगभग" की कीमत कुछ मिलियन डॉलर है :)

— जेम

@Triynko आपके "संभव" और @ JaredPar के "संभव" समान नहीं हैं। सिद्धांत और व्यवहार सिद्धांत में समान हो सकते हैं लेकिन व्यवहार में बहुत भिन्न हैं।

— विल्हेमटेल

@ जोसेफ, समस्या का हिस्सा है लोग सोचते हैं कि हैलो वर्ल्ड प्रोग्राम बग फ्री हैं। वे नहीं हैं। ज्यादातर असफल IO प्रयासों के उदाहरण या खाते के लिए प्रिंट में त्रुटियों की जांच नहीं करते हैं।

— जारेदपार

@RussellH, नहीं। आप वापसी मान निर्दिष्ट करने में विफल रहे हैं और परिणामी प्रक्रिया यादृच्छिक कचरा मेमोरी लौटाएगी।

— जेरदपर

Answer 7

वह निजी सदस्य चर उदाहरण के लिए निजी थे और वर्ग नहीं।

Comments

मैंने उस धारणा को तब तक कायम रखा जब तक ... अभी-अभी।

— TheMissingLINQ

@ebrown मैं आम तौर पर केवल तभी उपयोगी साबित होता है जब एक बराबर () विधि लिखता है

— डेव वेब

वे रूबी में हैं।

— माइक कुचेरा

यह मेरे लिए इतना सामान्य है कि इस उत्तर का मतलब यह नहीं है कि पहली बार मैंने इसे पढ़ा। अब मैं रूबी को सीखना चाहता हूं ताकि यह मुझे दूसरे तरीके से भ्रमित कर सके। :)

— jmucchiello

@Kiewic यदि आपके पास अपने वर्ग के अंदर myVar नामक एक निजी सदस्य चर है, तो आप अपने कोड में अन्य.myVar को सीधे संदर्भित कर सकते हैं यदि अन्य इस वर्ग का उदाहरण है। मैंने मान लिया था क्योंकि यह "निजी" था आपको क्लास के अंदर भी अन्य .getMyVar () का उपयोग करना था।

— डेव वेब

Answer 8

मुझे लगा कि आपके कीबोर्ड पर स्थिर टाइपिंग बहुत स्थिर है।

Comments

ईमानदारी से या नहीं, इससे मुझे काम के लंबे दिन के अंत में हंसी आती है। : पी

— ओलिवियर ट्रेमब्ले

++ एक अच्छी हंसी के लिए। लगता है कि कुछ मेरे (गैर-तकनीकी) पति के साथ आएगा।

— जेस

+1! मैंने सोचा कि डक टाइपिंग में टाइपिंग भी शामिल है। या बत्तख। अथवा दोनों।

— स्क्लैकिड

Answer 9

कि आप एक समस्या को विकसित होने से पहले पूरी तरह से समझ सकते हैं।

Comments

यह, मेरे दोस्त, होना चाहिए: "आप पूरी तरह से एक समस्या को समझ सकते हैं।" लेकिन यह कितना सच है। और स्पष्ट रूप से समझने या यहां तक ​​कि स्वीकार करने के लिए एक कठिन अवधारणा।

— कार्लप

आप समस्या को "पूरी तरह से" नहीं समझ सकते, लेकिन निश्चित रूप से आप समस्या को समझना शुरू कर देंगे (कुछ डिग्री पर) इससे पहले कि आप विकसित करना शुरू करें। bit.ly/kLXgL

— OscarRyz

कभी-कभी आपको समस्या को समझने के लिए विकास करना शुरू करना पड़ता है। और / या, समस्या आपके द्वारा विकसित किए जाने वाले परिवर्तन को बदल देती है।

— इवान प्लाइस

Answer 10

स्मार्ट लोग हमेशा मुझसे ज्यादा स्मार्ट होते हैं।

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

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

कहानी का नैतिक: कभी भी कम मत समझना कि आप मेज पर क्या ला सकते हैं।

Comments

अच्छा था! मैं वर्तमान में एक सहकर्मी के साथ काम कर रहा हूं जो वास्तव में .NET विकास के बारे में बहुत कुछ जानता है। मुझे यह महसूस करने में कुछ समय लगा कि मैं यह समझने में बेहतर हूं कि ग्राहकों को क्या चाहिए।

— ट्रेब

और दूसरी तरफ, कि मैं अन्य लोगों से ज्यादा जानता हूं। यह पता चला है कि वे सिर्फ अलग सामान जानते हैं। अन्य नैतिक: कभी भी कम मत समझना कि कोई और मेज पर क्या ला सकता है।

— thursdaysgeek

यहाँ वह पुरानी "दूसरों की बात" फिर से है ... मैं एक नया वाक्यांश गढ़ रहा हूँ: टेक खरा ~ ~ श्रेष्ठ महसूस करने की स्थिति क्योंकि आप कुछ सामान जानते हैं, और बाकी सभी को यह बताने की गलती कर रहे हैं। @ सील्यो: स्मार्टास।

— प्रातः

उत्कृष्ट अवलोकन - मेरा संस्करण अधिक नकारात्मक है "हर कोई अब और फिर बेवकूफ बनाता है"। कुछ हद तक "बोजो बिट फ्लिप न करें" से संबंधित है।

— peterchen

आपको केवल तब चिंतित होना पड़ता है जब बेवकूफ लोग, आपसे ज्यादा स्मार्ट होते हैं।

— ब्रैड गिल्बर्ट

Answer 11

सबसे लंबे समय तक मैंने सोचा था कि बैड प्रोग्रामिंग कुछ ऐसा था जो फ्रिंज पर हुआ था .. जो कि डूइंग थिंग्स सही ढंग से आदर्श था। मैं इन दिनों इतना भोला नहीं हूं।

Comments

मुझे लगता था कि बैड प्रोग्रामिंग केवल अन्य प्रोग्रामर द्वारा की जाती थी, जब तक कि मैं अपने एक बैड प्रोग्राम के द्वारा नहीं किया गया था। अब मैं सही तरीके से बातें करता हूँ! (आप इस बार मुझ पर विश्वास करते हैं, ठीक है?)

— जेरेड अपडेटाइक

पूरी तरह से। मैं "यह कभी नहीं होता है" से "कि इस नौकरी के अलावा कभी नहीं होता है " से "हर जगह बुरा कोड होता है।"

— रयान लुनडी

हैकिंग आदर्श है। इंजीनियरिंग सही मायने में सक्षम होने के दायरे में है। अगर कभी किसी सॉफ्टवेयर इंजीनियर से मिलते हैं तो मैं आपको बता दूंगा।

— प्रातः

@corlettk: आपका मतलब है बंदर-कोडिंग आदर्श है, नहीं? हैकिंग एक कला है, एक उच्च स्तरीय कला मन है, जिसे प्राप्त करने से मैं बहुत दूर हूं।

— hasen

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

— लॉरेंस डोल

Answer 12

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

अब मैं कोशिश करता हूं कि चीजों को जितना संभव हो उतना सरल और डिकोड किया जाए। कुछ अमूर्त बनाने के लिए रिफैक्टिंग करना यह अनुमान लगाने की तुलना में बहुत आसान है कि मुझे कुछ अमूर्त करने की आवश्यकता कैसे है।

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

Comments

घोषित = सच्चा अमूर्तन। अपने स्वयं के लिए सार है ... समय से पहले का अनुकूलन।

— जेरेड अपडेटाइक

यह मेरे द्वारा प्रदर्शन ट्यूनिंग करते हुए पाया गया है। अमूर्तता की कई परतों के साथ एक प्यारा कार्यक्रम हो सकता है। फिर कार्यभार भारी हो जाता है, और लगता है कि हर समय क्या खर्च हो रहा है ... सभी सार। कंप्यूटर निर्देश निष्पादित करते हैं, अमूर्त नहीं।

— माइक डनलैवी

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

— पड़ता है

मैं पूरी तरह से जारेड के साथ सहमत हूं ... यदि आप "सरल और डिकम्पोज्ड" पाने में कामयाब रहे हैं तो आपने सही अमूर्तता हासिल की है। अगर आप चीजों को अमूर्त और कारखानों आदि में समाहित नहीं किया है, तो चीजों को कैसे रोका जा सकता है ...? यह सरल कैसे हो सकता है जब तक कि आप सभी "यदि प्रकार = यह नहीं करते हैं तो इसे हटा दें, या यदि प्रकार है तो कुछ और कोड करें"?

— रिचर्ड एंथनी हेन

मुझे भी। मुझे लगता है कि मैंने बहुत सारे स्पेगेटी कोड बनाने से पहले अमूर्तता के बारे में सीखा । उन्हें सिखाया जाना चाहिए कि कोड स्पेगेटी होने पर भी चीजों को कैसे प्राप्त किया जाए, और फिर हमें OO और अमूर्त के बारे में सिखाया जाए।

— hasen

Answer 13

कि महिलाओं को कंप्यूटर प्रोग्रामर सेक्सी लगते हैं ...

Comments

एक सेकंड रुको???

— 9ağdaş Tekin

उन्होंने कहा कि वह .. ठीक है, मैं दिन के आराम के लिए अपनी मुस्कान रखने के लिए कुछ ढूंढ रहा था। मुझे लगता है कि मैंने इसे पा लिया है !!! :)

— ऑस्कररेज़

पी: - "! ऊह, बेबी हाँ कहते हैं, 'अगर' मुझे कुछ अपवाद फेंक .. हाँ, आप जानते हैं कि मैं इसे कैसे चाहते हैं"

— cwap

क्या? प्रोग्रामर अमीर हैं? ऐसा कब हुआ?

— नवरा

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

— इवान प्लाइस

Answer 14

सॉफ्टवेयर की गुणवत्ता से बिक्री अधिक होगी। कभी-कभी ऐसा करता है लेकिन हमेशा नहीं।

Comments

सॉफ्टवेयर बेचना? ऐसा 1999 का है।

— bzlm

सदस्यता आधारित वेबसाइटों के बहुत सारे अब ...

— cgp

Microsoft यकीन है कि इस पर एक हत्या करता है।

— बिल मार्टिन

यह प्यार करता हूँ, तो यह सच है।

— डॉ।

मैं चाहता हूं कि हमारे सॉफ्टवेयर की गुणवत्ता / प्रदर्शन में सुधार एक विशेषता के रूप में गिना जाए

— टॉम लेयस

Answer 15

यह कि सभी भाषाएँ (ज्यादातर) समान हैं।

लंबे समय तक मुझे लगा कि पसंद की भाषा वास्तव में विकास प्रक्रिया की कठिनाई और परियोजना की सफलता की क्षमता में बहुत अंतर नहीं लाती है। यह निश्चित रूप से सच नहीं है।

नौकरी के लिए सही भाषा चुनना उतना ही महत्वपूर्ण / महत्वपूर्ण है जितना कि किसी अन्य एकल परियोजना का निर्णय।

Comments

मुझे लगता है कि सही पुस्तकालयों को चुनना यही मायने रखता है। यह सिर्फ इतना होता है कि भाषाओं और पुस्तकालयों के बीच अक्सर 1-टू -1 पत्राचार होता है ...

— केविन मॉन्ट्रोस

लेकिन अगर दो प्रोग्रामिंग लैंग्वेज दोनों ट्यूरिंग पूरी हैं तो क्या अंतर है? आप किसी भी प्रोग्राम को किसी भी भाषा में लिख सकते हैं! ;)

— छिपकली

मैं असहमत हूं, निर्णय किस भाषा का उपयोग करना है, यह कम महत्वपूर्ण है कि वास्तव में परियोजना को कौन लागू करेगा। कई अन्य महत्वपूर्ण निर्णयों के सिर्फ एक उदाहरण के रूप में।

— बोरिस टेरजिक

BrainFu ** अजगर के रूप में पूरा होने के रूप में ट्यूरिंग है।

— hasen

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

— ट्रायमैन

Answer 16

यह एक बड़ी टिप्पणी / कोड अनुपात एक अच्छी बात है।

मुझे यह महसूस करने में थोड़ा समय लगा कि कोड को स्व-दस्तावेजीकरण होना चाहिए। ज़रूर, यहाँ एक टिप्पणी और सहायक है अगर कोड को स्पष्ट नहीं किया जा सकता है या यदि कोई महत्वपूर्ण कारण है कि कुछ क्यों किया जा रहा है। लेकिन, सामान्य तौर पर, उस टिप्पणी समय को चर चर नाम देना बेहतर होता है। यह क्लीनर, स्पष्ट है और टिप्पणियों को कोड के साथ "सिंक से बाहर" नहीं मिलता है।

Comments

मैं वास्तविक कोड में सहमत हूं ... javadoc टिप्पणियों (या समकक्ष) को छोड़कर।

— प्रातः

+1, यहां तक कि मुझे ग्रंथ मैं 10 लाइन कार्यों के लिए लिखने के लिए इस्तेमाल किया पर शुरू नहीं मिलता है

— WDS

इसे जोड़ने के लिए, एक जोरदार () बयान एक पूर्व शर्त / पोस्टकंडिशन का दस्तावेजीकरण करने से बेहतर है। .NET 4 कोड अनुबंध स्वचालित रूप से प्रलेखन में भी बदल सकते हैं!

— रॉबर्ट फ्रेजर

Answer 17

वह प्रोग्रामिंग असंभव है।

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

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

जोड़ने के लिए, मुझे नहीं लगता कि प्रोग्रामिंग आसान है, यह एक चुनौती है और मुझे सीखना अधिक पसंद है और कुछ प्रोग्रामिंग समस्या को हल करने की तुलना में अधिक मजेदार नहीं है।

Comments

तथास्तु! लेकिन, हे, इस दृश्य को छतों से घोषित न करें। हम नहीं चाहते कि सभी को पता चले कि प्रोग्रामिंग मजेदार है, अब हम करते हैं? ;); पी

— पीटर पेराच

मास्टरपेटर: यह हमारे लिए और अधिक चारा देगा जब हम यहां आकर सवाल पूछेंगे।

— TheTXI

मैं कहूँगा कि प्रोग्रामिंग है कठिन सही करने के लिए । हालांकि, यह संभव है, जो आपकी बात लगती है।

— स्टीव एस

@ ओलाफुर: आप यह सवाल क्यों चाहते हैं कि विकी आपके जवाब के लिए नहीं, बल्कि आपके जवाब के लिए होगा।

— ग्नोविस

यह मेरे अनुभव को बिल्कुल स्पष्ट करता है। काश मैं अब जल्दी शुरू होता: पी

— स्किलड्रिक

Answer 18

"एरर रिज्यूमे नेक्स्ट पर" किसी तरह की एरर हैंडलिंग थी

Comments

मैं आपको महसूस करता हूं ... लेकिन vbscript (esp। Asp) में, यह केवल "त्रुटि से निपटने" विकल्प उपलब्ध था, जो कि विवेकपूर्ण जाँच के साथ संयुक्त था कि क्या वास्तव में त्रुटि हुई है, और प्रार्थना की एक उचित मात्रा है।

— फ्लैटलाइन

हाँ ... यह कुछ प्रकार का है ... बस एक प्रकार है कि हम दूर होने के लिए खुश हैं

— मैथ्यू

कुंआ?! लकिन यह है। आप अपने एरर-हैंडलिंग ब्लॉक को ऑन ओन एरर रिज्यूमे नेक्स्ट के साथ शुरू करते हैं, कुछ आज़माएँ, और फिर अगर (इर.नंबर <> 0) तो

— jpinto3912

क्या यह एक कोशिश पकड़ने के बराबर एकमात्र vbscript नहीं है?

— जेम्स 12

-1: यह एक तरह की एरर हैंडलिंग है। यह सिर्फ इतना सुंदर नहीं है।

— जॉनफैक्स

Answer 19

उस प्रोग्रामिंग सॉफ़्टवेयर को उच्च गणित में एक मजबूत नींव की आवश्यकता होती है।

सालों पहले कोडिंग शुरू करने के बाद मुझे हमेशा कहा जाता था कि एक अच्छा प्रोग्रामर बनने के लिए आपको उन्नत बीजगणित, ज्यामिति, पथरी, ट्रिगर, आदि में अच्छा होना चाहिए।

दस साल बाद और मुझे केवल एक बार कुछ भी करना था जो कि आठवें ग्रेडर के लिए नहीं था।

Comments

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

— स्टीव वॉर्थम

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

— hbw

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

— ज़ैक

उन्नत गणित को समझने के लिए आपको जिस प्रकार की अमूर्तता की आवश्यकता होती है, वह सॉफ्टवेयर बनाने के लिए आवश्यक अमूर्त के समान है।

— ऑस्कररेज़

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

— रिचर्ड एंथनी हेन

Answer 20

विधानसभा भाषा में == पुनर्लेखन को अनुकूलित करना।

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

Comments

पीक और पोक आपके दोस्त हैं :)

— मैथ्यू

बिगाड़ने! उस जज से कहो!

— शालोम क्रेमर

यह वह जगह है जहाँ जटिलता सिद्धांत आता है। विधानसभा आम तौर पर सूक्ष्म अनुकूलन है। अपने एल्गोरिदम को समय की जटिलता से छोटा बनाना जहाँ गति प्राप्त होती है।

— पीटीईटी

@scraimer: फैंसी आपको यहाँ देखकर, मैंने कभी इसकी उम्मीद नहीं की होगी ;-)

— रॉबर्ट एस। बार्न्स

@ मैथ्यू - "पीक और पोक आपके दोस्त हैं :)": ** अत्यधिक जलन मुझे पहले नहीं लिखा था।

— FastAl

Answer 21

• कि कंपनी के अधिकारी कोड की गुणवत्ता के बारे में परवाह करते हैं।
• वह कम रेखाएं बेहतर हैं।

Comments

वे परवाह करते हैं, लेकिन आपको कलाकार-कौशल को कार्यकर्ता-कौशल के साथ जोड़ना होगा। अल्गोरिटम कैंट का हर टुकड़ा कला का एक टुकड़ा हो सकता है। इसमें से कुछ प्लम्परिंग होंगे, इसलिए "कम उपयोग" का पुन: उपयोग करें। पुराने 80/20 नियम को याद रखें। कार्यक्रम का 80% समय का 20% उपयोग किया जाता है। तो कोड के 20% पर 80% ध्यान केंद्रित करें और एआरटी का वास्तविक विवरण बनाएं! : ओपी

— बर्गग्रीनडीके

कम लाइनें बेहतर हैं! एक भाषा के रूप में जावा को नापसंद करने का कारण यह है कि कुछ भी करने से कोड की बहुत सारी लाइनें लग जाती हैं। कोड की कम पंक्तियों का मतलब है कि अपने कोड को बदलना आसान है।

— क्लाउडीयू

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

— हरमास

सिवाय इसके कि जब लोग "कम लाइनों को बेहतर लेते हैं" तो जंजीर पद्धति से दूर होने की मानसिकता 7 गहरी कहलाती है ताकि जब उनमें से कोई एक शून्य सूचक फेंकता है, तो आपको पता नहीं चलता कि यह कौन सा था। या वे एक पंक्ति में इतने सारे कार्यों को संघनित करते हैं कि यह 150 वर्ण लंबा है और 4 संचालन करता है। यह पढ़ने में कठिन और डिबग करने के लिए कठिन दोनों बनाता है, लेकिन कोई तेज़ नहीं है और न ही निष्पादन के दौरान कम मेमोरी का उपयोग करता है।

— ट्रम्पस कर्क

यदि आपकी लाइन समाप्त हो गई है))))) और आप लिस्प नहीं लिख रहे हैं, तो आपके पास बहुत कम लाइनें हैं।

Answer 22

मैं कहूंगा कि एक तारीख के वर्ष तत्व को 2 अंकों के रूप में संग्रहीत करना एक धारणा थी जो डेवलपर्स की एक पूरी पीढ़ी को पीड़ित करती थी। Y2K पर जो पैसा उड़ाया गया, वह बहुत भयानक था।

Comments

यह केवल एक ही उत्तर है कि मैं उत्थान करूंगा, हालांकि यह सीडब्ल्यू है इसलिए यह कोई फर्क नहीं पड़ता ...

— दान रोसेनस्टार्क

IIRC कुछ सिस्टम 60 के दशक में और शायद 70 के केवल एक अंक का उपयोग किया क्योंकि यह कम मेमोरी का उपयोग करता था। मैंने ऐसे कागज के रूप भी देखे हैं जहाँ "196_" और "197_" पहले से अंकित थे।

— कुछ

मुझे अभी भी 200_ के साथ फॉर्म दिखाई दे रहे हैं और संभवत: 201_ प्रिंट के साथ अब कुछ हैं।

— माचा

दुखद बात यह है ... यूनिक्स का 2038 में इसका दूसरा दौर होगा

— इवान प्लाइस

@ बिली सिर्फ इसलिए क्योंकि मशीन आर्किटेक्चर में बदलाव का मतलब डेटा फॉर्मेट नहीं है। इंट प्रारूप में रिज़ॉल्यूशन के 2 अंकों को संग्रहीत करने से एक बाइट (8 बिट) की तारीख का प्रारूप बन जाएगा और, फिर भी, इसने 2k में 32bit हार्डवेयर आर्किटेक्चर मशीनों के टन को प्रभावित किया। यह केवल एक और उदाहरण है कि आप निम्न स्तरीय हार्डवेयर लोगों को डेटा प्रारूप क्यों निर्दिष्ट नहीं करते हैं। वे इस ज्ञान के साथ चुटकी काटते हैं कि सुदूर भविष्य में एक अनुसूचित SNAFU होगा।

— इवान प्लाइस

Answer 23

प्रविष्टि / बबल सॉर्ट के अलावा कुछ भी काफी बस काला जादू था।

Comments

हाहा, मुझे यह पसंद है, क्योंकि यह घर के करीब हिट करता है। एन-चुकता समय की तुलना में तेजी से क्रमबद्ध करें ?? Unpossible!

— रोस

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

— ब्रायन

मैं एल्गोरिदम छँटाई में एक शोधकर्ता हूँ! और वे अभी भी काले जादू की तरह महसूस करते हैं।

— SPWorley

मेरे कार्यक्रम में एक बार कोड की एक पंक्ति थी जो एक लंबी और जटिल थी और मुझे इसे तोड़ने या इसे समझाने (यह कुछ जटिल प्रकाश सूत्र है) की तरह महसूस नहीं हुआ था, इसलिए मैंने यह सब एक लाइन और #define पर डाल दिया। d इसे DARK_MAGICK होना चाहिए, और एकमात्र टिप्पणी डार्क मैजिक के रहस्यों को जानने की कोशिश करने के खिलाफ एक चेतावनी थी

— एलेक्स

बोगोसॉर्ट उन सभी में सबसे रहस्यमय है।

— एलेक्स बेयर्डले

Answer 24

यह XML वास्तव में इंटरऑपरेबल और मानव पठनीय डेटा प्रारूप होगा।

Comments

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

— टोनी एजेकॉम्बे

इसका एक अंतर-सिंटैक्स है, इसमें कोई संदेह नहीं है। इसका सिर्फ यही वाक्यविन्यास अक्सर किसी भी समाधान का सबसे कम महत्वपूर्ण पहलू है।

— साइमन गिब्स

+1, आप इच्छा-सूची में छोटे और तेज़ भी जोड़ सकते हैं।

— MarkJ

सही लेकिन सीएसवी पर एक सुधार और निश्चित लंबाई जहां प्रलेखन के बिना आपको खराब कर दिया जाता है।

— पीटीईटी

मैं XML को डेटा स्वरूपों में लाए गए मानकीकरण के लिए और चरित्र एन्कोडिंग को सही ढंग से संभालने के लिए पसंद करता हूं। मैं कभी-कभी XML का उपयोग करके जो कुछ भी करता है उससे नफरत करता हूं ।

— जोकिम सॉयर

Answer 25

वह सी ++ किसी भी तरह अन्य सभी भाषाओं की तुलना में आंतरिक रूप से बेहतर थी।

यह मुझे कॉलेज में मेरे एक दोस्त से कुछ साल पहले मिला था। मैंने इसे लंबे समय तक शर्मनाक तरीके से अपने साथ रखा (मैं अभी शरमा रहा हूं)। 2 साल या इसके साथ काम करने के बाद ही मैं इससे पहले कि वे क्या थे, दरारें देख सकते थे।

कोई भी - और कुछ भी नहीं - एकदम सही है, सुधार के लिए हमेशा जगह है।

Comments

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

— jpinto3912

@ जेपी: मैं अपनी पसंद के शब्दों से खुश हूं :)

— बाइनरी वॉरियर

व्यावसायिक अनुप्रयोगों की दुनिया में उत्पादकता अधिक मायने रखती है। बेशक, वहाँ कुछ niches कि c ++ की आवश्यकता है, और एकमात्र विकल्प है।

— शॉ

मैंने हमेशा यह माना है कि सी ++ सीधे एएनएसआई सी से भी बदतर है, सिर्फ इसलिए कि मैंने सी ++ प्रोग्रामर को जिस तरह की परेशानी में देखा है वह सी प्रोग्रामर को देखने में आई परेशानी की तुलना में बहुत अधिक जटिल है।

— नोसरेडना

दरअसल, वह भाषा जो अन्य सभी की तुलना में बेहतर है, वह कॉमन लिस्प है। C ++ बुरा नहीं है, हालांकि।

— डेविड थॉर्नले

Answer 26

मेरा मानना ​​था कि कार्यक्रम बनाना बिल्कुल वैसा ही होगा जैसा कक्षा में पढ़ाया जाता था ... आप लोगों के एक समूह के साथ बैठते हैं, किसी समस्या पर जाते हैं, एक समाधान के साथ आते हैं, आदि। इसके बजाय, वास्तविक दुनिया "यहाँ है" मेरी समस्या, मुझे इसे हल करने की आवश्यकता है, जाओ "और दस मिनट बाद आप एक और प्राप्त करते हैं, जिससे आपको अपने समाधान को कुशलतापूर्वक योजना बनाने के लिए कोई वास्तविक समय नहीं मिलता है।

Comments

मुझे लगता है कि जीवन कहा जाता है।

— रॉबिन डे

हम्मम .. यह समय है कि आप उस कंपनी को जमानत दें। ..

— jpinto3912

@ jpinto3912: नहीं, क्योंकि अगली कंपनी भी जीवन का एक हिस्सा होगी (पिछली टिप्पणी देखें)।

— ट्रेब

Answer 27

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

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

बेशक, लगभग हमेशा कुछ प्रकार के पैटर्न होते हैं, लेकिन वे अभिव्यंजक भाषाओं में उच्च स्तर पर हैं। अब मैं जावा में कुछ पेशेवर कोडिंग कर रहा हूं, और मुझे वास्तव में दर्द महसूस होता है, जब मुझे पैटर्न के मिलान और उच्च क्रम कार्यों के बजाय आगंतुक या कमांड पैटर्न जैसे सम्मेलन का उपयोग करना पड़ता है।

Comments

"कई पैटर्न सिर्फ बॉयलरप्लेट, या अतिरिक्त जटिलता थे, क्योंकि भाषा पर्याप्त अभिव्यंजक नहीं थी।" अभिव्यक्ति भाषा में बस बॉयलरप्लेट कोड है।

— अज्ञात

यह सच नहीं है, यह कैसे प्रोग्रामर की क्षमताओं को सीमित करने के बजाय प्रथम श्रेणी के सामान के लिए बॉयलरप्लेट है, जैसे उच्च आदेश कार्यों के मामले में। लिसप्स इसका सुंदर उदाहरण हैं।

— उदाहरण

Answer 28

पहले कुछ वर्षों के लिए मैं प्रोग्रामिंग कर रहा था कि मैं उस पर 1 पकड़ नहीं पाया था कि Kbyte तकनीकी रूप से 1024 बाइट्स है, 1000 नहीं। मैं हमेशा इस तथ्य से थोड़ा हैरान था कि मेरी डेटा फ़ाइलों के आकार मुझे उनसे क्या उम्मीद करते थे, उससे थोड़ा दूर लग रहे थे हो।

Comments

हार्ड ड्राइव निर्माताओं ने अभी भी नहीं पकड़ा है ...

— माइकल मायर्स

@ खरीदारों मुझे लगता है कि आप हार्ड ड्राइव विपणक सही मतलब? या ड्राइव वास्तव में इस तरह बनाया जाता है?

— Instantsoup

अरे, किबी से नफरत करना बंद करो। मेबी और कीबी कम से कम अन्बिग्बुओबस हैं।

— bzlm

किलो का मतलब होता है 1000, मेगा का मतलब होता है 1000000, गीगा का मतलब होता है 1000000000। यह रैम और ओएस बनाने वाले हैं जो इसे गलत बनाते हैं, ड्राइव बनाने वाले नहीं।

— मार्क रैनसम

कोई ऐसा करने वाला नहीं है? गंभीरता से? ठीक है, मैं इसे करूँगा ... xkcd.com/394

— एरिक फोर्ब्स

Answer 29

उस स्थिति की जाँच जैसे:

if (condition1 && condition2 && condition3)

एक अनिर्दिष्ट क्रम में किया जाता है ...

Comments

किस भाषा में? C / C ++, Java, और पायथन जैसी भाषाएं गारंटी देती हैं कि स्थितियों का मूल्यांकन दाईं ओर किया जाता है और यह मूल्यांकन पहली स्थिति में बंद हो जाता है जो झूठी हो जाती है। यह लैंग्वेज स्पेक का हिस्सा है। मेरा मानना ​​है कि अधिकांश अन्य भाषाएँ समान गारंटी देती हैं।

— क्लिंट मिलर

@ क्लिंट: हाँ, इसलिए "जो गलत निकला"।

— bzlm

हाँ, यह एक अच्छा है। यह अगर (myList! = null && myList.Count> = 0) {सामान ();} बहुत आसान है

— Zack

वास्तव में, यह भाषा पर निर्भर करता है, और सभी परिस्थितियों का मूल्यांकन करेगा (शॉर्टकट नहीं)। और मैंने कई लोगों को AndAlso (&&) के बजाय VB में (&) का उपयोग करते देखा है

— लुकास

। । । वास्तव में यह VB.net में भी दुर्घटनाग्रस्त हो जाएगा जब तक कि आप AndAlso re Lucas की टिप्पणी का उपयोग नहीं करते हैं

— बाइनरी

Answer 30

कि मेरी प्रोग्रामिंग तेज और बेहतर होगी अगर मैंने इसे अकेले प्रदर्शन किया।

Comments

लेकिन यह शायद अपने कोड

— अंडा

यह सब दूसरे व्यक्ति पर निर्भर करता है। =)

— जॉनफैक्स