මා කලින් ශ්‍රිතයකින් ආපසු පැමිණිය යුතුද? නැතහොත් if ප්‍රකාශයක් භාවිතා කළ යුතුද? [වසා ඇත]

මම බොහෝ විට ආකෘති දෙකෙහිම මෙවැනි ක්‍රියාකාරිත්වයක් ලියා ඇති අතර, එක් ආකෘතියක් තවත් ආකෘතියකට වඩා කැමති දැයි මම කල්පනා කළෙමි.

public void SomeFunction(bool someCondition)
{
    if (someCondition)
    {
        // Do Something
    }
}

හෝ

public void SomeFunction(bool someCondition)
{
    if (!someCondition)
        return;

    // Do Something
}

මම සාමාන්‍යයෙන් පළමු එක සමඟ කේත කරන්නේ කේතීකරණයේදී මගේ මොළය ක්‍රියා කරන ආකාරය නිසා ය, නමුත් මම සිතන්නේ 2 වන ක්‍රමයට වඩා වැඩි කැමැත්තක් දක්වන්නේ එය කිසියම් දෝෂයක් හැසිරවීම ගැන වහාම බලා ගන්නා නිසා සහ කියවීමට පහසු වන බැවිනි

මම දෙවන විලාසිතාවට කැමතියි. පළමුවෙන්ම අවලංගු අවස්ථා මඟහරින්න, එක්කෝ සුදුසු පරිදි පිටවීම හෝ ව්‍යතිරේකයන් මතු කිරීම, හිස් රේඛාවක් එහි දමා, ඉන්පසු ක්‍රමයේ “සැබෑ” ශරීරය එක් කරන්න. මට කියවීම පහසුය.

නිසැකවම දෙවැන්න. කලින් සඳහන් කළ දේ දැන් නරක නැත, නමුත් ඔබ වඩාත් සංකීර්ණ කේතයක් ලබා ගත් විට, කිසිවෙකු මෙය සිතනු ඇතැයි මට සිතාගත නොහැකිය:

public int SomeFunction(bool cond1, string name, int value, AuthInfo perms)
{
    int retval = SUCCESS;
    if (someCondition)
    {
        if (name != null && name != "")
        {
            if (value != 0)
            {
                if (perms.allow(name)
                {
                    // Do Something
                }
                else
                {
                    reval = PERM_DENY;
                }
            }
            else
            {
                retval = BAD_VALUE;
            }
        }
        else
        {
            retval = BAD_NAME;
        }
    }
    else
    {
        retval = BAD_COND;
    }
    return retval;
}

වඩා කියවිය හැකි ය

public int SomeFunction(bool cond1, string name, int value, AuthInfo perms)
{
    if (!someCondition)
        return BAD_COND;

    if (name == null || name == "")
        return BAD_NAME;

    if (value == 0)
        return BAD_VALUE;

    if (!perms.allow(name))
        return PERM_DENY;

    // Do something
    return SUCCESS;
}

තනි පිටවීමේ ස්ථානවල වාසිය මා කිසි විටෙකත් තේරුම් නොගත් බව මම සම්පූර්ණයෙන්ම පිළිගනිමි.

එය රඳා පවතින්නේ - පොදුවේ ගත් කල, ශ්‍රිතයෙන් ඉවත්වීම සඳහා කේත පොකුරක් ගෙනයාමට උත්සාහ කිරීමට මම නොයන්නෙමි - සම්පාදකයා සාමාන්‍යයෙන් මා වෙනුවෙන් ඒ ගැන බලා ගනී. කෙසේ වෙතත්, මට අවශ්‍ය මූලික පරාමිතීන් කිහිපයක් තිබේ නම් සහ වෙනත් ආකාරයකින් ඉදිරියට යා නොහැකි නම්, මම වේලාසනින් කඩාවැටෙන්නෙමි. ඒ හා සමානව, යම් තත්වයක් මඟින් යෝධ ifබ්ලොක් එකක් ජනනය කරන්නේ නම්, එහි ප්‍රති result ලයක් ලෙස මට එය කඩාවැටෙනු ඇත.

කෙසේ වෙතත්, යම් ශ්‍රිතයක් හැඳින්වූ විට යම් දත්තයක් අවශ්‍ය නම්, මම සාමාන්‍යයෙන් නැවත පැමිණීමට වඩා ව්‍යතිරේකයක් විසි කරමි (උදාහරණය බලන්න).

public int myFunction(string parameterOne, string parameterTwo) {
  // Can't work without a value
  if (string.IsNullOrEmpty(parameterOne)) {
    throw new ArgumentNullException("parameterOne");
  } 
  if (string.IsNullOrEmpty(parameterTwo)) {
    throw new ArgumentNullException("parameterTwo");
  }

  // ...      
  // Do some work
  // ...

  return value;
}

මම කලින් පැමිණීමට කැමතියි.

ඔබට එක් පිවිසුම් ස්ථානයක් සහ එක් පිටවීමේ ස්ථානයක් තිබේ නම්, ඔබ සැමවිටම ඔබේ හිසෙහි ඇති මුළු කේතයම පිටවීමේ ස්ථානය දක්වාම ලුහුබැඳිය යුතුය (වෙනත් කේත බෙලෝ කැබැල්ලක් ප්‍රති result ලයට වෙනත් යමක් කරයිදැයි ඔබ කිසි විටෙකත් නොදනී. පවතින තුරු එය සොයා ගත යුතුය). අවසාන ප්‍රති .ලය තීරණය කරන්නේ කුමන ශාඛාවකින්ද යන්න ඔබ කරන්නේ නැත. මෙය අනුගමනය කිරීම දුෂ්කර ය.

එක් ප්‍රවේශයක් සහ බහුවිධ පැවැත්මක් ඇති විට, ඔබ ඔබේ ප්‍රති result ලය ලැබුණු විට නැවත පැමිණෙන අතර කිසිවෙකු ඒ සඳහා වෙන කිසිවක් නොකරන බව දැකීමට එය කරදර නොවන්න (මන්ද ඔබ ආපසු පැමිණි දා සිට වෙනත් කිසිවක් නොතිබෙනු ඇත). එය හරියට ශරීරය තවත් පියවර කිහිපයකට බෙදීම හා සමාන වන අතර, සෑම පියවරක්ම ප්‍රති result ලය ලබා දීමට හෝ ඊළඟ පියවරට එහි වාසනාව අත්හදා බැලීමට ඉඩ සලසයි.

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

සී ++ ක්‍රමලේඛනයේදී ඔබට ඩිස්ට්‍රැක්ටර්ස් ඇති අතර දැන් පවා විෂය පථයෙන් පිටවීමේ ආරක්ෂකයින් සිටී. කේතය ව්‍යතිරේක-ආරක්ෂිත බව සහතික කිරීම සඳහා මේ සියල්ලම මෙහි තිබිය යුතුය, එබැවින් කේතය කලින් පිටවීම වැළැක්වීම සඳහා හොඳින් ආරක්ෂා වී ඇති අතර එබැවින් එසේ කිරීමෙන් කිසිදු තාර්කික අවාසියක් නොමැති අතර එය හුදෙක් විලාසිතාවේ ගැටලුවකි.

මම ජාවා ගැන ප්‍රමාණවත් දැනුමක් නොදක්වමි, “අවසාන වශයෙන්” බ්ලොක් කේතය කැඳවනු ඇත්ද සහ යම් දෙයක් සිදු වන බව සහතික කිරීමට අවශ්‍ය තත්වයට අවසාන තරඟකරුවන්ට මුහුණ දිය හැකිද යන්න.

සී # මට නිසැකවම පිළිතුරු දිය නොහැක.

ඩී-භාෂාව ඔබට නිසි ලෙස ගොඩනඟන ලද විෂය පථයෙන් පිටවීමේ ආරක්ෂකයින් ලබා දෙන අතර එම නිසා කලින් පිටවීම සඳහා හොඳින් සූදානම්ව සිටින අතර එම නිසා ශෛලිය හැර වෙනත් ප්‍රශ්නයක් ඉදිරිපත් නොකළ යුතුය.

කාර්යයන් ඇත්ත වශයෙන්ම එතරම් දිගු නොවිය යුතු අතර, ඔබට විශාල ස්විච් ප්‍රකාශයක් තිබේ නම් ඔබේ කේතය ද නරක ලෙස සාධක වේ.

ජයග්‍රහණය සඳහා මුල් ප්‍රතිලාභ. ඒවා කැත ලෙස පෙනේ, නමුත් විශාල ifඑතීමට වඩා අඩු කැතයි , විශේෂයෙන් පරීක්ෂා කිරීමට විවිධ කොන්දේසි තිබේ නම්.

මම දෙකම පාවිච්චි කරනවා.

DoSomethingකේත පේළි 3-5 ක් නම් පළමු හැඩතල ගැන්වීමේ ක්‍රමය භාවිතයෙන් කේතය ලස්සනයි.

නමුත් එයට වඩා බොහෝ රේඛා තිබේ නම්, මම දෙවන ආකෘතියට කැමතියි. විවෘත කිරීමේ සහ වසා දැමීමේ වරහන් එකම තිරයේ නොමැති විට මම කැමති නැත.

තනි පිවිසුම්-තනි-පිටවීම සඳහා සම්භාව්‍ය හේතුවක් නම්, විධිමත් අර්ථ නිරූපණය වෙනත් ආකාරයකින් කිව නොහැකි තරම් කැත බවට පත්වීමයි (GOTO හානිකර යැයි සැලකූ එකම හේතුව).

වෙනත් ක්‍රමයක් තබන්න, ඔබට 1 ප්‍රතිලාභයක් පමණක් තිබේ නම් ඔබේ මෘදුකාංගය සාමාන්‍යයෙන් ඉවත් වන්නේ කවදාදැයි තර්ක කිරීම පහසුය. එය ද ව්‍යතිරේකයට එරෙහි තර්කයකි.

සාමාන්‍යයෙන් මම කලින් ආපසු එන ප්‍රවේශය අවම කරමි.

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

එය රඳා පවතියි.

එකවරම පරීක්ෂා කිරීම සඳහා පැහැදිලිව පෙනෙන මළ අවසානයක් තිබේ නම් ඉක්මනින් ආපසු පැමිණීම, එමඟින් ඉතිරි ශ්‍රිතය අර්ථ විරහිත වනු ඇත. *

ශ්‍රිතය වඩාත් සංකීර්ණ නම් සහ වෙනත් ආකාරයකින් පිටවීමේ ස්ථාන තිබිය හැකි නම් නැවත ලබා ගැනීමේ + තනි ප්‍රතිලාභයක් සකසන්න (කියවීමේ හැකියාව පිළිබඳ ගැටළුව).

* මෙය බොහෝ විට නිර්මාණ ගැටලුවක් දැක්විය හැකිය. ඔබේ කේතයන් බොහොමයක් බාහිර / පරාමිති තත්වයක් හෝ ඉතිරි කේතය ක්‍රියාත්මක කිරීමට පෙර පරීක්ෂා කර බැලිය යුතු බව ඔබ සොයා ගන්නේ නම්, එය බොහෝ විට අමතන්නා විසින් හැසිරවිය යුතු දෙයකි.

If භාවිතා කරන්න

ගොටෝ ගැන ඩොන් නුත්ගේ පොතේ මම කියවූයේ සෑම විටම බොහෝ දුරට ඉඩ ඇති තත්වයක් පළමුවෙන්ම if ප්‍රකාශයකින් පැමිණීමට හේතුවකි. මෙය තවමත් සාධාරණ අදහසක් යන උපකල්පනය යටතේ (සහ යුගයේ වේගය ගැන සලකා බැලීමෙන් එකක් නොවේ). මුල් කේතය හොඳ ක්‍රමලේඛ පුහුණුවක් නොවන බව මම කියමි, විශේෂයෙන් ඒවා බොහෝ විට දෝෂ හැසිරවීම සඳහා භාවිතා නොකෙරේ යන කාරණය සැලකිල්ලට ගනිමින්, ඔබේ කේතය අසමත් නොවීමට වඩා අසමත් වීමට ඉඩ තිබේ නම් :-)

