'භාවිතා කිරීම' විධානයන් නාම අවකාශය තුළ හෝ පිටත තිබිය යුතුද?

මම සමහර C # කේත හරහා ස්ටයිල්කොප් ධාවනය කර ඇති අතර , එය මගේ usingනියමයන් නාම අවකාශය තුළ තිබිය යුතු බව වාර්තා කරයි .

usingනාම අවකාශයෙන් පිටත වෙනුවට විධානයන් ඇතුලත් කිරීමට තාක්ෂණික හේතුවක් තිබේද?

ඇත්ත වශයෙන්ම මේ දෙක අතර (සියුම්) වෙනසක් ඇත. File1.cs හි ඔබට පහත කේතය ඇතැයි සිතන්න:

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

දැන් හිතන්න කවුරුහරි මේ වගේ ව්‍යාපෘතියට තවත් ගොනුවක් (File2.cs) එකතු කරනවා:

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

සම්පාදකයා නාම අවකාශයෙන් පිටත Outerඑම usingවිධානයන් බැලීමට පෙර සොයයි , එබැවින් එය Outer.Mathවෙනුවට සොයා ගනී System.Math. අවාසනාවට (හෝ සමහර විට වාසනාවකටද?), Outer.Mathඑහි PIසාමාජිකයෙකු නොමැත , එබැවින් File1 දැන් කැඩී ඇත.

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විධානයක් බැලීමට පෙර අභ්‍යන්තරයේ ඇති නාම අවකාශය සොයන බවයි.

මෙම ත්‍රෙඩ් එකට දැනටමත් හොඳ පිළිතුරු කිහිපයක් ඇත, නමුත් මෙම අතිරේක පිළිතුර සමඟ මට තව ටිකක් විස්තර ගෙන ඒමට හැකි යැයි මට හැඟේ.

පළමුව, මතක තබා ගන්න කාල පරාසයන් සහිත නාම අවකාශ ප්‍රකාශයක්,

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

සම්පූර්ණයෙන්ම සමාන වේ:

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

ඔබට අවශ්‍ය නම්, ඔබට usingමෙම සියලු මට්ටම් සඳහා උපදෙස් දිය හැකිය . (ඇත්ත වශයෙන්ම, අපට අවශ්‍ය usingවන්නේ එක් ස්ථානයක පමණක් වන නමුත් එය භාෂාව අනුව නීත්‍යානුකූල වනු ඇත.)

කුමන ආකාරයේ ගම්‍යද යන්න නිරාකරණය කිරීමේ රීතිය මේ ආකාරයට ලිහිල් ලෙස ප්‍රකාශ කළ හැකිය: පළමුව තරඟයක් සඳහා අභ්‍යන්තර-වඩාත්ම “විෂය පථය” සොයන්න, කිසිවක් සොයාගත නොහැකි නම්, එක් මට්ටමකින් ඊළඟ විෂය පථයට ගොස් එහි සොයන්න, සහ එසේ ය . තරඟයක් සොයා ගන්නා තුරු. කිසියම් මට්ටමකට එකකට වඩා වැඩි ප්‍රමාණයක් හමු වුවහොත්, එක් වර්ගයක් වත්මන් එකලස් කිරීමේ සිට නම්, එය තෝරාගෙන සම්පාදක අනතුරු ඇඟවීමක් කරන්න. එසේ නොමැතිනම් අත්හරින්න (සම්පාදක කාල දෝෂය).

දැන්, ප්‍රධාන සම්මුතීන් දෙක සමඟ සංයුක්ත උදාහරණයකින් මෙයින් අදහස් කරන්නේ කුමක්ද යන්න පිළිබඳව පැහැදිලිව කියමු.

(1) පිටත භාවිතයන් සමඟ:

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) ඇතුළත භාවිතයන් සමඟ:

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" අතර අවශ්‍ය නොවීය.)

සමාප්ති සටහන්

ඔබ නාම අවකාශ ප්‍රකාශය ඇතුළත හෝ පිටත භාවිතා කළත් කමක් නැත, යමෙකු පසුව වැඩි ප්‍රමුඛතාවයක් ඇති නාම අවකාශයන්ගෙන් එකකට සමාන නමක් සහිත නව වර්ගයක් එකතු කිරීමේ හැකියාව සෑම විටම පවතී.

එසේම, කැදැලි නාම අවකාශයකට වර්ගයකට සමාන නමක් තිබේ නම්, එය ගැටළු ඇති කළ හැකිය.

