क्या बार-बार कोड को आसान बनाना #define का उचित उपयोग है?


17

इस पर कोई विचार है कि क्या कोडिंग को सरल बनाने के लिए #define का उपयोग करना कोडिंग को सरल बनाने के लिए अच्छी या बुरी प्रोग्रामिंग प्रैक्टिस है? उदाहरण के लिए, अगर मुझे एक साथ शब्दों का एक गुच्छा प्रिंट करने की आवश्यकता है, तो मुझे गुस्सा टाइपिंग आएगा

<< " " <<

एक कूट कथन में शब्दों के बीच एक स्थान सम्मिलित करने के लिए। मैं बस कर सकता था

#define pSpace << " " <<

और प्रकार

cout << word1 pSpace word2 << endl;

मेरे लिए यह न तो कोड की स्पष्टता से जोड़ता है या घटाता है और टाइपिंग को थोड़ा आसान बनाता है। ऐसे अन्य मामले हैं जो मैं सोच सकता हूं कि टाइपिंग बहुत आसान होगी, आमतौर पर डिबगिंग के लिए।

इस पर कोई विचार?

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


74
यह आपके लिए स्पष्ट है क्योंकि आपने इसका आविष्कार किया है। हर किसी के लिए यह सिर्फ obfuscated। पहले तो यह एक वाक्यविन्यास त्रुटि की तरह दिखता है। जब यह संकलित करता है तो मुझे लगता है कि क्या बिल्ली है और फिर पाते हैं कि आपके पास एक मैक्रो है जो सभी कैप में नहीं है। मेरी राय में, यह कोड को बनाए रखने के लिए भयानक बना देता है अगर मैं कोड समीक्षा के लिए आया तो मैं निश्चित रूप से इसे अस्वीकार कर दूंगा और मुझे उम्मीद नहीं है कि आपको ऐसे कई मिल जाएंगे जो इसे स्वीकार करेंगे। और आप 3 अक्षर सहेज रहे हैं !!!!!!!!!
मार्टिन यॉर्क

11
जहाँ आप कार्य या किसी भी चीज़ का उपयोग करके पुनरावृत्ति को उचित रूप से प्रभावित नहीं कर सकते हैं, बेहतर तरीका यह सीखना है कि आपका संपादक या IDE आपकी सहायता के लिए क्या कर सकता है। टेक्स्ट-एडिटर मैक्रोज़ या "स्निपेट" हॉटकीज़ आपको पठनीयता को नुकसान पहुँचाए बिना इतना टाइप करने से बचा सकते हैं ।
स्टीव 314

2
मैंने पहले भी (बॉयलरप्लेट के बड़े हिस्से के साथ) ऐसा किया है, लेकिन मेरा अभ्यास कोड लिखना था, फिर प्रीप्रोसेसर चलाना, और प्रीप्रोसेसर आउटपुट के साथ मूल फ़ाइल को बदलना। मुझे टाइपिंग से बचाया, मुझे (और अन्य) रखरखाव की परेशानी से बचाया।
TMN

9
आपने 3 पात्रों को बचाया और उन्हें भ्रमित करने वाले बयानों के लिए व्यापार किया। खराब मैक्रो का बहुत अच्छा उदाहरण,
इम्हो

7
कई संपादकों के पास इस परिदृश्य के लिए एक उन्नत विशेषता है, इसे "कॉपी एंड पेस्ट" कहा जाता है
क्रिस बर्ट-ब्राउन

जवाबों:


111

कोड लिखना आसान है। कोड पढ़ना कठिन है।

आप एक बार कोड लिखें। यह वर्षों तक रहता है, लोग इसे सौ बार पढ़ते हैं।

पढ़ने के लिए कोड का अनुकूलन करें, लिखने के लिए नहीं।


11
मैं 100% सहमत हूं। (वास्तव में, मैं यह उत्तर स्वयं लिखने जा रहा था।) कोड एक बार लिखा जाता है, लेकिन इसे दर्जनों, सैकड़ों, या यहां तक ​​कि हजारों बार, शायद दर्जनों द्वारा, सैकड़ों द्वारा, या हजारों डेवलपर्स द्वारा भी पढ़ा जा सकता है। कोड लिखने में लगने वाला समय पूरी तरह से अप्रासंगिक है, केवल एक चीज जो इसे पढ़ने और समझने का समय है।
sbi

