কোডে লাইনের সংখ্যা হ্রাস করা কতটা গুরুত্বপূর্ণ?

85

আমি একটি সফটওয়্যার বিকাশকারী যিনি J2SE (কোর জাভা) এ কাজ করেন।
প্রায়শই আমাদের কোড পর্যালোচনার সময় আমাদের কোডের লাইনের সংখ্যা হ্রাস করতে বলা হয়।

এটি অনর্থক কোড অপসারণের বিষয়ে নয়, এটি এমন একটি স্টাইল অনুসরণ করা যা কোডের কয়েকটি লাইন দিয়ে একই জিনিসগুলি করার বিষয়ে দৃষ্টি নিবদ্ধ করে, আমি লাইন সংখ্যা বাড়ানো মানে এমনকি কোডে স্পষ্টতা অর্জনে বিশ্বাস করি।

আপনি কি মনে করেন যে জিনিসগুলি করার সঠিক উপায়?
যদি এলওসি (কোডের লাইনগুলি) একটি সংখ্যক হয় তবে এটি কোডকে কীভাবে প্রভাবিত করবে? যদি এলওসি একটি বৃহত্তর সংখ্যা হয় তবে কোডটিতে এটি কীভাবে প্রভাব ফেলবে?

ওয়েবসাইট থেকে উদাহরণ: "জাভরঞ্চ" -

public static void happyBirthday(int age)
{  
    if ((age == 16) || (age == 21) || ((age > 21) && (((age % 10) == 0) || ((age % 25) == 0))))        
    {
        System.out.println("Super special party, this year!");
    }
    else
    {
        System.out.println("One year older. Again.");
    }
}

বনাম

public static void happyBirthday(int age)
{

    boolean sweet_sixteen = (age == 16);
    boolean majority = (age == 21);
    boolean adult = (age > 21);
    boolean decade = (age % 10) == 0;
    boolean quarter = (age % 25) == 0;

    if (sweet_sixteen || majority || (adult && (decade || quarter)))
    {
        System.out.println("Super special party, this year!");
    }
    else
    {
        System.out.println("One year older. Again.");
    }
}

— অঙ্কিত
সূত্র

63

আমি কোনও জাভা ফাইলকে একটি একক কোডের কোডে রূপান্তর করতে পারি ( s/\n/ /g) এর অর্থ এই নয় যে এটি এমনকি দূরবর্তীভাবে পাঠযোগ্য হবে

— ratchet freak

6

আপনার সংস্থাটি কী উত্পাদনশীলতা পরিমাপের জন্য এলওসি ব্যবহার করে, তাই তারা তাদের কোডিং মানগুলির সাথে আপনাকে 'সিস্টেম গেমিং' থেকে বিরত করার চেষ্টা করছে?

— জেফো

29

আপনি প্রতিটি শৈলীর একটি সংক্ষিপ্ত উদাহরণ সরবরাহ করতে পারলে এটি সত্যিই সহায়তা করবে (চেরি বাছাই করা হয়নি), তাই আমরা কী সম্পর্কে কথা বলছি তা সম্পর্কে প্রত্যেকের স্পষ্ট। উভয় দিকেই চরম রয়েছে; এবং উত্তরটি আপনার প্রসঙ্গে খুব নির্ভরশীল হতে চলেছে।

— ড্যানিয়েল বি

3

কখনও আপনার ঘরটি পরিষ্কার করুন, তারপরে আপনার মা এসে বললেন "এটি পরিষ্কার নয়" এবং আপনি যে 10 টি জিনিস রেখে দেননি তা নির্দেশ করে। কোড পর্যালোচনায় তারা আপনাকে যা বলছে তা মূলত এটি।

— বিক্রিয়াকারী

11

আপনি যে উদাহরণটি দিয়েছেন তা হ'ল প্রবর্তনযোগ্য পরিবর্তনশীল রিফ্যাক্টরিংয়ের পরিচিতির একটি পাঠ্যপুস্তিকা সংস্করণ , যা সাধারণত পাঠযোগ্যতা এবং অভিপ্রায় বৃদ্ধি করে (যা একটি ভাল জিনিস)। কিছু তর্ক করবে যে আপনার চলকগুলি আরও সংক্ষিপ্ত, এক-লাইন ফাংশনগুলিতে সংশোধন করা উচিত, তবে এটি একে চূড়ান্ত দিকে নিয়ে যাচ্ছে; আমি বলব যে পর্যালোচনা দ্বারা প্রস্তাবিত সংক্ষিপ্ত সংস্করণটির তুলনায় আপনার সংস্করণটিকে পছন্দ করা উচিত।

— ড্যানিয়েল বি

75

পরিমাপের সমস্যাটি, তারা যত ভাল উদ্দেশ্যপ্রাপ্ত তা নির্ধারণ না করেই আইটেমটি পরিমাপ করার বিষয়টি একেবারে গুরুত্বপূর্ণ করে তোলে এবং তাত্পর্যপূর্ণভাবে, কোনও আইটেম পরিমাপ না করার কাজটি গুরুত্বহীন করে তোলে। কোনটি গুরুত্বপূর্ণ তা পরিমাপ করা এবং যা গুরুত্বহীন তা পরিমাপ করা একেবারে প্রয়োজনীয়।

এসএলওসি পরিমাপ (আপনার পর্যালোচনাগুলি কার্যকরভাবে যা করা হয়), এসএলওকে গুরুত্বপূর্ণ করে তোলে .... এসএলওসি গুরুত্বপূর্ণ? - একেবারে হয় নি, কখনও হয় নি (কখনও কখনও বাছাই করা প্রোগ্রামিং প্রতিযোগিতা ) কখনও বাণিজ্যিক প্রতিষ্ঠানে থাকতে পারে না।

নিজেকে একটি সাধারণ প্রশ্ন জিজ্ঞাসা করুন - "এই রুটিনের এসএলওসি হ্রাস" কীভাবে যে কোনও কোডকে আরও উন্নত করে। এই ক্ষেত্রে সম্ভবত যা ঘটছে তা হ'ল এসএলওসি জটিলতা পরিমাপের একটি নিষ্কলুষ উপায় হিসাবে ব্যবহৃত হচ্ছে। আপনার যা কিছু খরচ এড়াতে হবে তা হ'ল মটরশুটি গণনা করা সহজ - যেমন এসএলওসি এর মতো উদ্দেশ্যমূলক পদক্ষেপগুলি গুরুত্বপূর্ণ গণনা না করে বরং গণনা করা শক্ত - যেমন পাঠযোগ্যতা, জটিলতা ইত্যাদি measures

— ম্যাটনজ
সূত্র

33

ওপির পর্যালোচনাটির বিবরণটি কিছুটা অর্থহীন শোনায়, আমি বলব যে কোডগুলির লাইনগুলি প্রায়শই আপনি উল্লেখ করেন এমন কঠোর ব্যবস্থার সাথে সম্পর্কিত। দীর্ঘ ফাংশন প্রায়শই কম পঠনযোগ্য হয় এবং প্রায়শই উচ্চতর সাইক্লোমেটিক জটিলতা থাকে। সুতরাং এটি পর্যালোচনা আসলে কোডটি ব্রেক / সংক্ষিপ্তকরণের প্রস্তাব দিচ্ছে যা এর দ্বারা উপকৃত হবে, বা যদি এটি কেবল একাধিক, বৈধ লাইনগুলিকে অন্তর্ভুক্ত করার পরামর্শ দিচ্ছে তবে এটি সত্যিই নেমে আসে।