සෙවුම් ධූරාවලිය වෙනස් වන නිසා සහ වෙනත් වර්ගයක් සොයා ගත හැකි නිසා භාවිතයන් එක් ස්ථානයක සිට තවත් ස්ථානයකට ගෙන යාම සැමවිටම භයානක ය. එමනිසා, එක් සමුළුවක් තෝරාගෙන එයට ඇලී සිටින්න, එවිට ඔබට කිසි විටෙකත් භාවිතයන් ගෙනයාමට සිදු නොවේ.

විෂුවල් ස්ටුඩියෝ හි සැකිලි, පෙරනිමියෙන්, භාවිතයන් නාම අවකාශයෙන් පිටත තබන්න (නිදසුනක් ලෙස ඔබ VS නව ගොනුවක් තුළ නව පන්තියක් ජනනය කරන්නේ නම්).

පිටත භාවිතයේ ඇති එක් (කුඩා) වාසියක් නම්, ඔබට පසුව ගෝලීය ගුණාංගයක් සඳහා භාවිතා කරන විධානයන් භාවිතා කළ හැකිය, උදාහරණයක් [assembly: ComVisible(false)]ලෙස [assembly: System.Runtime.InteropServices.ComVisible(false)].

එය නාම අවකාශය තුළ තැබීම මඟින් ගොනුව සඳහා එම නාම අවකාශයට දේශීය ප්‍රකාශනය කරයි (ඔබට ගොනුවේ බහු නාම අවකාශයක් තිබේ නම්) නමුත් ඔබට එක් ගොනුවකට එක් නාම අවකාශයක් පමණක් තිබේ නම් ඒවා පිටතට ගියත් නැතත් විශාල වෙනසක් සිදු නොවේ. නාම අවකාශය තුළ.

using ThisNamespace.IsImported.InAllNamespaces.Here;

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

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

namespace Namespace3
{ 
   using ThisNamespace.IsImported.InJustNamespace3;
}

හැන්සල්මන්ට අනුව - ඩිරෙක්ටිව් සහ එකලස් පැටවීම භාවිතා කිරීම ... සහ වෙනත් එවැනි ලිපි තාක්ෂණික වශයෙන් වෙනසක් නැත.

මගේ මනාපය නම් ඒවා නාම අවකාශයෙන් පිටත තැබීමයි.

ස්ටයිල්කොප් ප්‍රලේඛනයට අනුව:

SA1200: DirectDirectivesMustBePlacedWithinNamespace භාවිතා කිරීම

හේතුව AC # විධානය භාවිතා කිරීම නාම අවකාශයක මූලද්‍රව්‍යයෙන් පිටත තබා ඇත.

රීති විස්තරය ගොනුවේ කිසිදු නාම අවකාශ මූලද්‍රව්‍යයක් නොමැති නම්, නාම අවකාශයක මූලද්‍රව්‍යයෙන් පිටත භාවිතා කරන විධානයක් හෝ අන්වර්ථ නාමයක් භාවිතා කරන විට මෙම රීතිය උල්ලං violation නය වේ.

උදාහරණයක් ලෙස, පහත දැක්වෙන කේතය මෙම රීතිය උල්ලං lations නය කිරීම් දෙකකට හේතු වේ.

using System;
using Guid = System.Guid;

namespace Microsoft.Sample
{
    public class Program
    {
    }
}

කෙසේ වෙතත්, පහත දැක්වෙන කේතය මෙම රීතිය උල්ලං in නය කිරීමක් සිදු නොකරනු ඇත:

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: නාම අවකාශය 'Microsoft.Sample' හි අන්වර්ථ නාමයක් වන 'Guid' සමඟ ගැටෙන අර්ථ දැක්වීමක් අඩංගු වේ.

මෙම කේතය System.Guid වර්ගයට Guid ලෙස අන්වර්ථයක් නිර්මාණය කරයි, එසේම ගැලපෙන ඉදිකිරීම් අතුරුමුහුණතක් සහිත Guid නමින් තමන්ගේම වර්ගයක් නිර්මාණය කරයි. පසුව, කේතය මඟින් ගයිඩ් වර්ගය පිළිබඳ උදාහරණයක් නිර්මාණය කරයි. මෙම අවස්ථාව නිර්මාණය කිරීම සඳහා, සම්පාදකයා විසින් මාර්ගෝපදේශයේ වෙනස් අර්ථකථන දෙක අතර තෝරා ගත යුතුය. භාවිතා කිරීමේ-අන්වර්ථ විධානය නාම අවකාශයේ මූලද්‍රව්‍යයෙන් පිටත තැබූ විට, සම්පාදකයා විසින් දේශීය නාම අවකාශය තුළ නිර්වචනය කර ඇති මාර්ගෝපදේශයේ දේශීය අර්ථ දැක්වීම තෝරා ගනු ඇති අතර නාම අවකාශයෙන් පිටත අර්ථ දක්වා ඇති භාවිතා කිරීමේ අන්වර්ථ නියෝගය සම්පූර්ණයෙන්ම නොසලකා හරිනු ඇත. අවාසනාවට, කේතය කියවීමේදී මෙය පැහැදිලිව පෙනෙන්නට නැත.