2
प्रीप्रोसेसर को पढ़ने और बनाए रखने के लिए कोड के अनुकूलन के लिए इस्तेमाल किया जा सकता है।
एसके-लॉजिक

2
और यहां तक ​​कि अगर यह सिर्फ एक या दो साल में कोड पढ़ रहा है: आप इन चीजों को बीच में अन्य चीजें करते हुए खुद को भूल जाएंगे।
जोहान्स

2
"हमेशा इस तरह से कोड करें जैसे कि आपका कोड बनाए रखने वाला व्यक्ति एक हिंसक मनोरोगी होगा जो जानता है कि आप कहां रहते हैं।" - (मार्टिन गोल्डिंग)
डायलन यागा

@ डायलन - अन्यथा, कुछ महीनों तक उस कोड को बनाए रखने के बाद, वह आपको मिल जाएगा - (मुझे)
स्टीव ३१४

28

व्यक्तिगत रूप से, मैं इसे घृणा करता हूं। इस तकनीक से लोगों को हतोत्साहित करने के कई कारण हैं:

  1. संकलन-समय पर आपके वास्तविक कोड परिवर्तन महत्वपूर्ण हो सकते हैं। अगला लड़का साथ आता है और यहां तक ​​कि उसके #define या फ़ंक्शन कॉल में एक समापन ब्रैकेट भी शामिल होता है। कोड के एक निश्चित बिंदु पर जो लिखा गया है, वह पूर्व-प्रसंस्करण के बाद वहां क्या होने वाला है।

  2. यह अपठनीय है। यह आपके लिए स्पष्ट हो सकता है .. अभी के लिए .. अगर यह सिर्फ एक परिभाषा है। यदि यह एक आदत बन जाती है, तो आप जल्द ही दर्जनों #defines के साथ समाप्त हो जाएंगे और खुद को ट्रैक करना शुरू कर देंगे। लेकिन सबसे बुरी बात, कोई और नहीं समझ पाएगा कि word1 pSpace word2वास्तव में इसका क्या मतलब है (बिना #Define देखे)।

  3. यह बाहरी उपकरणों के लिए एक समस्या बन सकता है। कहते हैं कि आप किसी तरह #define के साथ समाप्त होते हैं जिसमें एक समापन ब्रैकेट शामिल होता है, लेकिन कोई खोलने वाला ब्रैकेट नहीं होता है। सब कुछ अच्छी तरह से काम कर सकता है, लेकिन संपादकों और अन्य उपकरणों में function(withSomeCoolDefine;अजीबोगरीब (जैसे, वे त्रुटियों और व्हाट्सएप की रिपोर्ट करेंगे) जैसे कुछ देख सकते हैं । (इसी तरह का उदाहरण: एक परिभाषित के अंदर एक फ़ंक्शन कॉल - क्या आपके विश्लेषण उपकरण इस कॉल को खोजने में सक्षम होंगे?)

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


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

16

इस पर मेरा मुख्य विचार यह है कि मैं कोड लिखते समय एक नियम के रूप में "टाइपिंग को आसान बनाने" का उपयोग कभी नहीं करता।

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

इस प्रकार, आपके द्वारा उपयोग किया जाने वाला #define वैकल्पिक <<और अन्य सामान के सामान्य तरीके को तोड़ देता है । यह कम से कम आश्चर्य के नियम को तोड़ता है, और IMHO एक अच्छी बात नहीं है।


1
+1: "कोड को अधिक बार परिमाण के एक क्रम में पढ़ा जाता है कि यह लिखा गया है" !!!!
जियोर्जियो

14

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

ऐसा कहने के बाद, मैं वास्तविक दुनिया के उदाहरण दूंगा कि मैं मैक्रों के अच्छे समावेश को क्या मानता हूं।

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

#include <cppunit/extensions/HelperMacros.h>

class ComplexNumberTest : public CppUnit::TestFixture  
{
    CPPUNIT_TEST_SUITE( ComplexNumberTest );
    CPPUNIT_TEST( testEquality );
    CPPUNIT_TEST( testAddition );
    CPPUNIT_TEST_SUITE_END();

 private:
     Complex *m_10_1, *m_1_1, *m_11_2;
 public:
     void setUp();
     void tearDown();
     void testEquality();
     void testAddition();
}

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

ये मैक्रो ब्लॉक कुछ इस तरह से विस्तार करते हैं:

public: 
  static CppUnit::Test *suite()
  {
    CppUnit::TestSuite *suiteOfTests = new CppUnit::TestSuite( "ComplexNumberTest" );
    suiteOfTests->addTest( new CppUnit::TestCaller<ComplexNumberTest>( 
                                   "testEquality", 
                                   &ComplexNumberTest::testEquality ) );
    suiteOfTests->addTest( new CppUnit::TestCaller<ComplexNumberTest>(
                                   "testAddition",
                                   &ComplexNumberTest::testAddition ) );
    return suiteOfTests;
  }

जिसे आप पढ़ना और बनाए रखना पसंद करेंगे?

एक अन्य उदाहरण Microsoft MFC फ्रेमवर्क में है, जहाँ आप संदेशों के लिए कार्य करते हैं:

BEGIN_MESSAGE_MAP( CMyWnd, CMyParentWndClass )
    ON_MESSAGE( WM_MYMESSAGE, OnMyMessage )
    ON_COMMAND_RANGE(ID_FILE_MENUITEM1, ID_FILE_MENUITEM3, OnFileMenuItems)
    // ... Possibly more entries to handle additional messages
END_MESSAGE_MAP( )

तो, वे कौन सी चीजें हैं जो "गुड मैक्रोज़" को भयानक बुरी तरह से अलग करती हैं?

  • वे एक कार्य करते हैं जिसे किसी अन्य तरीके से सरल नहीं किया जा सकता है। दो तत्वों के बीच अधिकतम निर्धारित करने के लिए मैक्रो लिखना गलत है, क्योंकि आप टेम्पलेट पद्धति का उपयोग करके समान प्राप्त कर सकते हैं। लेकिन कुछ जटिल कार्य हैं (उदाहरण के लिए, सदस्य कार्यों के लिए संदेश कोड को मैप करना) जो कि C ++ भाषा सिर्फ सुंदर तरीके से नहीं संभालती है।

  • उनके पास एक अत्यंत सख्त, औपचारिक उपयोग है। इन दोनों उदाहरणों में मैक्रो को मैक्रो शुरू करने और समाप्त करने की घोषणा की जाती है, और इनबॉइट मैक्रोज़ केवल इन ब्लॉकों के अंदर दिखाई देंगे। आपके पास सामान्य सी ++ है, आप संक्षेप में मैक्रोज़ के ब्लॉक के साथ खुद को बहलाते हैं, और फिर आप फिर से सामान्य हो जाते हैं। "दुष्ट मैक्रो" उदाहरणों में, मैक्रोज़ पूरे कोड में बिखरे हुए हैं और असहाय पाठक के पास यह जानने का कोई तरीका नहीं है कि C ++ नियम कब लागू होते हैं और कब नहीं।


5

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

यह अधिक जटिल परिदृश्यों के लिए एक बेहतर समाधान भी हो सकता है, जब टेक्स्ट प्रीप्रोसेसिंग बहुत अधिक अपठनीय और जटिल काम कर सकता है (पैराट्राइज्ड इनपुट के बारे में सोचें)।


2
+1। वास्तव में: संपादक को आपके लिए काम करने दें। यदि आप इसका संक्षिप्त विवरण देते हैं तो आपको दोनों दुनिया के सर्वश्रेष्ठ मिलेंगे << " " <<
unperson325680

-1 के लिए "यह और अधिक जटिल परिदृश्यों के लिए एक बेहतर समाधान हो सकता है, जब पाठ प्रीप्रोसेसिंग बहुत अधिक अपठनीय और जटिल काम कर सकता है (पैराट्राइज्ड इनपुट के बारे में सोचें)" - यदि यह वह जटिल है, तो इसके लिए एक विधि बनाएं, फिर भी, बनाएं इसके लिए एक विधि। उदा। यह बुराई मुझे हाल ही में कोड में मिली ..... # प्रिंट प्रिंट (x) {पुट (x); वापसी x}
Mattnz

@mnnz, मेरा मतलब है कि लूप का निर्माण, अगर / और निर्माण करता है, तो तुलनित्र निर्माण के लिए टेम्प्लेट और इतने पर - उस तरह का सामान बंद। आईडीई में इस तरह के पैराट्राइज्ड इनपुट आपको न केवल कोड की कुछ पंक्तियों को जल्दी से टाइप करने में मदद करते हैं, बल्कि पैरामेट्स के माध्यम से जल्दी से पुनरावृति भी करते हैं। कोई भी तरीकों से मुकाबला करने की कोशिश नहीं करता है। विधि विधि है)))
shabunc