— ড্যানিয়েল বি

3

আমি বলব যে কোডের রেখার সংখ্যা হ্রাস করার জন্য গুরুত্বপূর্ণ কারণটি হ'ল একক পৃষ্ঠায় কোনও ফাংশন বেশি দেখতে সক্ষম হওয়া। কোনও পদ্ধতি বা ক্লাসটি স্ক্রোল না করে দেখার পক্ষে যত সহজ, আপনার মাথায় প্রসঙ্গ বজায় রাখা তত সহজ।

— ঝাঁকুনি

2

@ ড্যানিয়েলবি লং ফাংশনগুলি প্রায়শই দীর্ঘ হয় না কারণ কারও মাথা rapেকে রাখা শক্ত হয়; তবে, কারণ তারা একবারে অনেক কিছু করার চেষ্টা করে। উদাহরণস্বরূপ, তারা সাধারণত ইনপুটগুলির বৈধতা দিয়ে শুরু করে, তারপরে কিছু প্রসেসিং, তারপরে বিকল্প প্রসেসিংয়ের জন্য একটি চেক, এরপরে অন্য কোনও চেক অনুসরণ করার পরে এটি দেখার জন্য যে কোনও সম্পর্কহীন কিছু আপডেট করার দরকার আছে, তার পরে একটি অন্তর্নিহিত রুটিন অনুসরণ করা হয় যার মূল ক্রিয়াকলাপের সাথে কোনও সম্পর্ক নেই ( যেমন তারিখ যুক্তি যা মাসের ওভাররন এবং অ্যাডজাস্টগুলি পরীক্ষা করে) এবং আরও অনেক কিছু। আপনি শেষের দিকে যাওয়ার পরে, ক্লাসটির দায়িত্ব কী ছিল তা আপনি মনে করতে পারবেন না।

— এডউইন বাক

1

@ চতুষ্পদ: এটিকে একটি পৃষ্ঠায় ফিট করে প্রসঙ্গ বজায় রাখা এসএলওসি হ্রাস করার খুব খারাপ কারণ। কোডটি যদি ভালভাবে সাজানো থাকে এবং পড়া সহজ হয় তবে অবশ্যই প্রসঙ্গ বজায় রাখা সহজ। - 2500 বা 1000 পিক্সেল একটি "পৃষ্ঠা" কি? আমার প্রতিকৃতিতে একটি 2 * 30 "মনিটর রয়েছে, তবুও মাঝে মাঝে ল্যাপটপে বিকাশ ঘটে

— ম্যাট্নজ

4

অধ্যয়নগুলি (রেফারেন্স এ) LOC === বাগগুলি একটি ডাইম একটি ডজন। এটি একটি সুপরিচিত এবং স্বীকৃত সত্য। যা (আমার জ্ঞানের কাছে) দেখানো হয়নি তা হ'ল (রেফ খ) "কোনও কোড বেসে এলওসি হ্রাস করুন === সেই কোড বেসে বাগগুলি হ্রাস করুন"। এক্সট্রাপোলেটিং (রেফ ক) দাবি করতে (রেফ খ) অবৈজ্ঞানিক। এমন কাগজ প্রকাশ করা যা সম্পর্কের প্রমাণ দেয় বা অস্বীকার করে।

— mattnz

84

আমি আপনার কোড পর্যালোচকদের সাথে একমত, তবে একটি নক্ষত্রের সাথে। আপনার কোডে আপনি যে প্রতিটি বিবৃতি লিখেছেন তা প্রযুক্তিগত দায়বদ্ধতা - এটি সম্ভাব্য ব্যর্থতার পয়েন্ট। যদি আপনি 10 টি স্টেটমেন্ট সহ একটি পদ্ধতি লিখে থাকেন এবং আপনার সহকর্মী এমন একটি লিখেছেন যা 5 টি স্টেটমেন্টের সাথে একই কার্যকারিতা অর্জন করে, তার সমস্যাগুলির সম্ভাবনা দ্বারা পরিমাপ করা হিসাবে তার 'আরও ভাল' হওয়ার সম্ভাবনা রয়েছে (আপনার কোডটি ভুলভাবে দ্বিগুণ জায়গা হতে পারে এমন দ্বিগুণ জায়গায় রয়েছে) জটিল, বা সমস্যাযুক্ত)।

যদিও এখানে তারকাচিহ্ন রয়েছে। এটি ধারণার কোডের আসল সংখ্যা সম্পর্কে নয় কারণ আপনি এমন কিছু দিয়ে লাইনের সংখ্যা হ্রাস করতে পারেন:

void someMethod() {   
 someobject.doSomething(someSingleton.getInstance().with().a().lot().of().law().of().demeter().violations()).and().if().that().werent().enough().theres().more();
}

এটি কোডের এক লাইন, তবে এটি এমন এক জায়গা যেখানে চমকপ্রদ জিনিসগুলি ভুল হতে পারে। তাই আমি বলব সংক্ষিপ্ত বক্তব্যগুলির সাথে সর্বাধিক কাজ করার দিকে মনোনিবেশ করুন - আপনার কাজগুলি করার জন্য যতটা কোড প্রয়োজন তত বেশি কোড লিখুন এবং আরও কিছু করার দরকার নেই। কমপক্ষে, আমি মনে করি এটি আপনার কোড পর্যালোচকরা চালাচ্ছেন।

ব্যক্তিগতভাবে, আমি মনে করি একটি ভারসাম্য আঘাত হানতে হবে। যেমনটি আমি বলেছি, আপনার লেখা প্রতিটি বক্তব্য একটি দায়বদ্ধতা, তবে যদি বর্ণনামূলক নামের সাথে কোনও স্থানীয় ভেরিয়েবল খুঁজে বের করা আপনার পদ্ধতিটিকে আরও পরিষ্কার এবং আরও পাঠযোগ্য করে তোলে তবে তার পক্ষেও একটি মামলা করার দরকার আছে। আমি মনে করি আপনি খুব সহজেই এমন পরিস্থিতিতে পড়তে পারেন যেখানে লোকেরা তুলনামূলকভাবে ছোটখাটো নান্দনিক পার্থক্যগুলি নিয়ে কাঁপছে, তবে সামগ্রিকভাবে, আমি মনে করি আপনার পর্যালোচকদের সঠিক ধারণা রয়েছে - যেগুলি ভুল হতে পারে তার সংখ্যা হ্রাস করার পক্ষে।

— এরিক ডায়েটারিচ
সূত্র

4

সম্মত হন - বক্তব্যের সংখ্যা হ্রাস করা সীমাবদ্ধতার জন্য কার্যকর হতে পারে, তবে কোড পর্যালোচনা যদি বিবৃতিগুলির সংখ্যা হ্রাস করতে চায়, তবে তারা কি "বিবৃতিগুলির কম সংখ্যক" "লাইনগুলির কম সংখ্যক" না বলে বলবে না? কোড "।

— mattnz

1

@ ম্যাটনজ কেবলমাত্র নিশ্চিত হয়ে থাকেন যে তারা পেডেন্টিক হচ্ছে।

— ড্যান নীলি

2

