আপনার উত্সে অর্থহীন কোড

34

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

পদ্ধতি বা ফাংশন কলগুলি যা মূল্যবোধের কিছুই করে না।

অপ্রয়োজনীয় চেকগুলি পৃথক শ্রেণীর ফাইল, বস্তু বা পদ্ধতিতে সম্পন্ন হয়েছে।

if সবসময় সত্যকে মূল্যায়ন করে এমন বিবৃতি।

থ্রেডস যা স্পিন বন্ধ করে এবং কিছুই নোট করে না।

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

আমার প্রশ্ন। অন্য কেউ কি কোড দেখেছেন? আপনার সিদ্ধান্তে কী ছিল যে কেন কোডটি ছিল?

কারও কাছে যদি এমন কোড লেখা থাকে তবে আপনি কেন শেয়ার করতে পারবেন?

coding-style

— আলী
সূত্র

4

if (false) {...}কোড মন্তব্য করার জন্য ব্লক দুর্দান্ত! </

— arcasm

18

বোকাদের দ্বারা কখনই উপযুক্ত হিসাবে ব্যাখ্যা করা হয় না যা বিশেষত সফ্টওয়্যার বিকাশে যেখানে অস্থায়ী দ্রুত হ্যাক খুব কমই অস্থায়ী হয় mal

— ওয়াইল্ডপিক্স

1

@ dlras2 প্লট টুইস্ট: # ডিফাইন মিথ্যা সত্য :)

— সিলভিউ বুর্কিয়া

17

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

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

— JeffO
সূত্র

2

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

— আলী

18

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

— দ্রুত

1

@ চিকলি_নো জন্য +1। সাধারণত যা ঘটে তা শেষ হয়; এটি ভাঙার ভয়ে ("বা স্বর্গকে নিষেধ করা উচিত, কোডটি আসলে কোড উন্নত করতে আরও বেশি সময় নিতে হবে!" ভয়ের কারণে "যে কাজ করে" এমন কোনও কিছু স্পর্শ করতে প্রত্যেকেই ভয় পান! সুতরাং কোডটি রট এবং পরীক্ষক এবং অবশেষে রাস্তায় অনেক বছর ভেঙে পড়ে।

— ওয়েইন মোলিনা

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

— মিহাইল মালোস্টানিডিস

73

আমি কোডটি এর মতো দেখিনি তবে আমি অন্যান্য কোডের জন্য কোডটি অর্থহীন দেখায় বা অর্থহীন বলে দেখেছি:

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

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

— StasM
সূত্র

22

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

— ব্রুস এডিগার

2

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

— জর্জিও

3

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

— জো

20

আমার প্রশ্ন। অন্য কেউ কি কোড দেখেছেন? আপনার সিদ্ধান্তে কী ছিল যে কেন কোডটি ছিল?

1) হ্যাঁ।

2) আমি যেসব ক্ষেত্রে দেখেছি, সেগুলিতে আমি এটি বিভিন্নভাবে লিখে রাখতাম:

প্রোগ্রামার অনভিজ্ঞ
প্রোগ্রামার একটি বিশেষত জটিল এবং / বা খারাপভাবে সম্পাদিত ডিজাইন যা তিনি সংশোধন করার চেষ্টা করছেন তা বুঝতে পারছেন না
(বলুন) একজন রিফ্যাক্টরের মাঝখানে প্রোগ্রামার বাধাগ্রস্ত হচ্ছে।
অসতর্কতা

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

মান / ভুলগুলি "ব্যবসায়" কে গুরুতরভাবে প্রভাবিত করে যদি আপনি অবশ্যই এই ধরণের ল্যাসেজ-ফায়ার পদ্ধতিকে নিতে পারেন না। তবে সেই পরিস্থিতিতে আপনাকে একটি বিস্তৃত পরীক্ষার পদ্ধতির সাথে মিলিয়ে প্রত্যেকটির বাধ্যতামূলক এবং পরিশ্রমী কোডের পর্যালোচনা প্রয়োজন ।

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

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

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