කෙසේ වෙතත්, භාවිතා කිරීමේ-අන්වර්ථ විධානය නාම අවකාශය තුළ ස්ථානගත කර ඇති විට, සම්පාදකයාට එකම නාම අවකාශය තුළ අර්ථ දක්වා ඇති වෙනස්, ගැටුම් සහිත මාර්ගෝපදේශ වර්ග දෙකක් තෝරා ගත යුතුය. මෙම වර්ග දෙකම ගැලපෙන ඉදිකිරීම්කරුවෙකු සපයයි. සම්පාදකයාට තීරණයක් ගැනීමට නොහැකි නිසා එය සම්පාදක දෝෂය සලකුණු කරයි.

නාම අවකාශයෙන් පිටත භාවිතා කිරීම-අන්වර්ථ නියෝගය තැබීම නරක පුරුද්දකි, මන්දයත් මෙවැනි තත්වයන් තුළ ව්‍යාකූලත්වයට හේතු විය හැකි අතර, ඇත්ත වශයෙන්ම කුමන වර්ගයේ අනුවාදයක් භාවිතා කරන්නේද යන්න පැහැදිලි නැත. මෙය දෝෂ හඳුනා ගැනීමට අපහසු විය හැකි දෝෂයකට තුඩු දිය හැකිය.

නාම අවකාශයේ මූලද්‍රව්‍යය තුළ අන්වර්ථ නාම භාවිතා කිරීමෙන් මෙය දෝෂ ප්‍රභවයක් ලෙස ඉවත් කරයි.

2. බහු නාම අවකාශයන්

එක් ගොනුවක් තුළ බහු නාම මූලද්‍රව්‍ය තැබීම සාමාන්‍යයෙන් නරක අදහසකි, නමුත් මෙය සිදු කළ විට සහ භාවිතා කරන විට, ගෝලීයව ගොනුවේ ඉහළින් නොව, සෑම නාම අවකාශයකම භාවිතා කරන සියලු විධානයන් තැබීම හොඳ අදහසකි. මෙය නාම අවකාශයන් තදින් විෂය පථයට යොමු කරනු ඇති අතර, ඉහත විස්තර කර ඇති ආකාරයේ හැසිරීම් වලක්වා ගැනීමට ද උපකාරී වේ.

නාම අවකාශයෙන් පිටත තබා ඇති විධානයන් භාවිතා කරමින් කේතය ලියා ඇති විට, මෙම විධානයන් නාම අවකාශය තුළට ගෙන යන විට සැලකිලිමත් විය යුතු අතර, මෙය කේතයේ අර්ථ නිරූපණය වෙනස් නොවන බවට වග බලා ගත යුතුය. ඉහත විස්තර කර ඇති පරිදි, නාම අවකාශයේ මූලද්‍රව්‍යය තුළ අන්වර්ථ නාම භාවිතා කිරීම සම්පාදකයාට නාම අවකාශයෙන් පිටත විධානයන් තැබූ විට සිදු නොවන ආකාරයෙන් ගැටුම් වර්ග අතර තෝරා ගැනීමට ඉඩ දෙයි.

උල්ලං lations නයන් නිවැරදි කරන්නේ කෙසේද මෙම රීතිය උල්ලං violation නය කිරීමක් නිවැරදි කිරීම සඳහා, නාම අවකාශයේ මූලද්‍රව්‍යය තුළ ඇති සියලුම විධානයන් සහ අන්වර්ථ නාමයන් භාවිතා කරන්න.

ඔබට අන්වර්ථ නාම භාවිතා කිරීමට අවශ්‍ය වූ විට නාම අවකාශය තුළ ප්‍රකාශ භාවිතා කිරීම ගැටළුවක් වේ. අන්වර්ථය කලින් සිට ප්‍රතිලාභ නොලබයි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>>>;

ලස්සන නැහැ.

ජෙප් ස්ටිග් නීල්සන් පැවසූ පරිදි , මෙම නූලට දැනටමත් හොඳ පිළිතුරු ඇත, නමුත් මම සිතුවේ මෙම පැහැදිලිව පෙනෙන සියුම්කම ද සඳහන් කිරීම වටී.