আমার অভিজ্ঞতায় যে কেউ কম বিবৃতিতে একই অ্যালগরিদম লিখতে পারে ক) এমন জিনিসগুলি ব্যবহার করবে যা খুব সাধারণ নয়, বা খুব ভাল বোঝা যায় না, এবং খ) ইউনিট পরীক্ষার প্রয়োজন এমন আরও প্রান্ত-মামলাগুলি প্রবর্তন করতে পারে এবং বাগগুলি প্রবর্তন করতে পারে। এটি অবশ্যই ধরে নিয়েছে যে উভয় প্রোগ্রামারই প্রায় সমানভাবে সক্ষম।

— ড্যানিয়েল এএ পেলসেমেকার

13

হাস্যকরভাবে দীর্ঘ ফাংশন কল চেইনের জন্য +1 এবং তারপরে স্নিগ্ধ ডাবল বন্ধনী violations()।

— জো জেড।

5

100% +1, তাই অনেকে কোড কোডে যোগ করে প্রতিটি অতিরিক্ত বিটের কোডের পরিণতি বুঝতে পারে না, এটি এমন কিছু যা লোকদের সত্যই জেনে রাখা উচিত।

— জিমি হোফা

32

আক্ষরিকরূপে পর্যালোচকদের পরামর্শ গ্রহণ করা কোনও উপকারে আসবে না, কারণ এর সরাসরি ফলস্বরূপ ফলাফলটি ওয়ান-লাইনারকে (লাইন দৈর্ঘ্যের সীমা সত্ত্বেও) প্রচার করে। আমি বিশ্বাস করি যে পাঠটি এখানে শিখতে হবে তা হল, আপনার কোডটি আরও কম কাজ করা ।

অন্য কথায়, এটি সরলতার জন্য একটি কল। এটি বেশ জনপ্রিয় দাবি যে কোডটি একটি দায়বদ্ধতা, সম্পদ নয় , তাই কার্যকারিতা সংরক্ষণের সময় এর পরিমাণ হ্রাস করা একটি মহৎ প্রচেষ্টা। এটি সরাসরি, আরও নিচে থেকে পৃথিবীর পদ্ধতির মাধ্যমে অর্জন করা যেতে পারে যা সমস্যার সরাসরি সমাধান করে এবং সংক্ষিপ্ত সমাধানগুলি পছন্দ করে।

কেন থম্পসনের মতো একবার বলেছিলেন: আমার সবচেয়ে উত্পাদনশীল দিনগুলির মধ্যে একটি ছিল 1000 লাইন কোড ।

— জিয়ন
সূত্র

21

আমি আপনার অবস্থানের সাথে "কোডের মধ্যে স্পষ্টতা থাকা এমনকি যদি এর অর্থ লাইন সংখ্যা বাড়ানো মানে" সাথে একমত হতে চাই।

আমি অনেকগুলি ওয়ান-লাইনার দেখেছি যা মোটামুটি টর্সযুক্ত, তবে তারা কী করছে তা অবিলম্বে প্রকাশিত হয়নি। পঠনযোগ্যতা রাজা হওয়ায় অন্যান্য বিকাশকারীদের আপনার কোড বজায় রাখতে হবে।

আমি যুক্তি দিয়ে বলব যে এর চেয়ে ভাল উদ্দেশ্য লক্ষ্য করা হ'ল সংক্ষিপ্ত পদ্ধতি। কয়েকটি লাইনের কোডের জন্য সংক্ষিপ্ত নয়, তবে সংক্ষিপ্ত কারণ তারা একটি কাজ করে।

— jhewlett
সূত্র

12

আমি বর্তমানে একটি বড় সংস্থার সিনিয়র অ্যাপ্লিকেশন বিকাশকারী এবং প্রকল্প ব্যবসায় বিশ্লেষক হিসাবে কাজ করি এবং আমার বিকাশের লাইন গণনাটি আগ্রহের কেন্দ্র কখনও হয় নি। তবে, আমি বিশ্বাস করি যে কোনও কোড আরও ঘনীভূত হতে পারে, তত ভাল, তবে এটি দ্রুত বিশ্লেষণ করতে এবং সঠিক করতে (বা যুক্ত করতে) সক্ষম হওয়া ব্যয়ে নয়। আমার কাছে, আপনি যখন ব্যবসায়ের সমালোচনামূলক অ্যাপ্লিকেশনটির দায়িত্বে রয়েছেন যে অবিরাম স্ট্যান্ডিং পরিবর্তনের পরিবেশে বিশাল পরিমাণের স্কেল্যাবিলিটি ও ফ্লাই পরিবর্তনে সক্ষম হতে হবে, সংক্ষিপ্ত, সহজ কোড পড়তে সহজ বিকাশের অন্যতম গুরুত্বপূর্ণ উপাদান । এরিক ডিয়েট্রিচের জবাবের কৃতিত্ব , এটি:

void someMethod() {   
someobject.doSomething(someSingleton.getInstance().with().a().lot().of().law().of().demeter().violations()).and().if().that().werent().enough().theres().more();
}

তবে আমার কাছে এটি সম্পূর্ণরূপে অগ্রহণযোগ্য হবে, তবে আমি বিদ্যমান সংস্থাগুলি থেকে সমস্ত সংস্থাকে কোড পরিবর্তন করে দেখতে পেয়েছি:

if (boolean == true){
value.prop = option1;
}
else{
value.prop = option2;
}

প্রতি:

value.prop =  boolean ? option1 : option2;

পাঠযোগ্যতার ত্যাগ না করে এমন একটি দুর্দান্ত কোড কনডেন্সিং পছন্দ ছিল।

এটি কোডকে কীভাবে প্রভাবিত করে? আমি কখনই কোনও পারফরম্যান্স বৃদ্ধি বা হ্রাস লক্ষ্য করেছি না, বলুন, কোডের 100 লাইন। সরল সত্যটি হ'ল এটি যে প্রক্রিয়াটি আপনি সেখানে পৌঁছাতে লাগে তার সংখ্যাগুলির চেয়ে চূড়ান্ত পণ্যটিতে পৌঁছানোর জন্য আপনি আরও বেশি ব্যবহার করেন। আমি দেখেছি বেশ কয়েকটি প্রক্রিয়া খুব ঘনীভূত, যদিও অকার্যকর, আরও ভাল কোড প্রবাহের সাথে দীর্ঘতর কোডগুলির চেয়ে আলাদাভাবে সম্পাদন করে।

— জোশুয়া ভোলারিক্স
সূত্র

আপনার অর্থvalue.prop = boolean ? option1 : option2;

— ক্রিস্টোফার হামারস্ট্রিম

আমি করি! ... যাইহোক 'কনডেন্সড কোড' তে।

— জোশুয়া ভোলারিক্স

2

আপনার দ্বিতীয় উদাহরণটি বিশেষত ভাল, কারণ এটি কেবল সহজ নয়, এটি আরও স্পষ্ট করে তোলে এটি দুটি বিকল্পের একটির একটি কার্যকারিতা, যার কোনও পার্শ্ব প্রতিক্রিয়া নেই। if-then-elseঅস্পষ্ট এই; উদাহরণস্বরূপ, প্রতিটি শাখায় if(যা ভুল হতে পারে বা নাও হতে পারে তবে এটি স্পষ্ট করা শক্ত) এর আলাদা আলাদা ভেরিয়েবলকে নির্ধারণ করা খুব সহজ ।

— আন্দ্রেস এফ