ඔබ ඉහත උපදෙස් පිළිපදින්නේ නම්, ඔබට එම ප්‍රතිලාභය ශ්‍රිතයේ පතුලේ තැබිය යුතුය, එවිට ඔබට එය නැවත එතැනට නොපැමිණිය හැක, දෝෂ කේතය සකසා පේළි දෙකක් එවන්න. එමගින් 1 ප්‍රවේශ 1 පිටවීමේ පරමාදර්ශය සාක්ෂාත් කර ගනී.

ඩෙල්ෆි විශේෂිත ...

මට කිසිදු සාක්ෂියක් නොමැති වුවද ඩෙල්ෆි ක්‍රමලේඛකයින් සඳහා මෙය හොඳ ක්‍රමලේඛ පුහුණුවක් බව මගේ මතකයේ තිබේ. පෙර-D2009, අපි අගය ආපසු පරමාණුක ආකාරයෙන් නැහැ, අපි exit;සහ result := foo;හෝ අපි ව්යතිරේක විසි විය.

ඔබට ආදේශ කිරීමට සිදු වූයේ නම්

if (true) {
 return foo;
} 

සදහා

if true then 
begin
  result := foo; 
  exit; 
end;

ඔබගේ සෑම කාර්යයකම ඉහළින්ම සිටින බව දැකීමෙන් ඔබට අසනීප විය හැකිය

if false then 
begin
  result := bar;

   ... 
