'ব্যবহার' নির্দেশাবলী নামের জায়গার ভিতরে বা বাইরে থাকা উচিত?

Question

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

usingনাম স্থানের বাইরে নির্দেশের ভিতরে রাখার কোনও প্রযুক্তিগত কারণ আছে কি ?

Comments

: কখনও কখনও এটি পার্থক্য যেখানে আপনি usings করা তোলে stackoverflow.com/questions/292535/linq-to-sql-designer-bug

— gius

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

— চার্লি

@ ব্যবহারকারী -12506 - এটি মাঝারি থেকে বৃহত বিকাশকারী টিমে খুব ভাল কাজ করে না যেখানে কয়েকটি স্তরের কোডের ধারাবাহিকতা প্রয়োজন। এবং পূর্বে উল্লিখিত হিসাবে, আপনি বিভিন্ন লেআউটটি বুঝতে না পারলে আপনি এমন প্রান্তের কেসগুলি খুঁজে পেতে পারেন যা আপনার প্রত্যাশা অনুযায়ী কাজ করে না।

— benPearce

পরিভাষা: সেগুলি using বিবৃতি নয় ; তারা using দিকনির্দেশনা । usingঅন্যদিকে, একটি বিবৃতি একটি ভাষার কাঠামো যা পদ্ধতি পদ্ধতির অভ্যন্তরে অন্যান্য বিবৃতিগুলির সাথে ঘটে থাকে etc. উদাহরণস্বরূপ, using (var e = s.GetEnumerator()) { /* ... */ }একটি বিবৃতি যা আলগাভাবে একই var e = s.GetEnumerator(); try { /* ... */ } finally { if (e != null) { e.Dispose(); } }।

— জেপ্প স্টিগ নীলসন

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

— user1451111

Answer 1

উভয়ের মধ্যে আসলে একটি (সূক্ষ্ম) পার্থক্য রয়েছে। আপনার কল্পনা করুন ফাইল 1 সিএস-এ নিম্নলিখিত কোড রয়েছে:

// File1.cs
using System;
namespace Outer.Inner
{
    class Foo
    {
        static void Bar()
        {
            double d = Math.PI;
        }
    }
}

এখন কল্পনা করুন যে কেউ এই প্রকল্পে অন্য ফাইল (ফাইল2.cs) যুক্ত করেছে যা দেখতে এরকম দেখাচ্ছে:

// File2.cs
namespace Outer
{
    class Math
    {
    }
}

সংকলকটি নেমস্পেসের বাইরের দিকনির্দেশগুলি Outerদেখার আগে অনুসন্ধান usingকরে, সুতরাং এটির Outer.Mathপরিবর্তে এটি সন্ধান করে System.Math। দুর্ভাগ্যক্রমে (বা সম্ভবত সৌভাগ্যক্রমে?), Outer.Mathএর কোনও PIসদস্য নেই, সুতরাং ফাইল 1 এখন ভেঙে গেছে।

আপনি যদি usingনিজের নাম স্থানের ঘোষণার ভিতরে ভিতর রাখেন তবে এটি পরিবর্তন হবে :

// File1b.cs
namespace Outer.Inner
{
    using System;
    class Foo
    {
        static void Bar()
        {
            double d = Math.PI;
        }
    }
}

সংকলক অনুসন্ধানের Systemআগে অনুসন্ধান করে Outer, খুঁজে বের করে System.Mathএবং সবকিছু ঠিকঠাক।

কারও কারও যুক্তি ছিল যে Mathব্যবহারকারী-সংজ্ঞায়িত শ্রেণীর জন্য খারাপ নাম হতে পারে, যেহেতু ইতিমধ্যে একটি রয়েছে System; এখানে বিন্দু শুধু যে হয় একটি পার্থক্য, এবং এটি আপনার কোডের maintainability প্রভাবিত করে।