আমি এমন পরিবেশের মুখোমুখি হয়েছি যেখানে টার্নারি অপারেটরটি ব্যবহার করা স্পষ্টভাবে নিষিদ্ধ ছিল। সাধারণত তারা পিএল / এসকিউএল বা জাভার অনুরূপ স্থানান্তরের পরিবেশ ছিল যেখানে লোকেরা ক্ষয়ক্ষতির ভয় পেয়েছিল ... আপনার বক্তব্য হিসাবে আরও কোড লেখার ফলে কোনও কার্যকারিতা প্রভাব নেই, কোডটি কী তা নির্ভর করে হতে পারে। উদাহরণস্বরূপ আপনি যদি কোনও অপারেটরকে কোনও পদ্ধতির কল দিয়ে প্রতিস্থাপন করেন তবে অবশ্যই একটি প্রভাব রয়েছে (এবং এটি মারাত্মক প্রভাবও হতে পারে)।

— w

9

আইএমও, একটি তুচ্ছ এলওসি গণনা দ্বারা কোডের কার্যকারিতা পরিমাপ করা খারাপ ধারণা। সঠিকভাবে ইঞ্জিনিয়ারিং এবং কার্যকর কোড তৈরি করে তা থেকে আরও অনেক কিছু রয়েছে।

আমার অভিজ্ঞতায় কার্যকর কোড:

সলাইডের কোনও নীতি ভঙ্গ করে না
পাঠযোগ্য এবং স্ব-ব্যাখ্যামূলক
আলবার্ট আইনস্টাইনের সরলতার পরীক্ষায় উত্তীর্ণ: "সবকিছুই যতটা সম্ভব সহজ করা উচিত, তবে সহজ নয়।"

— ডাইনো অক্টাভিয়ান
সূত্র

1

আইনস্টাইনের উক্তিটির জন্য +1।

— জাস্টসাল্ট

6

এখানে অনেক উত্তর রয়েছে যেগুলি এলওসিটিকে নীচে রাখার প্রযুক্তিগত উপকার এবং বিপরীতে সম্বোধন করে এবং এটি অর্থবহ মানের মানের সফ্টওয়্যার মেট্রিক কিনা। এই প্রশ্নটি এটাই নয়। এটি কীভাবে পরিচালনার সাথে মোকাবেলা করা যায় তা যে থাম্বের একটি নির্দিষ্ট কোডিং নিয়মের একটি নির্দোষ মতবাদী মেনে চলার জন্য জোর দেয়।

দুর্ভাগ্যক্রমে, লোকেরা উপযুক্ত বিষয়গুলিতে ল্যাচ দেওয়া মোটামুটি সাধারণ বিষয় যা যথাযথ প্রসঙ্গে ব্যবহৃত হয় এবং ব্যবহারিকভাবে প্রয়োগ করা হয়, তাদের সেই প্রসঙ্গটি থেকে বাইরে নিয়ে যান এবং পরামর্শকে প্রথমে প্রশমিত করার ক্ষেত্রে যে বিষয়গুলি রয়েছে সেগুলি প্রশংসা করতে ব্যর্থ হওয়ার সাথে সাথে তাদের কৌতূহলে প্রয়োগ করুন advice ।

এলওসিটিকে নীচে রাখার বিষয়ে পরামর্শের উদ্দেশ্য হ'ল এমন পদ্ধতিগুলি তৈরি করা এড়ানো যা একসাথে খুব বেশি চেষ্টা করার চেষ্টা করে এবং "godশ্বর শ্রেণি" তৈরির নিরুৎসাহিত করা, যা তাদের নকশাকৃত নকশার দিকগুলি সম্পর্কে খুব বেশি জানে প্রত্যক্ষ দায়িত্ব এবং সিস্টেমের অন্যান্য শ্রেণিগুলির উপর নির্ভরশীল। সংক্ষিপ্ত কোডের আরেকটি সুবিধা হ'ল এটি আরও পঠনযোগ্য, যদিও আপনি উল্লেখ করেছেন, আপনি এটিকে অতিরিক্ত মাত্রায় বাড়াতে পারেন যেখানে পাঠযোগ্যতা আসলে ক্ষতিগ্রস্থ হতে শুরু করে।

কম এলওসি গণনা করার সুস্পষ্ট সুবিধা রয়েছে (ছোট পদ্ধতিগুলি বড়দের চেয়ে আপনার মাথার মধ্যে খুব সহজেই ফিট করে, কোডের কম জিনিসগুলির অর্থ ভুল হওয়া খুব কম জিনিস ইত্যাদি), তবে এটি হ্রাসকারী রিটার্নের আইনেরও অধীন। একটি 20 লাইন পদ্ধতিতে একটি 150 লাইন পদ্ধতিতে রিফ্যাক্টর করা 10 লাইন পদ্ধতিটিকে 7 লাইন পদ্ধতিতে রিফ্যাক্টর করার চেয়ে অনেক বড় জয়।

যখন এই ধরনের রিফ্যাক্টরিং ভাল সফ্টওয়্যার ডিজাইন (যেমন পাঠযোগ্যতা) এর অন্য কোনও দিকের ব্যয়ে আসে তখন আপনি এমন একটি পর্যায়ে পৌঁছে গেছেন যেখানে আপনি এটি না করে ন্যায়সঙ্গত করতে পারেন। ভেরিয়েবলগুলি অপসারণ যা কোডের অর্থ কী তার প্রসঙ্গ দেয় এবং তাদেরকে আক্ষরিক সাথে প্রতিস্থাপন করে যা খুব খারাপ কাজ নয়। ভাল কোড এর প্রায় কোনও আক্ষরিক নেই। যাইহোক, এই ভেরিয়েবলগুলি (এবং নামযুক্ত ধ্রুবকগুলি) কোডের লাইন যা সরাসরি প্রোগ্রামে অবদান রাখে না এবং তাই যদি এলওসিকে কোনও ধরণের godশ্বর হিসাবে উপাসনা করা হয় তবে এই জাতীয় স্পষ্টকরণের রেখাগুলি দ্রুত জয়ের জন্য ছাঁটাই করার মহা বিপদে পড়ে এবং কিছু পরিচালনা থেকে বিপথগামী প্রশংসা।

আমি বিশ্বাস করি আপনি এটি উপলব্ধি করার পক্ষে যথেষ্ট স্মার্ট, আসলে এটিই আপনার মূল প্রশ্নের জোরালো। কোড কমানো ভাল এবং কখন তা হয় না তা সমস্যাটি আপনার বোঝার নয়, যা সাধারণভাবে নির্বিচারে যুক্তিসঙ্গত অনুশীলনটি প্রয়োগ করার ক্ষেত্রে সমস্যাবাদ।

আমি আপনার ব্যবস্থাপনার সাথে চ্যাট করতে সময় নেওয়ার পরামর্শ দিচ্ছি, আপনার অবস্থানটি ব্যাখ্যা করে এবং আপনি কেন মনে করেন যে আপনাকে যা করতে বলা হচ্ছে তা কোডকে সহায়তা করার চেয়ে ক্ষতি করে। দ্বন্দ্বমূলক ঘটনা এড়াতে চেষ্টা করুন, তবে এই জাতীয় আলোচনার সময় যুক্তিবাদী এবং শান্ত থাকার চেষ্টা করবেন না। আপনার ম্যানেজমেন্ট বুঝতে পারে যে প্রোগ্রামিং একটি বাস্তববাদী ক্রিয়াকলাপ, এবং সর্বোত্তম অনুশীলনের পরামর্শ কেবলমাত্র যদি ব্যবহারিক উপায়ে প্রয়োগ করা হয় তবে তা কার্যকর। সেরা অনুশীলন কোনও বইয়ে রচনা করা হয়, পাথরে খোদাই করা নয়, এবং যখন এটি দ্বন্দ্ব (সংক্ষিপ্ত কোড বনাম পঠনযোগ্য কোড) তখন প্রোগ্রামারকে তাদের রায়টি প্রয়োগ করতে হবে যে তাদের সেরা অনুশীলনটি অনুসরণ করা উচিত। আশা করি তারা যুক্তিসঙ্গত লোক যারা এর মতো ইনপুটকে প্রশংসা করে।