+1 একটি প্রতিক্রিয়া টাইপ করে যাচ্ছিল এবং আমি উল্লেখ করতে যাচ্ছি এমন সমস্ত কারণের তালিকাভুক্ত দেখতে পেয়েছি।

— কানাডিয়ান

দাতব্য হওয়ার জন্য +1। আঙুলগুলি নির্দেশ না করে কারও ভুলগুলি ঠিক করুন এবং আপনার সহকর্মীরা আপনার প্রযুক্তিগত দক্ষতা এবং আপনার লোক দক্ষতা উভয়কেই সম্মান করবেন। লেখককে ক্রেইপ কোডের জন্য হারানগ করুন এবং আপনার সহকর্মীরা আপনার পদ্ধতির প্রতি বিরক্তি প্রকাশ করবে এবং আপনার দক্ষতা ছাড় করবে।

— কালেব

13

এই সমস্তগুলি প্রায়শই কোনও প্রকল্পের বয়সের লক্ষণ।

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

আমি একটি দৈনিকউটিএফ থেকে এটি মনে করি:

@deprecated // he might have been crazy enough to use reflection...
boolean getTrue() {
    return false; 
}

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

৩. যদি সবসময় সত্যকে মূল্যায়ন করে এমন বিবৃতি statements ওহ, আমি এটি করেছি আমি একবার একটি প্রকল্প পেয়েছি, এটি সম্ভবত 10-15 এর একটি সিরিজ ছিল যদি / অন্য ব্লক করে। আচরণটি পরিবর্তন করতে, আমি কেবল true||প্রথম ব্লকে একটি রেখেছি । কয়েক মাস (বছর?) অবধি পরে আমি ফিরে এসে বললাম, "ওহ, বাহ এই কোডটি ধ্বংস হয়ে যাওয়ার কথা ছিল কিন্তু কখনই হয়নি"

৪. থ্রেডগুলি যা স্পিন করে এবং কিছুই নোট করে না। আমি চিন্তাভাবনার একটি লাইন এভাবে চলে যেতে পারি:

আমি জানি! এই দুটো সমস্যা আমি অসমর্থিতভাবে পরিচালনা করতে পারি! আমি থ্রেড ফু এবং বার তৈরি করব।
(দুই মাস পরে) হুহ, আপনি জানেন, বার থেকে কার্যকারিতা foo এ কিছুটা ভাল। আমি কিছুটা সরে যাব।
(এক বছর পরে) আপনি জানেন, এই অন্য জিনিসটি বার থেকে ফু-তে রাখার অর্থ হয়।
(বহু, বহু বছর পরে) "আরে, এই barথ্রেডটি কিছু করছে বলে মনে হচ্ছে না, আমরা কি এটি মুছে ফেলতে পারি?" "এর চেয়ে ভাল না, এখানে অনেক অনেক বছর রয়েছে ..."

— cwallenpoole
সূত্র

5

"আরও ভাল নয়, এটি অনেকগুলি, বহু বছর ..." এর জন্য +1 - এটি বারবার ঘটে। পরিণতিগুলির ভয়ের কারণে অপসারণের ভয় ("আমরা কীভাবে পরীক্ষা করব যে আমরা কিছু ভাঙ্গেনি" - বিশেষত যদি আশেপাশে কোনও ইউনিট পরীক্ষা না হয়)।

— দ্রুত

11

আমি কিছুটা আশাবাদী। আমি মনে করি আপনি যা বর্ণনা করেছেন তা প্রায়শই ঘটে যখন কোডটি অযত্নে পুনরুদ্ধার করা হয়।

— জোনাথন খু
সূত্র

13

যদিও এটি কঠিন, ম্যালিসকে কখনই বোকা বোকা দ্বারা ব্যাখ্যা করা যায় না।

— ব্রুস এডিগার

8

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

আজকাল আমি সবসময় ধরে নিয়েছি লোকটি কাজটি করার সময় এখনও ভাষা শিখছে । আর সে তাড়াহুড়ো করে চলেছে।