4

दूसरों ने पहले ही समझाया है कि आपको ऐसा क्यों नहीं करना चाहिए। आपका उदाहरण स्पष्ट रूप से मैक्रो के साथ कार्यान्वित होने के लायक नहीं है। लेकिन, आपके पास कई मामले हैं पठनीयता के लिए मैक्रो का उपयोग करने के लिए।

ऐसी तकनीक के एक बुद्धिमान अनुप्रयोग का एक कुख्यात उदाहरण क्लैंग प्रोजेक्ट है: देखें कि .defवहां फ़ाइलों का उपयोग कैसे किया जाता है। मैक्रोज़ के साथ और #includeआप एक समान, कभी-कभी पूरी तरह से घोषित समान परिभाषा के संग्रह के लिए एक परिभाषा प्रदान कर सकते हैं जो कि प्रकार की घोषणाओं में अनियंत्रित हो जाएगा, caseजहां कहीं भी उपयुक्त हो, डिफ़ॉल्ट इनिशियलाइज़र, इत्यादि कथन। यह स्थिरता को काफी बढ़ाता है: आप कभी भी नया जोड़ना नहीं भूलेंगे। उदाहरण के लिए, caseजब आपने एक नया जोड़ा है enum, तो हर जगह बयान ।

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


3

इस तरह #defines का उपयोग करना कभी भी उचित नहीं है। आपके मामले में, आप ऐसा कर सकते हैं:

class MyCout 
{
public:
  MyCout (ostream &out) : m_out (out), m_space_pending (false)
  {
  }

  template <class T>
  MyCout &operator << (T &value)
  { 
    if (m_space_pending)
      m_out << " ";

    m_out << value;
    m_space_pending = false;
    return *this;
  }

  MyCout &operator << (const char *value)
  {
    if (m_space_pending)
      m_out << " ";

    m_out << value;
    m_space_pending = true;
    return *this;
  }

  MyCout &operator << (char *value) { return operator << (static_cast <const char *> (value)); }
  MyCout &operator << (ostream& (*fn)(ostream&)) { m_out << fn; return *this; }

private:
  ostream
    &m_out;

  bool
    m_space_pending;
};

int main (int argc, char *argv [])
{
  MyCout
    space_separated (cout);

  space_separated << "Hello" << "World" << endl;
}

2

नहीं।

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

// These don't compile:

#define pSpace (<< " " <<)
cout << word1 pSpace word2 << endl;

#define space(x) (" " << (x))
cout << word1 << space(word2) << endl;

// These do:

#define FOO_FACTOR (38)
x = y * FOO_FACTOR;

#define foo() (cout << "Foo" << endl)
foo();

#define die(c) { if ((c)) { exit(1); } }
die(foo > 8);

#define space(x) (" " + string((x)))
cout << "foo" << space("bar") << endl;

(एंड्रयू शेफर्ड जवाब में उदाहरण की तरह) घोषणाओं में प्रयोग किया जाता मैक्रो (जैसे के बीच स्विच जब तक नियमों का एक सेट के साथ हारने प्राप्त कर सकते हैं के रूप में वे के बारे में संदर्भ परेशान नहीं है publicऔर private)।


1

एक शुद्ध "सी" कार्यक्रम में करने के लिए यह एक उचित वैध चीज है।

यह C ++ प्रोग्राम में अनावश्यक और भ्रामक है।

C ++ में कोड के दोहराए जाने से बचने के कई तरीके हैं। आपके IDE द्वारा प्रदान की गई सुविधाओं का उपयोग करने से (यहां तक ​​कि vi एक सरल " %s/ pspace /<< " " <</g" टाइपिंग के रूप में ज्यादा बचत करेगा और अभी भी मानक पठनीय कोड का उत्पादन करेगा)। आप इसे लागू करने के लिए एक निजी तरीकों को परिभाषित कर सकते हैं या अधिक जटिल मामलों के लिए C ++ टेम्पलेट एक क्लीनर और सरल होगा।


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