Fooনেমস্পেসে Outerনা হয়ে কী হয় তা লক্ষ করাও আকর্ষণীয় Outer.Inner। Outer.Mathসেক্ষেত্রে ফাইল 2 এ যুক্ত করা ফাইল 1 কোথায় usingযায় তা নির্বিশেষে ব্রেক করে । এটি সূচিত করে যে সংকলকটি কোনও usingনির্দেশের দিকে নজর দেওয়ার আগে অন্তরঙ্গীয় এনকোলেজিং নামস্থানটি অনুসন্ধান করে ।

Comments

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

— ডেভিড স্মিট

গৃহীত উত্তরটি ভাল, তবে আমার কাছে মনে হচ্ছে এটি ব্যবহারের ধারাগুলি নেমস্পেসের বাইরে রেখে দেওয়া reason যদি আমি নেমস্পেস আউটারে থাকি n তবে আমি আশা করব এটি ম্যাথ ক্লাসটি আউটার থেকে ব্যবহার করবে to

— ফ্রাঙ্ক ওয়ালিস

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

— mbmcavoy

দুর্দান্ত উত্তর, তবে আমার কাছে মনে হচ্ছে যে আমি কেবল স্থানীয়ভাবে বিবৃতি ব্যবহার করে নন-ফ্রেমওয়ার্ক রাখতে চাই এবং বিবৃতিগুলি বিশ্বব্যাপী ব্যবহার করে কাঠামোটি রাখতে চাই। কারোরই আরও ব্যাখ্যা আছে যে কেন আমার পছন্দটি পুরোপুরি পরিবর্তন করা উচিত? এছাড়াও, কোথা থেকে এলো, ভিএস ২০০৮-এ টেমপ্লেটগুলি নেমস্পেসের বাইরে ব্যবহার করে?

— থাইমাইন

আমি মনে করি এটি আপনার ব্যবহারের স্থান পরিবর্তন করার পরিবর্তে একটি খারাপ নামকরণ কনভেনশন বেশি। আপনার সমাধানে ম্যাথ নামে কোনও শ্রেণি থাকা উচিত নয়

— jDeveloper

Answer 2

এই থ্রেডটির ইতিমধ্যে কয়েকটি দুর্দান্ত উত্তর রয়েছে তবে আমি মনে করি এই অতিরিক্ত উত্তর দিয়ে আমি আরও কিছুটা বিস্তারিত আনতে পারি।

প্রথমে মনে রাখবেন যে পিরিয়ড সহ একটি নেমস্পেসের ঘোষণা, যেমন:

namespace MyCorp.TheProduct.SomeModule.Utilities
{
    ...
}

সম্পূর্ণ সমতুল্য:

namespace MyCorp
{
    namespace TheProduct
    {
        namespace SomeModule
        {
            namespace Utilities
            {
                ...
            }
        }
    }
}

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

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

এখন, দুটি প্রধান সম্মেলনের সাথে একটি দৃ concrete় উদাহরণে এর অর্থ কী তা সম্পর্কে স্পষ্ট হয়ে উঠি।

(1) বাইরের usings সহ:

using System;
using System.Collections.Generic;
using System.Linq;
//using MyCorp.TheProduct;  <-- uncommenting this would change nothing
using MyCorp.TheProduct.OtherModule;
using MyCorp.TheProduct.OtherModule.Integration;
using ThirdParty;

namespace MyCorp.TheProduct.SomeModule.Utilities
{
    class C
    {
        Ambiguous a;
    }
}

উপরের ক্ষেত্রে, কী ধরণের Ambiguousতা অনুসন্ধান করতে অনুসন্ধানটি এই ক্রমে চলে যায়:

1. ভিতরে নেস্টেড প্রকারগুলি C(উত্তরাধিকারী নেস্টেড প্রকার সহ)
2. বর্তমান নেমস্পেসে প্রকারগুলি MyCorp.TheProduct.SomeModule.Utilities
3. নেমস্পেসে প্রকারভেদ MyCorp.TheProduct.SomeModule
4. প্রকারভেদ MyCorp.TheProduct
5. প্রকারভেদ MyCorp
6. নাল নেমস্পেসের প্রকারগুলি (গ্লোবাল নেমস্পেস)
7. ধরনের System, System.Collections.Generic, System.Linq, MyCorp.TheProduct.OtherModule, MyCorp.TheProduct.OtherModule.Integration, এবংThirdParty

অন্যান্য সম্মেলন:

(2) ভিতরে usings সহ:

namespace MyCorp.TheProduct.SomeModule.Utilities
{
    using System;
    using System.Collections.Generic;
    using System.Linq;
    using MyCorp.TheProduct;                           // MyCorp can be left out; this using is NOT redundant
    using MyCorp.TheProduct.OtherModule;               // MyCorp.TheProduct can be left out
    using MyCorp.TheProduct.OtherModule.Integration;   // MyCorp.TheProduct can be left out
    using ThirdParty;

    class C
    {
        Ambiguous a;
    }
}

এখন, অনুসন্ধানের Ambiguousধরণটি এই ক্রমে যায়:

1. ভিতরে নেস্টেড প্রকারগুলি C(উত্তরাধিকারী নেস্টেড প্রকার সহ)
2. বর্তমান নেমস্পেসে প্রকারগুলি MyCorp.TheProduct.SomeModule.Utilities
3. ধরনের System, System.Collections.Generic, System.Linq, MyCorp.TheProduct, MyCorp.TheProduct.OtherModule, MyCorp.TheProduct.OtherModule.Integration, এবংThirdParty
4. নেমস্পেসে প্রকারভেদ MyCorp.TheProduct.SomeModule
5. প্রকারভেদ MyCorp
6. নাল নেমস্পেসের প্রকারগুলি (গ্লোবাল নেমস্পেস)

(দ্রষ্টব্য এটি MyCorp.TheProduct"3." এর একটি অংশ ছিল এবং তাই "4" এবং "5" এর মধ্যে প্রয়োজন ছিল না))

মন্তব্য আখেরী

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

এছাড়াও, যদি কোনও নেস্টেড নেমস্পেসের প্রকারের একই নাম থাকে তবে এটি সমস্যা তৈরি করতে পারে।

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

ডিফল্টরূপে ভিজ্যুয়াল স্টুডিওর টেম্পলেটগুলি নাম স্থানের বাইরে usings রাখে (উদাহরণস্বরূপ, যদি আপনি ভিএসকে একটি নতুন ফাইলে একটি নতুন শ্রেণি তৈরি করে থাকেন)।

বাইরের ব্যবহারের একটি (ক্ষুদ্র) সুবিধা হ'ল আপনি তারপরে একটি বিশ্বব্যাপী বৈশিষ্ট্যের জন্য ব্যবহারের দিকনির্দেশগুলি ব্যবহার করতে পারেন, উদাহরণস্বরূপ [assembly: ComVisible(false)]পরিবর্তে [assembly: System.Runtime.InteropServices.ComVisible(false)]।

Comments

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

— জুনটজু

Answer 3

এটিকে নেমস্পেসের ভিতরে রাখলে তা ঘোষণাগুলি ফাইলের জন্য সেই নেমস্পেসে স্থানীয় হয় (ক্ষেত্রে যদি আপনার ফাইলে একাধিক নেমস্পেস থাকে) তবে আপনার যদি প্রতি ফাইলের মধ্যে কেবল একটি নেমস্পেস থাকে তবে তা বাইরে যায় বা না যায় সে ক্ষেত্রে তেমন কোনও পার্থক্য আসে না doesn't নেমস্পেসের ভিতরে।

using ThisNamespace.IsImported.InAllNamespaces.Here;

namespace Namespace1
{ 
   using ThisNamespace.IsImported.InNamespace1.AndNamespace2;

