ডেড কোড লেখা কি কার্যকর?

16

আপনি ডেড কোড লেখা দরকারী মনে করেন?

কেউ কেউ বলে "যদি আপনার কাছে কিছু অপারেশন করার জন্য ২ টি লজিক থাকে তবে অন্যান্য লজিক কোড মন্তব্য করার পরিবর্তে বা কোড অপসারণের পরিবর্তে এটিকে ডেড কোড করে দেয় কারণ এটি অপারেশনে প্রভাব ফেলবে না।"

উদাহরণ: -

if(true){
    // logic - 1
} else {
    // logic - 2  // dead code
}

এটা সত্যি?

আমি সাধারণত ডেড কোডগুলি লিখি না পরিবর্তে আমি কেবল দ্বিতীয় যুক্তিটি সরিয়ে ফেলি।

java

— হ্যারি জয়
সূত্র

6

কেন এটি জটিল করে তুলছে। এটি সরিয়ে ফেলুন, কেবল কেআইএসএস

— জিগার জোশী

1

আমি বিন্দুটি দেখতে পাচ্ছি না ...

— ফিল

13

জিনিসগুলির একটি অসীমতা রয়েছে যা আমি আমার প্রোগ্রামটি করতে চাই না। অন্য শাখায় কী রাখবেন তা আপনি কীভাবে সিদ্ধান্ত নেবেন?

— পল কসাই

4

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

— ম্যাট উইলকো

1

কেবল একটি মন্তব্য যে কোডটি অতীতের কোড পরিবর্তনগুলি সংরক্ষণ করার জায়গা নয়। এর জন্য সোর্স কন্ট্রোল।

— ফানকিমশরুম

67

আইএমও, এটি অর্থহীনের চেয়ে খারাপ।

সময় নষ্ট হওয়া ছাড়াও, এটা আপনি (বা পরবর্তী লোক) বিভ্রম যে আপনি কিছু কোড যে যদি আপনি পরিবর্তন কাজ করবে পেয়েছেন দেয় trueকরার false। এটি কেবল একটি বিভ্রম ... যদি আপনি এটি পরীক্ষা না করেন।

এবং যদি অবশ্যই হয়, তবে এটি বিশৃঙ্খলা যা কোডটি আরও কঠিন করে তোলে।

— স্টিফেন সি
সূত্র

7

"অর্থহীন চেয়ে খারাপ" এর জন্য +1। এটি হওয়ার জন্য একটি বাগ অপেক্ষা করছে। এটি জটিলতার সাথে যুক্ত করে যেখানে এটির প্রয়োজন নেই। কোডটি বুঝতে এটি অতিরিক্ত সময় ব্যয় করে।

— ডায়েটবুদ্ধ

13

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

সম্পাদনা:

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

আপনি যদি কোনও চিত্রটি মুছে ফেলতে পারেন যেহেতু এটি "লাইভ" কোড দ্বারা ব্যবহৃত হয় না কেবল ডেড কোড ব্যবহার করে তবে আপনাকে নিজের ডেড কোডটি পরিবর্তন করতে হবে (এবং সম্ভবত সম্ভবত ব্রেক হয়ে যাবে) বা অন্য পদ্ধতিটিকে ডেড কোড নিজেই তৈরি করতে হবে।

শেষ পর্যন্ত আপনি অবশ্যই কোনও রক্ষণাবেক্ষণের নরকের আকারে শেষ হবেন।

সুতরাং, সেরা কোডটি মুছে দেওয়া কোড, যেহেতু এটি কোনও ভুল ফলাফল তৈরি করতে পারে না বা রক্ষণাবেক্ষণকারীদের বিরক্ত করতে পারে না। :)

— টমাস
সূত্র

এটি কীভাবে আপনি জানতে পারবেন যে এটি সংরক্ষণাগারে রয়েছে?

— মাইকেল বর্গওয়ার্ট

@ মিশেল আপনার কাছে সাধারণত ভান্ডার মন্তব্য বা কিছু প্রকারের ডকুমেন্টেশন থাকে যেখানে আপনি সেই কোডটির অস্তিত্ব সম্পর্কে ইঙ্গিত দিতে পারেন।

— থমাস

8

না, এটি খারাপ, কারণ এটি আপনার কোডকে বিশৃঙ্খলা করে এবং রক্ষণাবেক্ষণযোগ্যতা হ্রাস করে।

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

— মাইকেল বর্গওয়ার্ট
সূত্র

4