@ सेक्योर - मैं मानता हूं कि दिए गए उदाहरण के मामले में इसका अच्छा विचार नहीं है। लेकिन कमी के खाके आदि को देखते हुए सी में "#DEFINE" मैक्रोज़ के लिए वैध उपयोग हैं
जेम्स एंडरसन

1

C ++ में इसे ऑपरेटर ओवरलोडिंग के साथ हल किया जा सकता है। या यहां तक ​​कि एक साधारण समारोह के रूप में कुछ सरल:

lineWithSpaces(word1, word2, word3, ..., wordn)दोनों सरल है और आपको pSpacesबार-बार टाइप करने से बचाता है ।

तो जबकि आपके मामले में यह एक बड़ी बात की तरह प्रतीत नहीं हो सकता है, एक समाधान है जो सरल और अधिक मजबूत है।

सामान्य तौर पर, ऐसे कुछ मामले होते हैं जहां स्थूल का उपयोग ओफ़्फ़केशन को प्रस्तुत किए बिना काफी कम होता है, और अधिकतर वास्तविक भाषा सुविधाओं का उपयोग करते हुए पर्याप्त रूप से छोटा समाधान होता है (मैक्रोज़ केवल एक स्ट्रिंग स्ट्रिंग प्रतिस्थापन से अधिक है)।


0

इस पर कोई विचार है कि क्या कोडिंग को सरल बनाने के लिए #define का उपयोग करना कोडिंग को सरल बनाने के लिए अच्छी या बुरी प्रोग्रामिंग प्रैक्टिस है?

हां, यह बहुत बुरा है। मैंने भी लोगों को ऐसा करते देखा है:

#define R return

टाइपिंग को बचाने के लिए (जिसे आप प्राप्त करने की कोशिश कर रहे हैं)।

इस तरह के कोड केवल इस तरह के स्थानों में हैं ।


-1

मैक्रोज़ बुराई हैं और इसका उपयोग केवल तब किया जाना चाहिए जब आपको वास्तव में होना चाहिए। कुछ मामले हैं जहां मैक्रोज़ लागू होते हैं (मुख्य रूप से डीबगिंग)। लेकिन ज्यादातर मामलों में C ++ में आप इसके बजाय इनलाइन फ़ंक्शन का उपयोग कर सकते हैं ।


2
नहीं है कुछ भी नहीं किसी भी प्रोग्रामिंग तकनीक में आंतरिक रूप से बुराई। सभी संभावित उपकरण और विधियों का उपयोग किया जा सकता है, जब तक आप जानते हैं कि आप क्या कर रहे हैं। यह कुख्यात पर लागू होता है goto, सभी संभव मैक्रो सिस्टम, आदि के लिए
एसके-लॉजिक

1
इस मामले में बुराई की बिल्कुल यही परिभाषा है: "कुछ ऐसी चीज़ों से बचना चाहिए जो आपको ज़्यादातर से बचनी चाहिए, लेकिन कुछ ऐसी चीज़ों से नहीं जिन्हें आपको हर समय टालना चाहिए"। यह इस लिंक पर समझाया गया है कि बुराई इंगित कर रही है।
15

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

-2

नहीं, आपको टाइपिंग को बचाने के लिए मैक्रोज़ का उपयोग करने की अनुमति नहीं है ।

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

टाइपिंग को कम करने के लिए अधिकांश संपादकों के पास मैक्रोज़, यहां तक ​​कि बुद्धिमान कोड स्निपेट्स भी होते हैं।


"नहीं, आपको टाइपिंग को बचाने के लिए मैक्रोज़ का उपयोग करने की अनुमति नहीं है ।" - अच्छा काम मैं यहाँ आपके आदेश को सुनने नहीं जा रहा हूँ! अगर मेरे पास उन वस्तुओं का ढेर है, जिन्हें मुझे घोषित / परिभाषित / नक्शा / switch/ आदि करने की आवश्यकता है, तो आप शर्त लगा सकते हैं कि मैं पागल होने से बचने के लिए मैक्रो का उपयोग करने जा रहा हूं - और पठनीयता में वृद्धि। कीवर्ड, नियंत्रण प्रवाह और इस तरह के टाइपिंग को बचाने के लिए मैक्रोज़ का उपयोग करना बेवकूफी है - लेकिन यह कहना कि कोई भी उनका उपयोग वैध संदर्भों में कीस्ट्रोक्स को बचाने के लिए नहीं कर सकता समान रूप से असिन है।
अंडरस्कोर_ड
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.