আপনারও কিছুটা সাহসী হওয়া দরকার কারণ আপনি যদি এলওসি হ্রাস করার জন্য চাপ সৃষ্টি করছেন যেখানে আপনি এটি অপ্রয়োজনীয় বা অনুপযুক্ত মনে করেন তবে স্বাভাবিক জীবন যাপনের জন্য আপনি যেভাবেই পরিবর্তন আনতে পারবেন এটাই স্বাভাবিক। আপনাকে এটি করা থেকে বিরত থাকতে হবে এবং আপনাকে এই সিদ্ধান্তটি "নিজের" করতে হবে। ম্যানেজমেন্ট যুক্তিসঙ্গত এমন পরিস্থিতিতে আপনার তাদের নির্দেশিকাগুলি ঠিকঠাক অনুসরণ করা উচিত নয়, তবে আপনি যে কোনও পরিস্থিতিতে ন্যায্যতা প্রমাণ করতে সক্ষম হবেন।

দুঃখের বিষয়, লোকেরা অযৌক্তিক হতে পারে, বিশেষত যখন লোকেরা তাদের সিদ্ধান্ত এবং তারা আপনার উপর চাপিয়ে দিয়েছিল এমন বিধিগুলি প্রশ্নবিদ্ধ প্রশ্নগুলির নীচে নেমে আসে। তারা যুক্তিযুক্ত না চয়ন করতে পারেন। আপনারও এটির জন্য প্রস্তুত থাকতে হবে। যদি আপনি এমন কেসগুলি প্রদর্শন করতে পারেন যেখানে এলওসি সেরা অনুশীলনটি অন্যান্য সেরা অনুশীলনের সাথে সরাসরি দ্বন্দ্বের মধ্যে আসে এবং কেন পণ্যটি ক্ষতিগ্রস্থ হয়, এবং যদি আপনি কোড বেইসের অংশে এটি করতে পারেন যার জন্য তাদের খুব কম বা কোনও ব্যক্তিগত জড়িত ছিল না (তাই এটি না হয়) তাদের কাজ বা তারা তদারকি করা কাজের উপর ব্যক্তিগত আক্রমণ বলে মনে হচ্ছে না) তবে এটি আপনার যুক্তি আরও বাড়িয়ে তুলতে সহায়তা করতে পারে। আবার আপনাকে শান্ত, যুক্তিযুক্ত উপায়ে নিজেকে ন্যায়সঙ্গত করার জন্য প্রস্তুত থাকতে হবে এবং আপনি যে যুক্তি দিচ্ছেন তার "নিজের" করতে সক্ষম হতে হবে।

আপনার ম্যানেজমেন্টটি যুক্তিসঙ্গত লোকদের সরবরাহ করা হয় তবে তারা আপনার প্রশংসা করতে হবে যে আপনি যা বলছেন তার যোগ্যতা আছে যদি আপনি নিজের দাবিগুলি ব্যাক আপ করতে প্রমাণ সরবরাহ করতে পারেন।

— GordonM
সূত্র

2

আমার মনে হয় আপনার খুব কম সংখ্যক এসএলওসি নিয়ে ফাংশন করার চেষ্টা করা উচিত।

যদি এলওসি (কোডের লাইনগুলি) একটি ছোট সংখ্যা হয় তবে কোডটি কীভাবে প্রভাবিত করে এবং যদি এলওসি একটি বৃহত সংখ্যা হয় তবে কীভাবে কোডটি প্রভাবিত করে?

আদর্শভাবে, 30 টি বোঝার চেয়ে একবারে 8 টি লাইন কোড বোঝা সহজ হওয়া উচিত।

এর অর্থ এই নয় যে 8 টি লাইনে সংকুচিত 30 এলওসি বোঝা সহজ হবে।

আপনি কি মনে করেন যে জিনিসগুলি করার সঠিক উপায়।

সাধারণত কোনও ফাংশনে, আমি এটি বিমূর্তির স্তরের ("এখানে আইও কোড", "বৈধকরণ এখানে", "এখানে গণনা" এবং আরও কিছু করে গ্রুপ করার চেষ্টা করি)।

তারপরে, আমি এটিকে ফাঁকা রেখার দ্বারা পৃথক করে ব্লকগুলিতে ভাগ করব। কোডটি যদি প্রায় দশটি লাইনের বেশি হয় তবে আমি প্রতিটি ব্লককে একটি পৃথক ফাংশনে নিষ্কাশন করি (যেভাবেই কোডটি একাধিকবার প্রদর্শিত হয় তার জন্য আমি তা করি)। আমি এইভাবে পারফরম্যান্স ভাঙ্গার বিষয়ে একটি যুক্তি শুনেছি (অপ্রয়োজনীয় ফাংশন কল) তবে বাস্তবে আমি এর কারণে কোনও পারফরম্যান্স বাধা পাইনি।

এটি বলেছিল, আমি এই নিষ্কাশনটি সম্পন্ন করে ফাংশন করেছি এবং তার পরে ফাংশনটি 40 ডলার লম্বা (সি কোড) ছিল। যদি কোডটি যথাসম্ভব গোষ্ঠীযুক্ত করা হয়, তবে আমি আর দীর্ঘ ফাংশন নিয়ে সমস্যা দেখছি না।

— utnapistim
সূত্র

2

আমি মনে করি LOC এর চেয়ে পরিষ্কার, অটো-ডকুমেন্টেড কোডে ফোকাস করা আরও গুরুত্বপূর্ণ। যদিও আমি আপনার উদাহরণটি সত্যই পছন্দ করি না, কারণ এটি কারণ ছাড়াই কোডটি কী করছে তা ব্যাখ্যা করে। উদাহরণস্বরূপ, এটি:

বুলিয়ান মিষ্টি_সিক্সটিন = (বয়স == 16);

বেশ অপ্রয়োজনীয়। "বয়স == 16" পড়া যে কেউ তা জানে। আমি বরং কোডটি এইভাবে লিখতে চাই:

public static boolean companyShouldThrowABigParty(int age) {
    return (age == 16) || (age == 21) || ((age > 21) && (((age % 10) == 0) || ((age % 25) == 0))); 
}

public static void happyBirthday(int age)
{  
    System.out.println(companyShouldThrowABigParty(age) ? "Super special party, this year!" : "One year older. Again.");
}

কখন পার্টি ফেলবেন সিদ্ধান্ত নেওয়ার যুক্তিটি সিস্টেম.আউট থেকে পৃথক, পরীক্ষা করা যায় এবং এটি বোঝা সহজ। আরও গুরুত্বপূর্ণ বিষয়, যদিও কোডটি পড়ে কেউ বুঝতে পারে যে সেভাবে এটি লেখা হয়েছিল ("সংস্থার লোকদের জন্য একটি বড় পার্টি নিক্ষেপ করতে চায়")।