   namespace Namespace2
   { 
      using ThisNamespace.IsImported.InJustNamespace2;
   }       
}

namespace Namespace3
{ 
   using ThisNamespace.IsImported.InJustNamespace3;
}

Comments

নেমস্পেসগুলি দৈহিক (ফাইল) নয়, একটি যৌক্তিক বিচ্ছেদ প্রদান করে।

— জওয়েন

এটি কোনও সত্য নয় যে কোনও পার্থক্য নেই; ব্লকগুলির usingমধ্যে নির্দেশাবলী namespaceএনকোলেসিং namespaceব্লকের ভিত্তিতে আপেক্ষিক নেমস্পেসগুলি উল্লেখ করতে পারে ।

— বা ম্যাপার

হ্যাঁ আমি জানি. আমরা পাঁচ বছর আগে এই প্রশ্নের স্বীকৃত উত্তরটিতে এটি প্রতিষ্ঠিত করেছি।

— মার্ক সিডেড

Answer 4

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

আমার পছন্দ হ'ল এগুলিকে নেমস্পেসের বাইরে রেখে দেওয়া।

Comments

@Chris এম: আহ ... লিংক উত্তর পোস্ট করা আছে ইঙ্গিত কোন উপকার বনাম আউট করা, আসলে একটি উদাহরণ দেখাচ্ছে যে falsifies দাবি আপনি যে লিংক পোস্ট করা ...

— জনি

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

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

লিঙ্কটির একটি সংক্ষিপ্তসার অন্তর্ভুক্ত করুন। যখন লিঙ্কটি অসম্পূর্ণ (কারণ এটা হবে ঘটে যথেষ্ট সময় দেওয়া হয়), হঠাৎ 32 upvotes সঙ্গে একটি উত্তর শুধুমাত্র মূল্য My style is to put them outside the namespaces.- এ সব সবে একটি উত্তর।

— এভিনিস

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

— জিম বাল্টার

Answer 5

স্টাইলকপ ডকুমেন্টেশন অনুসারে:

SA1200: ব্যবহারের নির্দেশাবলী মাস্টবিপ্লেডওয়াইথিননামস্পেস

নির্দেশিকা ব্যবহার করে এসি # কারণ একটি স্থানের উপাদানটির বাইরে রাখা হয়েছে।

বিধি বিবরণ এই নিয়মের লঙ্ঘন ঘটে যখন যখন কোনও নির্দেশ নির্দেশক বা কোনও ব্যবহার-উরফ নির্দেশিকা নামের স্থানের বাইরে রাখা হয়, যদি না ফাইলটিতে কোনও নামস্থান উপাদান থাকে না elements

উদাহরণস্বরূপ, নিম্নলিখিত কোডের ফলে এই নিয়ম দুটি লঙ্ঘন হতে পারে।

using System;
using Guid = System.Guid;

namespace Microsoft.Sample
{
    public class Program
    {
    }
}

নিম্নলিখিত কোডগুলি তবে এই বিধি লঙ্ঘনের ফলাফল হিসাবে নয়:

namespace Microsoft.Sample
{
    using System;
    using Guid = System.Guid;

    public class Program
    {
    }
}

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

namespace Microsoft.Sample
{
    using Guid = System.Guid;
    public class Guid
    {
        public Guid(string s)
        {
        }
    }

    public class Program
    {
        public static void Main(string[] args)
        {
            Guid g = new Guid("hello");
        }
    }
}

কোডটি নিম্নোক্ত সংকলক ত্রুটিতে ব্যর্থ হয়েছে, এতে থাকা লাইনে পাওয়া গেছে Guid g = new Guid("hello");

CS0576: নেমস্পেস 'মাইক্রোসফ্ট.স্যাম্পল'-এ একটি সংজ্ঞা সংঘটিত হয় যার নাম' গাইড '

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

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

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