using නාම අවකාශයන් තුළ දක්වා ඇති විධානයන් කෙටි කේතයක් සෑදිය හැකි බැවින් ඒවා පිටතින් නිශ්චිතව දක්වා ඇති ආකාරයට පූර්ණ සුදුසුකම් ලැබිය යුතු නොවේ.

පහත දැක්වෙන උදාහරණය ක්‍රියාත්මක වන්නේ වර්ග Fooසහ Barදෙකම එකම ගෝලීය නාම අවකාශයේ පවතින බැවිනි.Outer බැවිනි.

, අනුමාන කේතය ගොනුව Foo.cs :

namespace Outer.Inner
{
    class Foo { }
}

සහ Bar.cs :

namespace Outer
{
    using Outer.Inner;

    class Bar
    {
        public Foo foo;
    }
}

usingකෙටියෙන් කිවහොත්, විධානයෙහි පිටත නාම අවකාශය මඟ හැරිය හැක :

namespace Outer
{
    using Inner;

    class Bar
    {
        public Foo foo;
    }
}

එක් රැල්ලක් මා තුළට දිව ගියේය (එය වෙනත් පිළිතුරු වලින් ආවරණය නොවේ):

ඔබට මෙම නාම අවකාශයන් ඇතැයි සිතමු:

• වෙනත් දෙයක්
• දෙමාපිය

ඔබ using Something.Other පිටත භාවිතා කරන විට anamespace Parent , එය පළමු එක (යමක්. වෙනත්) වෙත යොමු වේ.

කෙසේ වෙතත් ඔබ එය ඇතුළත භාවිතා කරන්නේ නම් එම නාම අවකාශයේ ප්‍රකාශනය , එය යොමු දක්වන්නේ දෙවැන්න (දෙමාපිය. යම් දෙයක්. වෙනත්)!

සරල විසඳුමක් ඇත: " global::" උපසර්ගය එක් කරන්න : ලියකියවිලි

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

තාක්‍ෂණික හේතූන් පිළිතුරු වල සාකච්ඡා කර ඇති අතර වෙනස එතරම් විශාල නොවන නිසාත් ඒ දෙකම සඳහා වෙළඳාම් ඇති නිසාත් එය අවසානයේ පෞද්ගලික මනාපයන් වෙත පැමිණෙනු ඇතැයි මම සිතමි . .csලිපිගොනු නිර්මාණය කිරීම සඳහා විෂුවල් ස්ටුඩියෝ හි පෙරනිමි අච්චුව usingනාම අවකාශයෙන් පිටත විධානයන් භාවිතා කරයි

පහත සඳහන් දෑ සමඟ ව්‍යාපෘති ගොනුවේ මූලයේ ගොනුවක් usingඑක් කිරීම මගින් නාම අවකාශයෙන් පිටත විධානයන් පරීක්ෂා කිරීමට කෙනෙකුට ස්ටයිල්කොප් සකස් කළ හැකිය stylecop.json:

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

ඔබට මෙම වින්‍යාස ගොනුව විසඳුම් මට්ටමින් නිර්මාණය කර ඔබගේ ව්‍යාපෘති සියල්ලටම 'පවතින සම්බන්ධක ගොනුව' ලෙස එක් කළ හැකිය.

අනෙක් පිළිතුරු වලින් ආවරණය වී ඇති බව මා විශ්වාස නොකරන තවත් සියුම් දෙයක් නම්, ඔබට එකම නමක් සහිත පංතියක් සහ නාම අවකාශයක් ඇති විටය.

ඔබ නාම අවකාශය තුළ ආනයනය කළ විට එය පන්තිය සොයා ගනී. ආනයනය නාම අවකාශයෙන් පිටත නම් ආනයනය නොසලකා හරිනු ලබන අතර පන්තිය සහ නාම අවකාශය පූර්ණ සුදුසුකම් ලැබිය යුතුය.

//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.
        }
    }
}

එම නම් එය වඩාත් හොඳ ක්රමයක් වන්නේ පෙරනිමිය එනම් "භාවිතා යොමු ඔබගේ මූලාශ්රය විසඳුමක් සඳහා භාවිතා කරන 'ද නාමඅවකාශයන්හි පිටත විය යුතු අතර සිටින බව එම " නව එකතු සඳහනක් " හොඳ පුරුද්දකි ඔබ නාමඅවකාශයෙහි තුල එය ඉදිරිපත් කළ යුතුය වේ. මෙය එකතු කරනු ලබන යොමු මොනවාද යන්න වෙන්කර හඳුනා ගැනීමයි.