এটি অপারেশনকে প্রভাবিত করে না তবে এটি রক্ষণাবেক্ষণকে প্রভাবিত করে। আপনি বজায় রাখা আরও সহজ করার জন্য কোডটি যথাসম্ভব পরিচ্ছন্ন রাখতে চান।

— পিটার লরি
সূত্র

4

আপনি যা করছেন তা দ্বারা আমি সত্যই বিভ্রান্ত হয়ে পড়েছি।

অবতরণ অগ্রাধিকারের ক্রম:

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

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

— জ্যাক ভি।
সূত্র

3

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

— গিরিশৃঙ্গ
সূত্র

1

যদি আসলেই খুব বেশি উদ্দেশ্য না থাকে! যদি (সত্য) কার্যকর হয় কোনও অনিঃ

— জ্যাকারি কে

অবশ্যই, এটি সঠিক।

— Alp

3

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

আপনি যদি দুটি কোড বিকল্পের মধ্যে দ্রুত পরিবর্তন করতে সক্ষম হতে চান তবে নীচের সুবিধাজনক মন্তব্য গঠনটি ব্যবহার করতে পারেন:

//*
alternative 1 is active
/*/
alternative 2 is commented out
//*/

আপনি যদি /প্রথম মন্তব্য লাইনে কেবল প্রথমটিকে সরিয়ে ফেলেন তবে তা হয়ে যায়:

/*
alternative 1 is commented out
/*/
alternative 2 is active
//*/

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

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

আপনি এটি এমনকি চেইন করতে পারেন এবং এককভাবে একক চরের সাথে একাধিক ব্লক স্যুইচ করতে পারেন:

//*
first block of code for alternative 1
/*/
first block of code for alternative 2
/*/
second block of code for alternative 1
/*/
second block of code for alternative 2
//*/

আমি এটি এইভাবে ব্যবহার করব না তবে এটি কাজ করে।

— রেভস , 2 জন ব্যবহারকারী 68% x4u
সূত্র

এটি কীভাবে কাজ করে তা বুঝতে আমাকে পেন এবং কাগজ দিয়ে কাজ করতে হয়েছিল। লেখার সময় খুব সুন্দর কৌশল, আমি এটি ব্যবহার করব, তবে পছন্দটি করা হয়ে গেলে অবশ্যই মুছে ফেলা হবে।

— রোমান গ্রাজদান

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

— x4u

1

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

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

— ডেভ
সূত্র

এটিই README ফাইলগুলির জন্য

— উইপকোজন

0

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

— টম জেফেরিজ
সূত্র

0

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

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

— Dysaster
সূত্র

0

আমি অবিলম্বে এমন পরিস্থিতিটি ভাবতে পারি না যেখানে আমি ডেড কোডটি লেখা দরকারী বলে মনে করি। যদি বিকল্প অ্যালগরিদম থাকে তবে:

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

উভয় ক্ষেত্রেই, আপনার কোনও ডেড কোড নেই।

— জোনাথন লেফলার
সূত্র

0

আপনি যদি নিজের মৃত কোডটি মুছতে বা মন্তব্য না করেন তবে সংকলক ত্রুটিগুলি এড়ানোর জন্য আপনাকে এটিকে বজায় রাখতে হবে। এটা সময় নষ্ট। আপনার যদি এসসিএম থাকে তবে এটি মুছুন।

— rockeye
সূত্র

এসসিএম কি এসভিএন এর মতো? যদি না হয় তবে আমাদের এসসিএম নেই। আমাদের এসভিএন আছে।

— হ্যারি জয়

1

এসসিএম মানে সোর্স কোড ম্যানেজমেন্ট ( en.wikedia.org/wiki/Source_Code_Management )। আপনার যদি এসভিএন থাকে তবে আপনার এসসিএম আছে! ;)

এসসিএম বলতে আসলে সফ্টওয়্যার কনফিগারেশন ম্যানেজমেন্ট। আপনার যদি এসভিএন থাকে তার অর্থ আপনার কাছে সংস্করণ নিয়ন্ত্রণ রয়েছে, আপনার এসসিএম আছে কিনা তা অন্য প্রশ্ন।

— সফদভেদ

3

@ প্রতীক: না, এসসিএম এর অর্থ আসলে সফটওয়্যার চেইনসো গণহত্যা। অন্যথায় চিন্তা করা বোকামি। সোর্স কোড ম্যানেজমেন্ট, বা সফ্টওয়্যার কনফিগারেশন ম্যানেজমেন্ট, বা সাপ্লাই চেইন ম্যানেজমেন্টের মতো কোনও সিলাইন নেই। এসসিএম এর আসল অর্থ হ'ল সফটওয়্যার চেইনসো গণহত্যা, পিরিয়ড।

