কোন ক্ষেত্রে কম কোড ভাল হয় না? [বন্ধ]

Question

আমি ইদানীং কাজের সময়ে কিছু কোড রিফ্যাক্টর করেছি এবং আমি ভেবেছিলাম আমি ভাল কাজ করেছি did আমি 980 কোডের কোডটি 450 এ নামিয়ে দিয়েছি এবং ক্লাসের সংখ্যা অর্ধেক করে রেখেছি।

আমার সহকর্মীদের কাছে এটি দেখানোর সময় কেউ সম্মত হননি যে এটি ছিল উন্নতি।

তারা বলেছিল - "কোডের কম লাইনগুলি প্রয়োজনীয়ভাবে আরও ভাল নয়"

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

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

Comments

কোডের আকারটি এমন সময়ে পরিমাপ করা হয় যখন আপনি এটি পড়তে এবং বুঝতে প্রয়োজন, লাইন বা অক্ষরের সংখ্যা নয়।

— বার্গি

আপনার প্রশ্ন হিসাবে লিখিতভাবে স্পষ্টভাবে খুব ব্রড হয়। পরিবর্তে আপনি যে নির্দিষ্ট পরিবর্তনগুলি করেছেন সে সম্পর্কে একটি নতুন লেখার পরামর্শ দিন।

— jpmc26

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

— ম্যাকিয়েজ পাইচোটকা

আপনার প্রশ্নের উত্তর দেওয়ার জন্য উত্সর্গীকৃত একটি পুরো স্ট্যাক এক্সচেঞ্জ সাইট রয়েছে: কোডগল্ফ.স্ট্যাকেক্সেক্সঞ্জ.কম । :)

— ফেডারিকো পোলোনি

এর সম্ভাব্য সদৃশটি কোন পর্যায়ে ব্রেভিটি আর পুণ্য নয়?

— বব টিওয়ে

Answer 1

একটি পাতলা ব্যক্তি অতিরিক্ত ওজনের ব্যক্তির চেয়ে স্বাস্থ্যকর নয়।

একটি 980 লাইনের শিশুদের গল্প 450 লাইনের ফিজিক্স থিসিসের চেয়ে পড়া সহজ।

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

উদাহরণস্বরূপ, এটি কোডের সামগ্রিক দৈর্ঘ্য হ্রাস করার সময় - আপনি অতিরিক্ত অযাচিত জটিলতা প্রবর্তন করেছিলেন এবং কোডটিকে আরও রহস্যময় করেছেন।

ক্ষুদ্র পদ্ধতিতে একটি দীর্ঘ টুকরো কোড বিভক্ত করা যেমন ক্ষতিকারক হতে পারে ততটা উপকারী হতে পারে ।

আপনার রিফ্যাক্টরিং প্রচেষ্টা কেন একটি অনাকাঙ্ক্ষিত ফলাফল এনেছে বলে তারা মনে করে সে সম্পর্কে আপনাকে নির্দিষ্ট প্রতিক্রিয়া সরবরাহ করতে আপনার সহকর্মীদের জিজ্ঞাসা করুন।

Comments

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

— এম এ হানিন

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

— এম এ হানিন

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

— এসি

কারণ এটি প্রয়োজনীয় নয় তার অর্থ এটির মূল্য নেই।

— ক্রিস ওহলার্ট

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

— কোড_ড্রেড

Answer 2

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

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

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

Comments

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

Answer 3

অ্যালবার্ট আইনস্টাইনকে প্রায়শই দায়ী করা একটি উক্তি মনে পড়ে:

যতটা সম্ভব সবকিছু সহজ করুন, তবে সহজ নয়।

আপনি যখন ছাঁটা জিনিসগুলিতে ওভারবোর্ডে যান, কোডটি পড়া আরও জটিল করে তোলে। "পড়তে সহজ / কঠিন" যেহেতু খুব সাবলীল শব্দ হতে পারে, আমি এর দ্বারা আমি কী বোঝাতে চাই ঠিক তা ব্যাখ্যা করব: একজন দক্ষ বিকাশকারী "এই কোডটি কী করে?" বিশেষ উত্সের সাহায্য ব্যতীত কেবল উত্সটি দেখে।

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

যদি আমি বলি var x = 2 + 2;, এটি অবিলম্বে সুস্পষ্ট যে xএটি পূর্ণসংখ্যা হিসাবে গণ্য হবে। তবে যদি আমি বলি var foo = value.Response;, এটি কীভাবে fooপ্রতিনিধিত্ব করে বা এর বৈশিষ্ট্য এবং ক্ষমতা কী তা সম্পূর্ণ পরিষ্কার less সংকলক সহজেই এটি অনুমান করতে পারে, এটি একটি ব্যক্তির উপর অনেক বেশি জ্ঞানীয় প্রচেষ্টা রাখে।

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

Comments

varউদাহরণস্বরূপ সরলীকরণ একটি বিশেষ করে ভালো কারণ সময় পড়া অধিকাংশ এবং কোড বুঝতে বিমূর্ততা একটি নির্দিষ্ট পর্যায়ে আচরণ figuring আউট জড়িত থাকে, তাই নির্দিষ্ট ভেরিয়েবল প্রকৃত ধরনের বুদ্ধিমান সাধারণত কিছু পরিবর্তন করে না (এটি শুধুমাত্র আপনাকে নিম্ন বিমূর্ততা বুঝতে সহায়তা করে)। এর চেয়ে ভাল উদাহরণ হ'ল সহজ কোডের একাধিক লাইনগুলি একটি একক সংশ্লেষিত বিবৃতিতে স্কোয়াশ করা হয় - উদাহরণস্বরূপ if ((x = Foo()) != (y = Bar()) && CheckResult(x, y)) আঁকতে সময় লাগে, এবং এর প্রকারগুলি জেনে xবা yসামান্যতম ক্ষেত্রে সহায়তা করে না।