নেমস্পেস উপাদানটির মধ্যে ব্যবহার করে-উরফ নির্দেশাবলী স্থাপন করা এটি বাগের উত্স হিসাবে মুছে ফেলে।

2. একাধিক নেমস্পেস

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

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

কীভাবে লঙ্ঘন ঠিক করা যায় এই বিধি লঙ্ঘন স্থির করতে, সমস্ত નેমস্পেসের এলিমেন্টের মধ্যে নির্দেশনা এবং ব্যবহারের-উরফ নির্দেশাবলী ব্যবহার করে সরান।

Comments

@ জ্যারেড - আমি আমার উত্তরে উল্লেখ করেছি যে, আমার পছন্দের কাজ / সমাধানটি ফাইলের জন্য কেবলমাত্র একটি ক্লাস থাকা উচিত। আমি মনে করি এটি একটি মোটামুটি সাধারণ সম্মেলন।

— বেন পিয়ার্স

আসলে এটি স্টাইলকপ নিয়মও! SA1402: এসি # নথিটিতে কেবলমাত্র স্তরের একক শ্রেণী থাকতে পারে যতক্ষণ না সমস্ত ক্লাসের সমস্ত বিভাগ আংশিক এবং একই ধরণের হয়। অন্যটি ভেঙে একটি বিধি প্রদর্শন করে ভুল সসের সাথে কেবল ড্রিপস।

— টাস্ক

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

— নওফাল

অবশেষে প্রশ্নের একটি ভাল উত্তর। এবং বেন পিয়ার্সের মন্তব্য অপ্রাসঙ্গিক ... ফাইলের ক্লাসের সংখ্যার সাথে এর কোনও যোগসূত্র নেই।

— জিম বাল্টার

Answer 6

আপনি যখন এলিয়াস ব্যবহার করতে চান তখন নেমস্পেসের ভিতরে স্টেটমেন্ট ব্যবহার করে একটি সমস্যা রয়েছে। পূর্বের usingবক্তব্যগুলি থেকে উপাধি উপকারে আসে না এবং পুরোপুরি যোগ্য হতে হবে।

বিবেচনা:

namespace MyNamespace
{
    using System;
    using MyAlias = System.DateTime;

    class MyClass
    {
    }
}

বনাম:

using System;

namespace MyNamespace
{
    using MyAlias = DateTime;

    class MyClass
    {
    }
}

নিম্নলিখিতটি (যেমনটি আমি কীভাবে সমস্যাটি পেয়েছি) এর মতো আপনার দীর্ঘ-বায়ুযুক্ত উপন্যাস থাকলে এটি বিশেষত উচ্চারণ করা যেতে পারে:

using MyAlias = Tuple<Expression<Func<DateTime, object>>, Expression<Func<TimeSpan, object>>>;

usingনেমস্পেসের ভিতরে বিবৃতি সহ , এটি হঠাৎ হয়ে যায়:

using MyAlias = System.Tuple<System.Linq.Expressions.Expression<System.Func<System.DateTime, object>>, System.Linq.Expressions.Expression<System.Func<System.TimeSpan, object>>>;

সুন্দর না.

Comments

আপনার classএকটি নাম (সনাক্তকারী) দরকার। আপনি usingইঙ্গিত হিসাবে ক্লাসের ভিতরে কোনও নির্দেশিকা থাকতে পারে না । এটি অবশ্যই একটি নেমস্পেস স্তরে থাকতে হবে, উদাহরণস্বরূপ বাহ্যতমতমের বাইরে namespaceবা অভ্যন্তরের অভ্যন্তরে namespace(তবে কোনও শ্রেণি / ইন্টারফেস / ইত্যাদির ভিতরে নয়)।

— জেপ্পে স্টিগ নীলসন