— মিথ্যা রায়ান

সফটওয়্যার চাহিনসো বা সফটওয়্যার গণহত্যা?

— রোমান গ্রাজদান

0

কোন

কিছু প্রোগ্রামার মন্তব্যগুলির বিকল্প হিসাবে এই শৈলীটি ব্যবহার করে এবং এটি মার্জিত বলে মনে করেন।

if (1 == 0) 
{
    std::cout <<"I am a dead code capable of resurrection, once a programmer changes the condition!";
}

— setzamora
সূত্র

0

সহজ উত্তরটি একটি সহজ নম্বর। ডেড কোড বিভ্রান্তি এবং বাগগুলি হওয়ার সুযোগগুলি আকর্ষণ করে। কোডটিতে কোনও চরিত্র টাইপ করার সাথে সাথেই ঝুঁকি রয়েছে। সুতরাং আপনার আর কিছু যুক্ত করবেন না।

একবার যখন আমাকে অনুরূপ কিছু লিখতে হয়েছিল তখন এটি একটি কম্পাইলার বাগের আশেপাশের কাজ হিসাবে ছিল, এটি প্রায়শই এই কাজটি ব্যবহার করার জন্য সংকলক বিক্রেতাকে সুপারিশ করেছিলেন।

— tehnyit
সূত্র

0

আপনি কি লিখেছেন ডেড কোড পরীক্ষা করেন? এটি সম্ভবত ভাল কিনা তা নিশ্চিত করার জন্য কিছু করুন? তা না হলে এ থেকে মুক্তি পান get

ভবিষ্যতের কোড পরিবর্তনের জন্য, আপনি কি ডেড কোডটি এখনও কাজ করে যাচাই করতে যাচ্ছেন? তা না হলে এ থেকে মুক্তি পান get

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

কমেন্ট-আউট কোড রাখার কারণ থাকতে পারে (বা, সি বা সি ++ এ, #ifdefএড আউট কোড) তবে এটি কেন এখনও আছে এবং এটি কী উদ্দেশ্যে কাজ করে তা নিয়ে মন্তব্যের সাথে এই হওয়া উচিত।

— ডেভিড থর্নলি
সূত্র

0

নোট করুন যে জাভাতে, অ্যাক্সেসযোগ্য কোডের কারণে নিম্নলিখিতগুলিও সংকলন করবে না:

int someFunc() {
    return 10;
    int x = 12;
    return x;
}

আদর্শভাবে, যদি আপনার কোডটিতে কোনও সমস্যা থাকে তবে আপনি এটিকে উত্পাদনে না দেওয়া এবং আপনার ব্যবহারকারীদের দ্বারা খুঁজে পাওয়ার চেয়ে এটি যত তাড়াতাড়ি সম্ভব এটি সন্ধান করতে চান।

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

আপনি তর্ক করতে পারেন যে ডেড কোডটি পৌঁছানো যায় না, সুতরাং সমস্যা তৈরি করতে পারে না, তবে মন্তব্য, ব্র্যাকিং এবং ইনডেন্টেশন এ এমন কিছু হতে পারে যা এটি ঘটতে পারে।

— পল কসাই
সূত্র

সি # তে এটি সংকলন করবে তবে একটি সতর্কতা প্রদর্শন করবে।

— মরগান হের্লোকার

0

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

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

— Dyppl
সূত্র

0

এর আরেকটি চেহারা হ'ল মূলত বেশিরভাগ পেশাদার প্রোগ্রামাররা সম্মত হন যে কোডের আকারটি শত্রু। এই ব্লগ পোস্টগুলি একবার দেখুন: স্টিভ ইয়েজের সবচেয়ে খারাপ শত্রু জেফ আতউডের দ্বারা সর্বোত্তম কোড কোনও কোড নয় , আপনি আরও অনেক কিছু খুঁজে পেতে পারেন।

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

— Dyppl
সূত্র

0

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

— সুব শঙ্করা সুব্রমনিয়ান manian
সূত্র

0

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

তাত্ক্ষণিক বার্তাটি "প্যানিক: যেমন ফাইল% s-তে% d লাইনে থাকবে" এমন কিছু বলা উচিত তা অত্যন্ত গুরুত্বপূর্ণ ...

— হ্যাক দেখেছি
সূত্র