— বেন কটরেল

Answer 4

লম্বা কোডটি সম্ভবত পড়া সহজ হতে পারে। এটি সাধারণত বিপরীত হয়, তবে প্রচুর ব্যতিক্রম রয়েছে - তাদের মধ্যে কয়েকটি অন্যান্য উত্তরে বর্ণিত।

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

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

Comments

'Pecritenc' এর জন্য +1 এবং প্রিফ্যাক্টরিংয়ের পূর্বে পূর্বনির্ধারিত হওয়া উচিত এমন প্রাক্সনাল আপত্তিগুলির একটি খুব সুন্দর সংক্ষিপ্তসার summary

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

— ড্যারেন রিঞ্জার

এছাড়াও, প্রশ্নযুক্ত কোডটি সমালোচনামূলক কোড নাও হতে পারে, তাই এটি পরিষ্কার করার জন্য ইঞ্জিনিয়ারিং সংস্থানগুলির অপচয় হিসাবে বিবেচিত হয়।

— এরিক tদ

@ নোকমপ্রেন্ডে কোনও কারণ আপনি যুক্তিসঙ্গত, পূর্বনির্ধারিত এবং প্রিফ্যাক্টরিং ব্যবহার করেছেন? Pecritenc অনুরূপ পদ্ধতি সম্ভবত?

— মিলিন্দ আর

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

Answer 5

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

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

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

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

Comments

"পিতামহী ক্লাস"! Haw Haw! শুধু অ্যাডাম এবং ইভ ক্লাসে নজর রাখুন। (এবং অবশ্যই Godশ্বর শ্রেণি) এর আগে, এটি বিন্যাস এবং অকার্যকর ছিল।

Answer 6

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

সুতরাং,

enum OPTION1 { OPTION1_OFF, OPTION1_ON };
enum OPTION2 { OPTION2_OFF, OPTION2_ON };

void doSomething(OPTION1, OPTION2);

এর চেয়ে অনেক বেশি ভার্বোজ

void doSomething(bool, bool);

যাহোক,

doSomething(OPTION1_ON, OPTION2_OFF);

এর চেয়ে অনেক বেশি পঠনযোগ্য

doSomething(true, false);

সংকলক উভয়ের জন্য একই কোড উত্পন্ন করা উচিত, তাই সংক্ষিপ্ত ফর্মটি ব্যবহার করে লাভ করার কিছুই নেই।

Answer 7

আমি বলব সংহতি একটি সমস্যা হতে পারে।

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

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

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

Answer 8

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

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

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

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

Answer 9

কম্পিউটার কোডে অনেকগুলি জিনিস করা দরকার। একটি "মিনিমালিস্ট" কোড যা এই জিনিসগুলি করে না তা ভাল কোড নয়।

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

কম্পিউটার কোড "স্কেলেবল" হওয়া উচিত। একটি ক্রিপ্টিক কোড কেবলমাত্র একটি বিশেষায়িত অ্যাপ্লিকেশনের জন্য কাজ করতে পারে, যদিও আরও দীর্ঘ, তবে আরও বেশি ওপেন-এন্ড প্রোগ্রাম নতুন অ্যাপ্লিকেশনগুলিতে যুক্ত করা আরও সহজ করে তুলতে পারে।

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

Comments

দায়িত্ব দর্শকের চোখে পড়ে।

Answer 10

গণনামূলক কর্মক্ষমতা। আপনার কোডের পাইপ-আস্তরণের অনুকূলকরণ বা সমান্তরালভাবে কোড চালনার সময় এটি উপকারী হতে পারে, উদাহরণস্বরূপ 1 থেকে 400 পর্যন্ত লুপ নয়, তবে 1 থেকে 50 পর্যন্ত এবং প্রতিটি লুপে 8 টির মতো কোডের উদাহরণ রেখে ances আমি ধরে নিচ্ছি না যে আপনার পরিস্থিতিতে এটিই ছিল but

Comments

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

— আলেফজেরো

@ এলফজারো বাহ, আমি সেই কোডটি দেখতে পছন্দ করব, এটি অবশ্যই কেবল ক্রে ক্রাই হবে।

@ এলফজারো, ভাল সংকলকগুলি অনেক কিছু করতে পারে তবে দুঃখের বিষয় সমস্ত কিছুই নয়। উজ্জ্বল দিকটি হ'ল সেই বিষয়গুলিই প্রোগ্রামিংকে আকর্ষণীয় রাখে!

— হান্স জানসেন

@ এলএফজারো প্রকৃতপক্ষে, ভাল ম্যাট্রিক্স গুণ গুণটি কেবল কিছুটা সময় শেভ করে না (যেমন এটি একটি ধ্রুবক ফ্যাক্টর দ্বারা হ্রাস করুন), এটি বিভিন্ন অ্যাসিপোটিক জটিলতার সাথে সম্পূর্ণ ভিন্ন অ্যালগরিদম ব্যবহার করে যেমন স্ট্রেসেন অ্যালগোরিদম মোটামুটি ও (এন ^ 2.8) O (n ^ 3) এর চেয়ে বেশি।

— আর্থার ট্যাকা