end
else
   result := foo;

exitසම්පූර්ණයෙන්ම වළකින්න .

මම පහත ප්‍රකාශය සමඟ එකඟ වෙමි:

මම පුද්ගලිකව ආරක්ෂක වගන්තිවල රසිකයෙක් (දෙවන උදාහරණය) එය ශ්‍රිතයේ ඉන්ඩෙන්ටින් අඩු කරයි. සමහර අය ඒවාට අකමැති නිසා එය ශ්‍රිතයෙන් ප්‍රතිලාභ ලකුණු කිහිපයක් ලබා දෙයි, නමුත් එය ඔවුන් සමඟ වඩා පැහැදිලි යැයි මම සිතමි.

සිට ගෙන stackoverflow මේ ප්රශ්නය .

මම මේ දිනවල මුල් ප්‍රතිලාභ භාවිතා කරන්නේ අන්තයටම ය. මම මෙය ලියමි

self = [super init];

if (self != nil)
{
    // your code here
}

return self;

පරිදි

self = [super init];
if (!self)
    return;

// your code here

return self;

නමුත් එය ඇත්ත වශයෙන්ම වැදගත් නොවේ. ඔබේ කාර්යයන්හි කූඩු මට්ටම් එකක් හෝ දෙකකට වඩා තිබේ නම්, ඒවා බිඳ දැමිය යුතුය.

මම ලිවීමට කැමතියි:

if(someCondition)
{
    SomeFunction();
}

ඔබ මෙන්, මම සාමාන්‍යයෙන් පළමුවැන්න ලියමි, නමුත් අන්තිම එකට කැමතියි. මට කැදැලි චෙක්පත් ගොඩක් තිබේ නම් මම සාමාන්‍යයෙන් දෙවන ක්‍රමයට ප්‍රතික්‍රියා කරමි.

දෝෂ හැසිරවීම චෙක්පතෙන් ඉවතට ගෙන යන්නේ කෙසේදැයි මම කැමති නැත.

if not error A
  if not error B
    if not error C
      // do something
    else handle error C
  else handle error B
else handle error A

මම මේකට කැමතියි:

if error A
  handle error A; return
if error B
  handle error B; return
if error C
  handle error C; return

// do something

මුදුනේ ඇති කොන්දේසි "පූර්ව කොන්දේසි" ලෙස හැඳින්වේ. තැබීමෙන් if(!precond) return;, ඔබ සියලු පූර්ව කොන්දේසි දෘශ්‍යමය වශයෙන් ලැයිස්තුගත කරයි.

විශාල "if-else" බ්ලොක් භාවිතා කිරීමෙන් ඉන්ඩෙන්ට් ඉහළට වැඩි විය හැකිය (මට 3 මට්ටමේ ඉන්ඩෙන්ට්ස් පිළිබඳ උපුටා දැක්වීම අමතක විය).

ප්‍රකාශ කුඩා නම් තබා ගැනීමට මම කැමැත්තෙමි.

එබැවින්, අතර තෝරා ගැනීම:

if condition:
   line1
   line2
    ...
   line-n

හා

if not condition: return

line1
line2
 ...
line-n

මම ඔබ කලින් විස්තර කළ දේ තෝරා ගනිමි.

මතක තබා ගන්න, මම කලින් ලැබෙන ප්‍රතිලාභ හෝ වෙනත් කිසිවක් ගැන තැකීමක් නොකරමි, මම ඇත්තටම කැමතියි කේතය සරල කිරීමට, ප්‍රකාශයන්ගේ සිරුරු කෙටි කිරීමට යනාදිය.

කැදැල්ල නම් සහ තිබේ නම් සහ ඒවා භයානක වුවත් , ඒවා ඕනෑම වියදමකින් වළකින්න.

අනෙක් අය පවසන පරිදි එය රඳා පවතී. අගයන් ආපසු ලබා දෙන කුඩා කාර්යයන් සඳහා, මට මුල් ප්‍රතිලාභ කේත කළ හැකිය. නමුත් සැලකිය යුතු කාර්යයන් සඳහා, කේතයේ සෑම විටම ස්ථානයක් ලබා ගැනීමට මම කැමතියි, එය නැවත පැමිණීමට පෙර ක්‍රියාත්මක කළ හැකි යමක් තැබිය හැකි බව මම දනිමි.

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

බොහෝ විට පරීක්ෂා කරන ලද කොන්දේසි සඳහා, ඔබ AOP භාවිතා කරන්නේ නම් එම චෙක්පත් සඳහා අංශ ක්‍රියාත්මක කළ හැකිය.