क्या मैं अब "स्तंभित" कोड के लिए छोटे चर नामों का त्याग करता हूं?

17

मैं सीएस प्रोग्रामिंग में एक शौकिया प्रोग्रामर हूं जो उचित प्रोग्रामिंग कौशल सीखने की कोशिश कर रहा है। मेरा कोड कैसा दिखता है, इसके किनारों का विस्तार 103 स्तंभों तक है।

int extractMessage(char keyWord[25], char cipherText[17424],
                   int rowSize, char message[388]) 
{
    int keyColumn    = 0;
    int cipherColumn = 0;
    int offset       = 1;
    int nextWord     = 1;

    int lengthOfWord   = 0;
    int lengthOfCipher = 0;

    lengthOfWord = length(keyWord);
    lengthOfCipher = length(cipherText);


    while (keyWord[keyColumn] != cipherText[cipherColumn]) {
        cipherColumn++;
        if (keyWord[keyColumn + offset] != cipherText[cipherColumn + (rowSize*nextWord) + nextWord]) {
            cipherColumn++;
            continue;
        }
    }

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

c coding-style

— RaulT
स्रोत

26

बढ़ा चल; अधिक उपयोगी नाम जोड़ें । क्या आप cipherColumn + (rowSize*nextWord) + nextWordइसका वर्णन करने के तरीके के बारे में सोच सकते हैं जो यह स्पष्ट करता है कि उदाहरण के लिए गणना क्या है ? मैं शर्त लगाता हूं कि गणना की तुलना में यह नाम छोटा है, इसलिए आपको एक पठनीयता और कम लाइन की लंबाई मिलती है । इसके अलावा असाइनमेंट्स को संरेखित न करें, या आपको सबसे लंबे चर का नाम बदलने पर उन सभी को स्थानांतरित करना होगा।

— जोंशरशेप

2

हम्म .. तो क्या आप कह रहे हैं कि मुझे एक नया वैरिएबल बनाना चाहिए और सिफरक्लूमी + (rowSize * nextWord) + नेक्वर्ड के रिजल्ट को स्टोर करना चाहिए ताकि मैं इसे आगे इस्तेमाल कर सकूं? यह है कि पेशेवरों क्या करते हैं? मैं वास्तव में पूछ रहा हूँ

— राउल्ट

8

हाँ, यह मेरा सुझाव है। मैं एक समर्थक हूँ और यह वही है जो मैं करूँगा, इसलिए ... उनमें से कुछ, कम से कम।

— जोंशरशेप

11

सुनहरा नियम कोड लिखना है जिसे पढ़ा और समझा जा सकता है। हम अन्य लोगों के लिए कोड लिखते हैं (!) मशीनों के लिए नहीं। मशीनों के लिए मशीन कोड है। कुछ के लिए, ऐसा कोड जो आपको वर्णित है (एकल अक्षर नाम आदि) दिखता है, अन्य प्रोग्रामर के लिए सम्मान की कमी है (और भविष्य में - क्योंकि आप अगले कुछ हफ्तों या महीनों में भूल जाएंगे)। 80 स्तंभों से चिपके रहने का कोई कारण नहीं है, यह 80 के दशक में एमएस डॉस नहीं है।

— रास

3

@stijn हां, लेकिन यह आखिरी बार है जब हमें इसकी जरूरत थी। जैसे मैं 8-बिट 8086 प्रोसेसर के लिए अपने सी कोड को संकलित नहीं करता हूं, अगर मुझे इसे पंच कार्ड पर संग्रहीत करने की आवश्यकता है, तो मुझे भी नहीं लगता कि 21 वीं शताब्दी में 80 स्तंभों के गोल्डन स्टारडार्ड का कोई महत्व है। हमें इस तकनीक को फैलाना चाहिए, 80 के दशक में नहीं बैठना चाहिए और यह सोचना चाहिए कि यह हमें चतुर हैकर बनाती है। चतुरता सादगी, पठनीयता और प्रौद्योगिकी को अधिकतम करने के लिए है। हमारे पास पूर्ण-एचडी मॉनीटर हैं, इसका उपयोग करने का समय है।

— रास

24

आम तौर पर जब मुझे आपके जैसे यहां पोस्ट किए गए कोड दिखाई देते हैं, तो मैं इसे संपादित करता हूं, क्योंकि हम क्षैतिज स्क्रॉल से नफरत करते हैं। लेकिन जब से यह आपके प्रश्न का हिस्सा है, मैं आपको यहाँ संपादित दिखाऊंगा:

int extractMessage(char keyWord[25], char cipherText[17424],
                   int rowSize, char message[388]) 
{
    int keyColumn    = 0;
    int cipherColumn = 0;
    int offset       = 1;
    int nextWord     = 1;

    int lengthOfWord   = 0;
    int lengthOfCipher = 0;

    lengthOfWord = length(keyWord);
    lengthOfCipher = length(cipherText);


    while (keyWord[keyColumn] != cipherText[cipherColumn]) {
        cipherColumn++;
        if (keyWord[keyColumn + offset] 
        != cipherText[cipherColumn + (rowSize*nextWord) + nextWord]) {
            cipherColumn++;
            continue;
        }
    }
}

यही कारण है कि ब्रेक चौंकाने वाली हो सकती है, लेकिन यह क्षैतिज स्क्रॉल के साथ संस्करण की तुलना में अधिक पठनीय है, और यह करने के लिए नामों को छोटा करने की तुलना में बेहतर है i, jऔर k।

ऐसा नहीं है कि आप का उपयोग कभी नहीं करना चाहिए नहीं है i, jहै, और k। 3 नेस्टेड forछोरों को अनुक्रमित करते समय वे ठीक नाम हैं । लेकिन यहां नाम वास्तव में मेरे एकमात्र सुराग हैं कि आप क्या होने की उम्मीद करते हैं। खासकर जब से यह कोड वास्तव में कुछ भी नहीं करता है।

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

लाइन की लंबाई कभी भी नाम की लंबाई तय नहीं करनी चाहिए । अगर आपको ऐसा लगता है तो अपना कोड बिछाने का एक अलग तरीका खोज लें। आपके पास ऐसा करने के लिए हमारे पास कई उपकरण हैं।

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

int calcCipherColumn(char keyWord[25], char cipherText[17424],
                     int rowSize, char message[388]) 
{
    int keyColumn    = 0;
    int cipherColumn = 0;
    int offset       = 1;
    int nextWord     = 1;

    int lengthOfWord   = 0;
    int lengthOfCipher = 0;

    lengthOfWord = length(keyWord);
    lengthOfCipher = length(cipherText);

    while (keyWord[keyColumn] != cipherText[cipherColumn]) {
        cipherColumn++;
        if (keyWord[keyColumn + offset] 
        != cipherText[cipherColumn + (rowSize*nextWord) + nextWord]) {
            cipherColumn++;
            continue;
        }
    }
    return cipherColumn;
}

वहां, अब यह कुछ करता है।

अब जब यह कुछ करता है, तो मैं देख सकता हूं कि मैं क्या छुटकारा पा सकता हूं। यह लंबाई सामान भी इस्तेमाल नहीं किया है। यह continueकुछ भी नहीं करता है।

int calcCipherColumn(char keyWord[25], char cipherText[17424],
                     int rowSize, char message[388]) 
{
    int keyColumn    = 0;
    int cipherColumn = 0;
    int offset       = 1;
    int nextWord     = 1;

    while (keyWord[keyColumn] != cipherText[cipherColumn]) {
        cipherColumn++;
        if (keyWord[keyColumn + offset] 
        != cipherText[cipherColumn + (rowSize*nextWord) + nextWord]) {
            cipherColumn++;
        }
    }
    return cipherColumn;
}

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

int calcCipherColumn(char keyWord[25], char cipherText[17424],
                     int rowSize, char message[388]) 
{
    int keyColumn = 0;
    int cipherColumn = 0;
    int offset = 1;
    int nextWord = 1;

    while (keyWord[keyColumn] != cipherText[cipherColumn]) {
        cipherColumn++;
        if (keyWord[keyColumn + offset] 
        != cipherText[cipherColumn + (rowSize*nextWord) + nextWord]) {
            cipherColumn++;
        }
    }
    return cipherColumn;
}

हाँ, मुझे पता है कि यह थोड़ा कम पठनीय है, लेकिन अन्यथा आप उन लोगों को पागल कर देंगे जो परिवर्तनों का पता लगाने के लिए vdiff टूल का उपयोग करते हैं।

अब हम इन मूर्खतापूर्ण लाइन ब्रेक को ठीक करते हैं जो हमारे पास हैं क्योंकि हम लाइन की लंबाई सीमा के तहत रहने की कोशिश कर रहे हैं।

int calcCipherColumn(
        char keyWord[25], 
        char cipherText[17424],
        int rowSize, 
        char message[388]
) {
    int keyColumn = 0;
    int keyOffset = 1;

    int nextWord = 1;
    int cipherColumn = 0;
    int cipherOffset = (rowSize * nextWord) + nextWord;

    char key = keyWord[keyColumn];
    char keyNext = keyWord[keyColumn + keyOffset];

    while (key != cipherText[cipherColumn]) {
        cipherColumn++;
        if (keyNext != cipherText[cipherColumn + cipherOffset]) {
            cipherColumn++;
        }
    }
    return cipherColumn;
}

वहां, अब लूप में तर्क ध्यान केंद्रित करता है कि लूप में क्या परिवर्तन होता है। वास्तव में, सिवाय सब कुछ cipherColumnचिह्नित किया जा सकता है final। और हे! उसे देखो। हमारे पास अब यह करने के लिए जगह है।

मैंने किया था 3 और चर जोड़ने के लिए, एक का नाम बदलें, और उन्हें थोड़ा पुनर्व्यवस्थित करें। और नतीजा यह हुआ कि लाइनों को इतना छोटा कर दिया गया कि वह बिना किसी मूर्खतापूर्ण लाइनब्रेक के फिट हो गई !=।

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

मैंने आपको लाइन लंबाई प्रतिबंधों का सम्मान करने के लिए इनपुट मापदंडों को बिछाने के लिए जेफ ग्रिग के फॉर्म 6 संस्करण शैली को दिखाने की स्वतंत्रता भी ली ।

— candied_orange
स्रोत

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

— राउल्ट

1

@RaTT आपके काम करने वाले कोडबेस को पढ़ने में कुछ समय बिताता है। यह आपको एक विचार देगा कि आप क्या उपयोग कर सकते हैं जो आपके कोडर्स को आश्चर्यचकित नहीं करेगा। यदि आपके पास एक है तो एक मानक दस्तावेज़ का पालन करें। लेकिन सबसे अच्छा यह है कि साथी प्रोग्रामर से पूछें और उनसे पूछें कि आपका सामान कितना पठनीय है। ओह, और बाहर की जाँच करें codereview.stackexchange.com

— candied_orange

मैं सिफरऑफसेट के नीचे एक टिप्पणी जोड़ूंगा और गणना की व्याख्या करूंगा क्योंकि वह सूत्र स्पष्ट नहीं है। आप भूल जाएंगे कि तीन सप्ताह में क्यों।

— नेल्सन

15

दूसरों ने पहले से ही कुछ उपयोगी सुझाव दिए हैं, मुझे संक्षेप में बताएं:

80 के दशक में 80 वर्ण प्रति पंक्ति एक सुनहरा नियम हो सकता था। आजकल ज्यादातर लोग इस बात से सहमत हैं कि 100 से 130 अक्षर ठीक हैं।
अपने भावों के अंदर लाइनब्रेक का प्रयोग करें।
मध्यवर्ती परिणामों की शुरुआत करके लंबा लंबा विभाजन।

मुझे एक और सिफारिश जोड़ना पसंद है: लंबे नामों के बारे में हठधर्मिता न करें! एक चर का दायरा जितना बड़ा होता है, उतनी ही अधिक जानकारी उसके नाम में डालनी होती है। और आम तौर पर चर का दायरा छोटा रखना एक अच्छा विचार है।

उदाहरण के लिए, यदि आपके पास अपनी कीवर्ड एन्क्रिप्शन तालिका के कॉलम के लिए एक चर है और यह स्पष्ट है कि आपके चर के दायरे में केवल एक ही तालिका का उपयोग किया गया है, तो इसे कॉल करना columnया यहां तक कि ठीक है col। यदि स्कोप बड़ा है और इसमें कई टेबल शामिल हैं, तो इसे कॉल करने के लिए समझ में आता है keyWordEncryptionTableColumn।

एक अन्य उदाहरण: यदि आपके पास दो या तीन पंक्तियों में फैले हुए शरीर के साथ एक लूप है और किसी ऐरे के तत्वों तक पहुंचने के लिए एक इंडेक्स का उपयोग करना है, तो इंडेक्स को कॉल करने में कुछ भी गलत नहीं है i। इस संदर्भ में, यह कहना (अधिक से अधिक लोगों के लिए) कम से कम पठनीय है arrayIndexOfMyVerySpecialDataSet।

— फ्रैंक पफर
स्रोत

1

मैं आपके उत्तर से सहमत हूं। काम पर हम विरासत के कारण c / c ++ के लिए 80 char / line का उपयोग करते हैं और क्योंकि हम reviewboard का उपयोग करते हैं। सी # 100 चार्ट / लाइन के लिए, कभी-कभी मैंने नियम को तोड़ दिया और पठनीयता बनाए रखने के लिए 100 से थोड़ा अधिक चला गया।

— पीवल

वाह, क्या शानदार जवाब !! ये सभी जवाबदेह बहुत अच्छे रहे हैं, मेरी मदद के लिए धन्यवाद!

— राउल्ट

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

— कैट

1

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

— कैट

जब भी आप सरल चर नामों का उपयोग करते हैं, तो आपको 100% निश्चित होना चाहिए। मैंने जावास्क्रिप्ट बंद करने के बारे में जानने के लिए तीन घंटे बिताए।

— नेल्सन

3

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

रूपरेखा के बारे में:

ExtractMessage(char keyWord[25], char cipherText[17424],
               int rowSize, char message[388])

यह बिना किसी उद्देश्य के काम करता है, बस लाइन की लंबाई को सीमित करने से यह अधिक पठनीय नहीं बनता है। यदि आप चाहते हैं कि यह पठनीय हो, तो यह करें:

ExtractMessage(
  char keyWord[25],
  char cipherText[17424],
  int rowSize,
  char message[388]
  )
{

और फिर आप प्रकार पहचानकर्ताओं को संरेखित करना भी चाह सकते हैं (int के बाद एक स्थान जोड़ें)। हालाँकि, इस तरह से टीकाकरण या तर्क सूची की रूपरेखा के साथ सावधान / प्रतिबंधात्मक रहें:

int keyColumn    = 0;
int cipherColumn = 0;
int offset       = 1;
int nextWord     = 1;

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

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

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

— मार्टिन मात
स्रोत

1

व्यक्तिगत रूप से आपके उत्तर में पहला कोड ब्लॉक दूसरे की तुलना में मेरे लिए अधिक पठनीय है।

— माइल्स राउत

1

तीसरा कभी न करें, यह इसे बनाए रखने के लिए एक रखरखाव दुःस्वप्न है।

— jwenting

3

अस्वीकरण: मैं अपनी बात को स्पष्ट करने के लिए यहाँ थोड़ा अतिशयोक्ति कर रहा हूँ। तो नमक के एक दाने के साथ किसी भी अतिशयोक्ति को लें।

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

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

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

आपके प्रश्न का हिस्सा नहीं है, लेकिन मैं वैसे भी इस पर टिप्पणी करना चाहता हूं: अपने =ऑपरेटरों को लंबवत रूप से संरेखित करना बहुत बुरा विचार है ।

उसके तीन कारण हैं:

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

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

चूंकि संरेखण किसी भी अर्थ का अर्थ नहीं रखता है, लेकिन महत्वपूर्ण लागतों का उत्पादन करता है, इससे पहले कि आप किसी भी अधिक समय की लागत से पहले इस आदत को अनजान करें।

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

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

— cmaster - मोनिका को पुनः स्थापित करना
स्रोत

3

प्रोग्रामिंग वातावरण में सीमाओं के कारण वर्षों से कई शैलीगत परंपराएं (नियम नहीं!) उछलीं। पंच-कार्ड के दिनों में, आपने ए उन वर्णों की संख्या की कठिन सीमा थी जो एक भौतिक स्रोत रेखा पर दिखाई दे सकते थे (यही वजह है कि फोर्ट्रान ने लाइन-निरंतरता वर्णों के लिए कॉलम 6 आरक्षित किया था)। ऐसा नहीं था कि कई दशक पहले मैं 80x24 एम्बर-ऑन-ब्लैक VT220 टर्मिनल पर काम कर रहा था; जब मैंने संपादकों को 80 वर्णों तक सीमित नहीं किया था, तो जीवन बहुत आसान था यदि आपने क्षैतिज स्क्रॉलिंग से बचने की पूरी कोशिश की।

फोरट्रान (अप '77 के लिए, IINM) के पुराने संस्करणों के अंतर्गत, आप भी नहीं कर सकता है identifers कि अधिक से अधिक 6 से 8 वर्ण लंबा थे। 80 के दशक के उत्तरार्ध में भी, सी केवल गारंटी देता है कि बाहरी नामों में पहले 8 अक्षर सार्थक थे (यही वजह है कि कुछ पुस्तकालय कार्यों में आश्चर्यजनक रूप से वर्णनात्मक नाम जैसे हैं strpbrk)।

बेशक, 21 वीं सदी में दो दशक, हमारे पास अब वे सीमाएँ नहीं हैं। अधिक वर्णनात्मक पहचानकर्ताओं का उपयोग न करने का कोई कारण नहीं है।

बात सही संदर्भों में, है, iऔर jऔर kकर रहे हैं पूरी तरह से उचित, सार्थक नाम । यदि मैं किसी सरणी या वेक्टर के माध्यम से लूप में पुनरावृत्ति कर रहा हूं और मुझे वर्तमान तत्व की पहचान करने के लिए कुछ चाहिए, तो iपूरी तरह से अच्छी तरह से काम करता है। मैं किसी नाम का उपयोग नहीं करूंगा currentElement- यह उस संदर्भ में अधिक सार्थक नहीं है , और यह सिर्फ दृश्य अव्यवस्था जोड़ता है।

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

— जॉन बोडे
स्रोत

-1

मुझे यकीन नहीं है कि यह सी के लिए काम करता है या नहीं, लेकिन क्या कई लाइनों में सूत्रों को विभाजित करने का एक तरीका है? मुझे पता है कि अजगर के लिए ऐसा कुछ मौजूद है।

देखें कि क्या आप शुरू कर सकते हैं + (पंक्तिबद्ध करें * नेक्स्टवर्ड) + नेक्स्टवर्ड]) {एक नई लाइन पर। (जैसे अपनी IDE में एंटर दबाएं और देखें कि क्या यह इंडेंट करता है इसलिए C को पता है कि पिछली अभिव्यक्ति को वर्तमान लाइन पर पूरा किया जा रहा है)

— क्रियो
स्रोत

1

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

— राउल्ट

5

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

— रोमन रेनर

कोई भी फ़ंक्शन जो 50 पंक्तियों के करीब पहुंच रहा है, संभवतः बहुत लंबा और बहुत जटिल है, (1 की जटिलता के साथ डेटा आरंभीकरण के संभावित अपवाद के साथ), लेकिन आमतौर पर जब इस तरह की सीमा पर चर्चा की जाती है तो वे कोड की पंक्तियां होती हैं न कि पाठ की लाइनें एक ही बंटवारे की। कोड की लाइन, यानी अर्धविराम अक्सर एक अतिरिक्त लाइन के रूप में नहीं गिना जाएगा, प्रो के साथ जांचें!

— स्टीव बार्न्स ने