— এডুয়ার্ডো স্কোজ
সূত্র

2

মিষ্টি ষোলোর তাত্পর্য (এবং বয়স 21) সংস্কৃতি নির্দিষ্ট। "মিষ্টি ষোল" শব্দটি "বয়স == 16" এর চেয়ে বেশি অনুসন্ধানযোগ্য। জন্য যে কারণ, নির্দিষ্ট Booleans করতে তাদের নাম দান সহায়ক হতে পারে। আমি আপনার সাধারণ অনুভূতির সাথে একমত, যদিও: স্ব-ব্যাখ্যামূলক কোড ব্যাখ্যা করতে সময় নষ্ট করবেন না।

— জোনাস কলকার

1

আমি মনে করি কোডের কম লাইন = আরও পঠনযোগ্য কোড

তবে অবশ্যই কিছু সীমাবদ্ধতা রয়েছে, যখন আপনি কেবল কম লাইন পেতে আপনার কোডটিকে ছোট / अस्पष्ट করতে শুরু করেন।

/** Pad a number with 0 on the left */
function zeroPad(number, digits) {
    var num = number+"";
    while(num.length < digits){
        num='0'+num;
    }
    return num;
}

এটি হ্রাসকরণ যুক্তিটি একই থাকে, কেবল কম পাঠযোগ্য। এটি মানুষের দ্বারা করা উচিত নয়, এই সংশোধনটি কোনও মেশিন দ্বারা পড়ার জন্য মেশিন দ্বারা করা হয়।

function zP(e,t){var n=e+"";while(n.length<t){n="0"+n}return n}

আপনি যদি কিছু কোডের টুকরো মুছতে পারেন এবং অ্যালগরিদম এখনও এটি করার কথা বলে যা করছে, ঠিক আছে এগিয়ে যান। কেবল আপনার কোডটি ছোট করবেন না, এটি করার জন্য আরও ভাল সরঞ্জাম রয়েছে।

— Vitim.us
সূত্র

1

আমি মনে করি না কোডের কম লাইন == আরও পাঠযোগ্য কোড। যাইহোক, বাস্তবতা, যা তত্ত্বের থেকে খুব আলাদা, এটি হ'ল প্রচুর সংখ্যক লাইনযুক্ত কোডটি প্রায়শই সঠিক নকশা ছাড়াই লেখা হয়। ফলস্বরূপ, কম লাইনের প্রয়োজন হতে পারে মায়াময় কিছু প্রোগ্রামার যদি তারা সক্ষম হয় তবে আরও ভাল নকশা নিয়ে আসতে বাধ্য করে। মোড় म्हणजे অনেক প্রোগ্রামার হয় না, তারপরে প্রয়োজনীয়তা খুব বেশি সহায়তা করে না।

— zhouji
সূত্র

1

আমি সাধারণ পরিস্থিতিতে একটি সংখ্যা হিসাবে লাইনের সংখ্যা দেখতে পাই না, তবে এটি ইস্যুগুলিতে ইঙ্গিত করতে পারে। যদি কেউ আপনাকে 1000 লাইন কোডের একটি ক্লাস দেখায় তবে ক্লাসটি যেভাবে করা হয়েছে বা ডিজাইন করা হয়েছে তাতে কিছু ভুল হতে হবে।

আপনার উদাহরণটি এমন একটি ক্ষেত্রে ইঙ্গিত করে যেখানে সংখ্যার বৃহত্তর কোডের লাইন বোঝায়। তবে সেটাই উদাহরণ। প্রতিদিন আমি উদাহরণ দেখি যেখানে লাইনের সংখ্যা পরিকল্পনার অভাবে সংযুক্ত থাকে

— IvoC
সূত্র

0

আমি মনে করি, বাস্তব প্রকল্প বাস্তবায়নের চেয়ে কোনও প্রকল্পের শুরুতে এলওসি একটি উপকারী মেট্রিক way প্রতি ফাংশন পয়েন্টে এলওসি জানার ফলে আপনি প্রকল্পের প্রচেষ্টা অনুমান করতে পারবেন এবং সেই থেকে প্রকল্পটি কতটা সময় নেবে এবং বিকাশকারীদের অনুকূল সংখ্যা।

এটি নকশা এবং ভাষার পছন্দকেও প্রভাবিত করতে পারে: ফাংশন পয়েন্টগুলি হ্রাস করা বা একটি কম এলওসি / এফপি দিয়ে কোনও ভাষাতে স্যুইচ করা প্রকল্পের প্রচেষ্টা হ্রাস করা উচিত, অন্য সব কিছুই সমান।

— জেমস জেনসেন
সূত্র

0

কোডের লাইনগুলি নিজেরাই খুব গুরুত্বপূর্ণ নয়। এটি দেখার একটি উপায় গদ্যের সাথে এটির তুলনা করা। প্রথম উপলব্ধি হ'ল কোড এবং গদ্য উভয়ের একটি গুরুত্বপূর্ণ সম্পত্তি (যথার্থতা অনুমান করে) পঠনযোগ্যতা। পঠনযোগ্যতা (এবং বোধগম্যতা) অন্যান্য বৈশিষ্ট্য যেমন রক্ষণাবেক্ষণযোগ্যতা এবং নির্ভুলতার সাথে সহায়তা করে।

অল্প সংখ্যক লাইনে কোনও ফাংশন ফিট করার পক্ষে সুবিধা রয়েছে। তবে অনুচ্ছেদ ছাড়া পাঠ্য থাকা তার স্বচ্ছতা হ্রাস করে। কঠিন ধারণা, কঠিন (বিরল) শব্দ এবং প্রকাশের জটিল উপায়গুলি ব্যবহার একটি ধারণা প্রকাশের জন্য প্রয়োজনীয় শব্দের পরিমাণকে সাধারণত হ্রাস করে তবে একই সময়ে মাধ্যমিক বিদ্যালয় স্তর থেকে পাঠ্য পাঠের স্তরকে পেশাদার একাডেমিকগুলিতে নিয়ে যায় (ইন গদ্যের ক্ষেত্রে)।

সাধারণভাবে এটি আপনার কোডে বিমূর্ততা যুক্ত করতে এবং সহায়তাকারী ইত্যাদি ব্যবহার করতে সহায়ক তবে আবার, এই বিমূর্ততাগুলি অনেকগুলি হয়ে যেতে পারে। কী ঘটতে পারে তা হ'ল জটিলতাটি কোডের অন্য একটি অংশে সরানো। কখনও কখনও, আপনি যখন বিশেষজ্ঞ হিসাবে জুনিয়র প্রোগ্রামারগুলি (বা শিক্ষার্থী) দ্বারা ব্যবহারের জন্য কোনও ফ্রেমওয়ার্ক / লাইব্রেরি ডিজাইন করছেন, এটি করা ভাল ধারণা। তবে জুনিয়ররা আপনার কোডটি কীভাবে কাজ করে তা বোঝাতে সক্ষম হওয়ার আশা করবেন না, কেবল এটির পক্ষে এটি ভুলভাবে ব্যবহার করা খুব কঠিন।