— জেডজেআর
সূত্র

আপনার মুখের তকমা দেওয়ার জন্য আপনার নাক কেটে ফেলার কথা বলুন। আমার ধারণা এটি ঠিক আছে যদি আপনাকে আবার কোডটির দিকে নজর দিতে না হয়।

— জেফও

6

সর্বাধিক উত্তরগুলি এই দুটি সাধারণ সত্যের দিকে ফোটে:
[1] কোড কোডের ইতিহাসকে প্রতিবিম্বিত করে এবং
[2] কোড কোডের প্রত্যাশিত ভবিষ্যতের প্রতিফলন ঘটায়।

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

আমি ইফ-বিবৃতি লিখেছি যে উপস্থিতিতে সর্বদা সত্যকে মূল্যায়ন করে। তবে অতীতে এটি ভুল হতে পারে।

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

— অ্যান্ডি ক্যানফিল্ড
সূত্র

1

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

— অ্যান্ডি

1

যদি (ভাষা = 'এন' বা ভাষা = তম ') - সম্ভবত পরবর্তী মাসে আমরা চীনা চেষ্টা করব? যদি (! isset (ITLE TITLE)) - সমস্ত মডিউলগুলি $ টাইটেল সেট করার জন্য সমর্থন করা হয় তবে কোনও কোনও দিন এটি ভুল বানান করে। যদি (file_exists (AR TARGET)) - ভাল কোডটি ফাইলটি ইতিমধ্যে তৈরি করেছে তবে এটিতে সিস্টেম ত্রুটি রয়েছে এবং এটি তৈরি হয়নি। আমার স্ট্যান্ডার্ড পিএইচপি / মাইএসকিউএল ইন্টারফেস কোড সর্বদা ত্রুটির জন্য পরীক্ষা করে, যদিও আমি এখনও কোনওটি ধরিনি।

— অ্যান্ডি ক্যানফিল্ড

3

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

'পদ্ধতি বা ফাংশন কলগুলি কোনও মূল্য দেয় না' ' এবং 'যদি বিবৃতিগুলি সর্বদা সত্যের কাছে মূল্যায়ন করে' তার কোড সহ একটি বড় সমস্যা।

— DBlackborough
সূত্র

3

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

তারপরে কোড সাফ করার সমস্যা আছে: মৃত কোড বলে মনে হচ্ছে তা সরিয়ে দেওয়ার জন্য কোনও বিশেষ প্রেরণা নেই এবং এটি না করার জন্য প্রচুর উত্সাহ , কারণ আপনি যদি কোডটি পুরোপুরি বুঝতে না পারেন তবে আপনার মূল্যায়ন যে কোডটি "মৃত" হবে ত্রুটিযুক্ত থাকুন, এবং আপনি সিস্টেমটি ভঙ্গ করবেন wind

— স্কট সি উইলসন
সূত্র

2

পদ্ধতি বা ফাংশন কলগুলি যা মূল্যবোধের কিছুই করে না।

অগত্যা খারাপ না। বেস ক্লাসের পদ্ধতিগুলি প্রায়শই খালি পদ্ধতিগুলিকে কল করে যা সাবক্লাসগুলির জন্য ওভাররাইড পয়েন্ট হিসাবে বোঝানো হয়। উদাহরণ: কোকো টাচের ইউআইভিউ-র একটি -didAddSubview:পদ্ধতি রয়েছে যা ডিফল্ট সংস্করণে কিছুই না করে নথিভুক্ত। ইউআইভিউয়ের -addSubview:পদ্ধতিতে কিছু না করা -didAddSubview:সত্ত্বেও কল করতে হবে কারণ সাবক্লাসগুলি এটিকে কিছু করার জন্য প্রয়োগ করতে পারে। যে পদ্ধতিগুলি কিছু না করে এবং সেগুলির কারণগুলি অবশ্যই নথিভুক্ত করা উচিত।

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

অপ্রয়োজনীয় চেকগুলি পৃথক শ্রেণীর ফাইল, বস্তু বা পদ্ধতিতে সম্পন্ন হয়েছে।

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

যদি বিবৃতিগুলি সর্বদা সত্যের কাছে মূল্যায়ন করে।

এর মধ্যে একটি বড় পার্থক্য রয়েছে:

if (1) {
    // ...
}

এবং:

if (foo() == true) {
    // ...
}

যেখানে foo()সর্বদা ফিরে আসে true।

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

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

থ্রেডস যা স্পিন বন্ধ করে এবং কিছুই নোট করে না।

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

— কালেব
সূত্র

1

এটা হয়। বেশিরভাগ সময় আসলে।

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

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

এবং, এটির অনেকগুলি পুরানো কারণে সরাসরি হয় "যদি এটি ভেঙে না যায় তবে এটি ফিট করবেন না।" কখনও কখনও কোড ছিঁড়ে আপনি না বুঝতে পারেন, বা বিশ্বাস করেন নি অব্যবহৃত, "বাটারফ্লাই এফেক্ট" এর প্রোগ্রামিং সংস্করণ তৈরি করতে পারে। একবার বা দু'বারও হয়েছে।

— লুক স্টিভেনসন
সূত্র

1

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

— প্যাট্রিক
সূত্র

0

আমি if trueবিবৃতি নির্বিচারে "অর্থহীন কোড" হিসাবে শ্রেণীবদ্ধ করতে আপত্তি জানাই।

if (1) { ... }সি কোডে একটি ব্লক ব্যবহারের জন্য একটি বৈধ মামলা রয়েছে যা হয় হয় সি স্ট্যান্ডার্ডের সাথে সামঞ্জস্যপূর্ণ হতে চায় যা ভেরিয়েবল সংজ্ঞাগুলির উপর জোর দেয় যে কোনও ফাংশন শুরুর সময় হতে পারে, বা কেবল স্থানীয় ভেরিয়েবলগুলি স্থানীয়ভাবে সম্ভব হিসাবে সংজ্ঞায়িত করা উচিত।

switch (i) {
    case 23:
        if (1) {
            /* I can declare a local var here! */
        }
        break;
}

— ndim
সূত্র

5

'যদি (1)' দরকার নেই, তবে ব্লকটি কেন হবে না?

— ফিগব্যাগ

3

সি / সি ++ এবং সি # উভয়ই, এবং আমি বেশ নিশ্চিত জাভা (পাশাপাশি সম্ভবত আরও অনেক অনুরূপ ভাষাগুলি) বেনামে স্টেটমেন্ট ব্লককে অনুমতি দেয়; একটি if, whileবা অনুরূপ নির্মাণের প্রয়োজন নেই। এটি খুব পরিষ্কার হওয়ার সম্ভাবনা নেই, তবে ভাষা অনুমান অনুসারে এটি অবশ্যই অনুমোদিত।

— একটি সিভিএন

0

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

— ক্যাসি
সূত্র

0

@ অ্যান্ডি যেমন উল্লেখ করেছেন, একটি বড় উপাদান আমি দেখেছি তা হ'ল ইয়াএগএনআই ।

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

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

এখানে অন্য অনেকের মতো, আমি এটি দূষিতভাবে দেখিনি, তবে ভাল ডিজাইনের জ্ঞানের অভাব এবং এটি অন্যের কাছে সেভাবে দেখানোর চেষ্টা করার কারণে। মজার বিষয়, এটি বিকাশকারীরা আরও কম জ্ঞানসম্পন্ন বলে মনে হয় যে তারা এই ক্ষেত্রে আরও ভাল করতে পারে, কারণ কমপক্ষে তাদের কোড অতিরিক্ত মাত্রায় ইঞ্জিনিয়ারড অ্যাড নাসিয়ামের সমাপ্ত হয় না। ( KISS নীতি )

— ম্যাক্সওয়েল
সূত্র