@ জেপ্পস্টিগনিয়েলসন ধন্যবাদ। আমি usingভুলভাবে নির্দেশাবলী ভুল করে ফেলেছি । আমি এটি সম্পাদনা করেছিলাম কীভাবে এটির ইচ্ছা ছিল। নির্দেশ করার জন্য ধন্যবাদ। যুক্তি এখনও একই, যদিও।

— নিও

Answer 7

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

using নেমস্পেসের ভিতরে উল্লিখিত নির্দেশিকাগুলি সংক্ষিপ্ত কোড তৈরি করতে পারে যেহেতু বাইরের দিকে নির্দিষ্ট করার সময় তাদের পুরোপুরি যোগ্যতার প্রয়োজন হয় না।

নিম্নলিখিত উদাহরণটি কাজ করে কারণ প্রকারগুলি Fooএবং Barএকই গ্লোবাল নেমস্পেসে উভয়ই Outer,।

কোড ফাইলটি Foo.cs অনুমান করুন :

namespace Outer.Inner
{
    class Foo { }
}

এবং বার. cs :

namespace Outer
{
    using Outer.Inner;

    class Bar
    {
        public Foo foo;
    }
}

এটি usingসংক্ষেপে, নির্দেশের মধ্যে বাইরের নেমস্পেসটি বাদ দিতে পারে :

namespace Outer
{
    using Inner;

    class Bar
    {
        public Foo foo;
    }
}

Comments

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

— কিথ রবার্টসন

Answer 8

আমি একটি কুঁচকিতে ছুটে এসেছি (এটি অন্য উত্তরে আচ্ছাদিত নয়):

ধরুন আপনার কাছে এই নেমস্পেসগুলি রয়েছে:

• Something.Other
• Parent.Something.Other

আপনি ব্যবহার করেন, তখন using Something.Other বাইরে একটি এর namespace Parent, এটা প্রথম এক (Something.Other) বোঝায়।

তবে আপনি যদি সেই নামের স্থানের ঘোষণার ভিতরে এটি ব্যবহার করেন তবে এটি দ্বিতীয়টি বোঝায় (প্যারেন্ট.সোমথিং.অথার)!

একটি সহজ সমাধান রয়েছে: " global::" উপসর্গ: ডক্স যুক্ত করুন

namespace Parent
{
   using global::Something.Other;
   // etc
}

Answer 9

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

নিম্নলিখিত ফাইলগুলির সাথে প্রকল্পের মূলের মধ্যে ফাইল usingযুক্ত করে নামস্পেসের বাইরের দিকনির্দেশগুলি পরীক্ষা করতে স্টাইলোকপ সামঞ্জস্য করতে পারেন stylecop.json:

{
  "$schema": "https://raw.githubusercontent.com/DotNetAnalyzers/StyleCopAnalyzers/master/StyleCop.Analyzers/StyleCop.Analyzers/Settings/stylecop.schema.json",
    "orderingRules": {
      "usingDirectivesPlacement": "outsideNamespace"
    }
  }
}

আপনি সমাধানের স্তরে এই কনফিগারেশন ফাইলটি তৈরি করতে পারেন এবং আপনার সমস্ত প্রকল্পের মধ্যেও কনফিগারেশনটি ভাগ করতে আপনার প্রকল্পগুলিতে এটি 'বিদ্যমান লিঙ্ক ফাইল' হিসাবে যুক্ত করতে পারেন।

Answer 10

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

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

//file1.cs
namespace Foo
{
    class Foo
    {
    }
}

//file2.cs
namespace ConsoleApp3
{
    using Foo;
    class Program
    {
        static void Main(string[] args)
        {
            //This will allow you to use the class
            Foo test = new Foo();
        }
    }
}

//file2.cs
using Foo; //Unused and redundant    
namespace Bar
{
    class Bar
    {
        Bar()
        {
            Foo.Foo test = new Foo.Foo();
            Foo test = new Foo(); //will give you an error that a namespace is being used like a class.
        }
    }
}

Answer 11

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

Comments

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

— হাবিল