কোড লেখার সময়, বিশেষত আপনার কোডে খালি লাইন যুক্ত করতে দ্বিধা করবেন না। এগুলি অনুচ্ছেদের হিসাবে কাজ করে এবং আপনাকে আপনার ফাংশনের বিভিন্ন অংশ পৃথক করতে সহায়তা করে (এমনকি তাদের এখনও সহায়ক হিসাবে না রাখা উচিত)।

— পল ডি ভ্রিজ
সূত্র

-1

কোড মূল্যায়নের প্রতিটি আনুষ্ঠানিক পদ্ধতিতে দুর্দান্ত সমস্যাটি হ'ল এটি অবশ্যই কোনও কোডে ব্যর্থ হবে। এটি কারণ প্রোগ্রামিং হ'ল এক ধরণের শিল্প এবং এর মতো মূল্যায়নের জন্য পরিষ্কার মান নেই। অবশ্যই এখানে বিভিন্ন ধরণের শিল্প রয়েছে - পেইন্টিংগুলির ব্যাপক উত্পাদনও বিদ্যমান এবং সম্ভবত এই ব্যবসায়টিতে কতগুলি পেইন্ট একটি পেইন্টিংয়ে ব্যয় করা হয় তা গুরুত্বপূর্ণ। :)

— johnfound
সূত্র

-1

পুরোপুরি সত্যি বলতে, আমি এলওসি পরিমাপ সম্পর্কে একটি হুট দিই না। অবশ্যই, কোনও ফাংশন বা প্রক্রিয়া যতটা সম্ভব সংক্ষিপ্ত হওয়া ভাল, তবে আমি দিনের যে কোনও সময় সংক্ষিপ্তভাবে পাঠযোগ্য কোড গ্রহণ করি।

— ভ্লাদিমির কোকজানিক
সূত্র

-2

আমি সম্মত হই যে সর্বদা এলওসি হ্রাস প্রয়োজন একটি কোড পড়তে অসুবিধা হতে পারে।

তবে, আপনার কোডিংয়ের স্টাইলটি খুব ভার্জোজ এবং আপনার পর্যালোচক আরও বেশি সংক্ষিপ্ততর পথটি আরও ভাল বলে মনে করেন। উদাহরণস্বরূপ একটি মন্তব্য যা কেবলমাত্র একটি বিবৃতি ব্যাখ্যা করে যা ভেরিয়েবলের নাম পরিষ্কার করার জন্য মোটামুটি সুস্পষ্ট ধন্যবাদ অকেজো is

— MatthieuW
সূত্র

5

আমি যতদূর জানি, মন্তব্যগুলি এলওসি-তে গণ্য হয় না।

— mhr

1

আপনি ব্যবহার করেন এমন সংজ্ঞা অনুসারে এটি গণনা করে না বা এটি গণনা করে।

— ম্যাথিউডাব্লু

1

মন্তব্যগুলি মন্তব্য। তারা কোড না। সুতরাং তারা এলওসি গণিতে প্রযোজ্য নয়। স্ব-ডকুমেন্টিং কোডটি ভালভাবে মন্তব্য করা কোডের চেয়ে ভাল, কোড থেকে কম মন্তব্যগুলি অপসারণ করা কারও পক্ষে কার্যকর নয়।

— গর্ডনএম

-2

কেবলমাত্র একটি জিনিস যা কোডের পরিমাপের রেখাগুলি এবং সেগুলি আপনার কাছে কোডের রেখার সংখ্যা। অন্য সব কিছু গরম বাতাস, জল্পনা এবং কুসংস্কার।

সংখ্যার কম লাইনের কোড কীভাবে কিছু খারাপ করে তুলতে পারে তার আরও উত্তম উদাহরণ রয়েছে, আরও ভাল নয় তবে একটি মূল বিষয় মনে হয়েছে যে এটি মিস হয়েছে এবং তা হ'ল: এই কাজটি করার জন্য আপনাকে আসলে কতগুলি লাইন দরকার? ?

যদি আপনার কাজটি সম্পাদন করতে 10 লাইনের কোডের প্রয়োজন হয়, তবে তা হয়ে যান, আপনি এটি 10 লাইনেই করুন do যদি এটি সম্পাদন করতে 10,000 টি লাইন প্রয়োজন হয়, তবে একইভাবে এটি হয়ে যান, আপনি এটি 10,000 লাইনে করেন। "কোডের কম লাইনগুলি" এর সংস্কৃতি যদি আপনি এটি 1,000 বা 2,000 বা কিছু যাই না করেন তবে পরবর্তী উদাহরণটিকে আরও ভাল করে তুলবে না। কাজের 10,000 টি লাইনের দরকার ছিল এবং এই 10,000 টি লাইনের মধ্যে বৈধতা, ত্রুটি পরীক্ষা করা, সুরক্ষা ইত্যাদির স্তর অন্তর্ভুক্ত থাকতে পারে যা আপনি যদি এটি খুব কম করে করেন তবে মিস হয়ে যাবে ।

সম্পাদন করা

যেহেতু এটি কয়েকটি নিম্নবিত্ত সংগ্রহ করেছে আমি মনে করি যে আমি এখানে যা বলছি সে সম্পর্কে আমার আরও সুনির্দিষ্ট হওয়া দরকার। প্রথম জিনিস যে কেউ করতে হবে পড়া হয় এই - বিন্দু আমি তোমাকে দূরে থেকে এটা যে উচ্চ পর্যায়ের কোড লিখতে মেশিন কোড যে আসলে মৃত্যুদন্ড কার্যকর করা থেকে সামান্য অথবা কোন প্রতিচ্ছায়া সহ্য করতে পারে জিজ্ঞেস করছি। এই পয়েন্টটির প্রাসঙ্গিকতা হ'ল আসলে নীচে কী হয় তা বোঝা ছাড়াই উচ্চ-স্তরের কোডের উপর ফোকাস হ'ল বিপথগামী।

এখন নিম্নলিখিত বিবেচনা করুন:

কেবলমাত্র একটি লাইনের সাহায্যে খুব খারাপ, ধীর কোড লেখা সম্ভব - আমি সরবরাহিত লিঙ্কের শেষে টার্নারি অপারেটরের মন্তব্যটি নোট করুন।
যদি কোডের একটি লাইন কোনও এপিআই কল করে (বা অন্য কোনও কলকে বাইরের লাইব্রেরিতে কল করে) তবে কী কার্যকর হয় বা এটি কতটা কার্যকর তার উপর সরাসরি নিয়ন্ত্রণের পথে আপনার সংজ্ঞাটি সামান্যই থাকে।
ত্রুটি পরীক্ষা করা, পরিষ্কার করা ইত্যাদিতে সমস্ত কোডের অতিরিক্ত লাইন যুক্ত করে এবং আমি যথেষ্ট নিশ্চিত যে কোডের খুব কম লাইনের সবচেয়ে উত্সাহী ফ্যানও তাদের বিরুদ্ধে তর্ক করবেন না ।

সুতরাং - কোডের লাইনগুলি একটি ভাঙা মেট্রিক। কোডের কম লাইনগুলি অতিরিক্ত পারফরম্যান্সের গ্যারান্টি দেয় না - API API বা লাইব্রেরি কলটি একটি লাইন এবং আপনার নিয়ন্ত্রণের বাইরেও হতে পারে। কোডের কম লাইনগুলি অতিরিক্ত দৃust়তার গ্যারান্টি দেয় না - ত্রুটি পরীক্ষা করা এবং ক্লিনআপ সর্বদা অতিরিক্ত লাইনগুলির প্রয়োজন হবে। কোডের কম লাইনগুলি অতিরিক্ত পাঠযোগ্যতা বা রক্ষণাবেক্ষণের গ্যারান্টি দেয় না - এটি জানতে আপনাকে কেবল আইওসিসি'র দিকে নজর দেওয়া দরকার ।

সুতরাং কোড গ্যারান্টি কম লাইন কি করে? কোডের কম লাইন, এগুলি সবই।

10,000 এর তুলনায় 2 হাজার লাইনে একই কাজ করার দিকে মনোনিবেশ করা গুরুতর ভুল। পরিবর্তে যে কোডটি কাজ করে তার উপর ফোকাস করুন, এটি শক্তিশালী, যা গ্রহণযোগ্য সহনশীলতার মধ্যে সঞ্চালিত হয় এবং এটি পড়া এবং এগিয়ে যাওয়া বজায় রাখা আরও সহজ। কখনও কখনও এর অর্থ আপনি স্বল্প এলওসি কাউন্টে এটি করতে পারেন , কখনও কখনও এর অর্থ এটি আপনাকে উচ্চতর এলওসি গণনায় করতে হয়, তবে এলওসি গণনাটি এখানে গুরুত্বপূর্ণ যা হওয়া উচিত নয়।

— mh01
সূত্র

1

সংজ্ঞা অনুসারে , যদি কোনও কার্য সম্পাদনের জন্য কোডের এন লাইনগুলি পুরোপুরি প্রয়োজন হয় (যা প্রথম স্থানে নির্ধারণ করা কিছু কঠিন) তবে এটি এন লাইনের চেয়ে কম ক্ষেত্রে করা যাবে না। সুতরাং আপনার 10,000-লাইনের কাজটি 2,000, পিরিয়ডে করা যাবে না। আমার ধারণা, ওপি এমন কিছু ক্ষেত্রে কথা বলছে যেখানে কিছুটা অব্যাহতি রয়েছে, অর্থাৎ "প্রয়োজনীয়তা যে কোনও উপায়েই পুরোপুরি সম্পাদন করা যায়, তবে কোনটি ভাল?"

— আন্দ্রেস এফ

-3

কোডে লাইনের সংখ্যা হ্রাস করা কতটা গুরুত্বপূর্ণ? বেশিরভাগ ক্ষেত্রে, না। আসলে, বেশিরভাগ ক্ষেত্রে, জটিল অপারেশনগুলিকে আরও পাঠযোগ্য পদক্ষেপে বিভক্ত করে কোডের লাইন সংখ্যা বাড়ানো আরও গুরুত্বপূর্ণ, এবং প্রতিটি পদক্ষেপে মন্তব্য করার পাশাপাশি কোডটিকে অন্যের দ্বারা আরও পঠনযোগ্য এবং এক্সটেনসিবল করার জন্য মন্তব্যগুলি যুক্ত করে দেওয়া আপনার পরে আসা বিকাশকারীরা।

— Infin8Loop
সূত্র

1

সব ডাউনভোটস কেন?

— মার্কো

হ্যাঁ, কেন একটি নিখুঁত বুদ্ধিমান উত্তর হ্রাস করা হয়েছিল? কেন অন্যান্য নিখুঁত বুদ্ধিমান উত্তর ছিল, এগুলির সমস্তই এই ধারণাকে চ্যালেঞ্জ করেছিল যে কোডের হ্রাস করা লাইনগুলি নিজেই একটি শেষ, নিম্নচালিতও?

— ম্যাক্সিমাস মিনিমাস

1

@ mh01 আমি অনুমান করছি কারণ এর বেশিরভাগটিই ভুল? বিশেষত,

in most cases, it is more important to increase the number of lines of code by breaking out complex operations into more readable steps

আমার অভিজ্ঞতা মোটেই নয়। কমপ্লেক্স কোডটি প্রায়শই এটিকে আরও ছোট এবং সরল করে আরও পঠনযোগ্য এবং কম বগিযুক্ত করা যায়, কারণ এটি এমন কোনও ব্যক্তির দ্বারা লেখা থেকে জটিল হয়ে উঠেছে যিনি ভাষায় নতুন ছিলেন / সমস্যায় নতুন ছিলেন / তারা কী করছেন তা নিশ্চিত নয়।

— ইজকাটা

-5

পূর্ববর্তী সময়ে এটি ধরে নেওয়া হয়েছিল যে কোডের লাইনের লকের সংখ্যা যদি বড় হয় তবে কোড কার্যকর হয় এবং এটি যে সমস্ত কার্য সম্পাদন করে তা সম্পাদন করে তবে কিছুক্ষণ পরে উপলব্ধি হয়েছিল যে কম লোকটি এটিই বেশি কোডটি কার্যকর করার ক্ষেত্রে সিস্টেমের ব্যয়টি খুব কম হওয়ায় দক্ষতা রয়েছে the সিস্টেম লোকের উন্নতির জন্য লোকস কম করা উচিত then তবে এটি ধরে নেওয়া হয়েছিল যে লোক শোল কম হবে o সুতরাং নিম্নলিখিত বিষয়গুলি হ্রাস করতে আমলে নেওয়া উচিত।

আপনার সমস্যার একটি ফ্লোচার্ট তৈরি করুন
আপনি যতটা পারেন লুপের সংখ্যা কম ব্যবহার করার চেষ্টা করুন
ফাংশন কলগুলি বেশি হওয়া উচিত নয়
ট্রাইয়ের মতো নতুন ডেটা স্ট্রাকচার এমন ক্ষেত্রে ব্যবহার করা উচিত যেখানে প্রাসঙ্গিক তথ্য সংরক্ষণের জন্য স্ট্যাক বা সারি ব্যবহৃত হয়।
এবং যেখানে আপনি খুব বড় অ্যারেতে প্রচুর সংখ্যক স্টোর করছেন এবং তারপরে অ্যারের মাধ্যমে এটি অ্যাক্সেস করার চেষ্টা করছেন তা কল্পনাপ্রসূত হওয়ার চেয়ে বাস্তববাদী পদ্ধতির সাথে সমস্যাটি সমাধান করার চেষ্টা করুন]]
যতটা সম্ভব ম্যাক্রো ব্যবহার করুন আরও ব্যবহারের পদ্ধতিটি সমস্যার উপরও নির্ভর করে। যদি এটি সত্যিই জটিল হয় তবে কখনও কখনও সাধারণ পদ্ধতির ব্যবহারও জটিলটির সমতুল্য হয় is

— বিভূ তিওয়ারি
সূত্র

5

-১: বাহ! আমি মনে করি আপনার উত্তরে এলওসি হ্রাস করতে হবে! এটা পড়তে আমার চোখের ব্যাথা!

— জিম জি

1

@ জিমজি: আমি সম্মত হই যে উত্তরটি আমার চোখে আঘাত পেয়েছে তবে আমি মনে করি এটি এলওসি (যেমন প্রতিটি সংখ্যাযুক্ত আইটেমের জন্য পৃথক লাইন ব্যবহার করে) বাড়িয়ে সবচেয়ে ভাল সমাধান করা হয়েছে।

— ব্রায়ান

তালিকাটি পরিস্থিতি নিরাময়ের আগে একটি ফাঁকা লাইন প্রবেশ করানোতে এটি অটোফর্মেটরের দোষ ছিল

— বালোগ পাল