නරක ක්‍රමලේඛන භාවිතයන් `බිඳීම 'සහ' දිගටම කරගෙන යාම 'ද?

මගේ ලොක්කා නරක ක්‍රමලේඛකයින් භාවිතා කරන බව breakසහ continueලූපවල සඳහන් කරයි.

මම ඒවා නිතරම භාවිතා කරන්නේ ඒවා අර්ථවත් වන බැවිනි; දේවානුභාවයෙන් ඔබට පෙන්වන්නම්:

function verify(object) {
    if (object->value < 0) return false;
    if (object->value > object->max_value) return false;
    if (object->name == "") return false;
    ...
}

මෙහි ඇති කාරණය නම්, පළමුව ශ්‍රිතය කොන්දේසි නිවැරදි දැයි පරික්ෂා කර සත්‍ය ක්‍රියාකාරිත්වය ක්‍රියාත්මක කිරීමයි. IMO ද ලූප සමඟ අදාළ වේ:

while (primary_condition) {
    if (loop_count > 1000) break;
    if (time_exect > 3600) break;
    if (this->data == "undefined") continue;
    if (this->skip == true) continue;
    ...
}

මම හිතන්නේ මෙය කියවීම පහසු කරයි & debug; නමුත් මමත් අවාසියක් දකින්නේ නැහැ.

වාරණයක් ආරම්භයේ දී භාවිතා කරන විට, පළමු චෙක්පත් සිදු කළ පරිදි, ඒවා පූර්ව කොන්දේසි ලෙස ක්‍රියා කරයි, එබැවින් එය හොඳයි.

බ්ලොක් මැද භාවිතා කරන විට, යම් කේතයක් වටා, ඒවා සැඟවුණු උගුල් මෙන් ක්‍රියා කරයි, එබැවින් එය නරක ය.

ව්‍යුහාත්මකව ප්‍රිය කරන විවිධ භාවිතයන් පිළිබඳව සාකච්ඡා කරන ඩොනල්ඩ් නූත්ගේ 1974 පුවත්පත් ව්‍යුහගත ක්‍රමලේඛනය ප්‍රකාශන වෙත ගොස් ඔබට කියවිය හැකිය go to. ඒවාට සමාන breakහා continueප්‍රකාශ ඇතුළත් වේ (එහි ඇති බොහෝ භාවිතයන් go toවඩා සීමිත ඉදිකිරීම් දක්වා වර්ධනය කර ඇත). ඔබේ ලොක්කා නුත් නරක ක්‍රමලේඛකයෙකු ලෙස හැඳින්විය හැකිද?

(උදාහරණ පොලී මට ලබා දී ඇත. සාමාන්යයෙන්, breakසහ continueඑක් ඇතුළු වීම හා කේතය ඕනෑම කෑල්ලක් එක් කලහොත්, සහ පුද්ගලයා ඒ ආකාරයේ ද බහු මත ගෙඩිත් වැනි අය විසින් අප්රිය returnප්රකාශ.)

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

ඔබේ ක්‍රියාකාරිත්වය දිගු නම් සහ ඔබට බහු කැදැලි ලූප තිබේ නම් මෙය යම් අර්ථයක් ලබා දෙයි. කෙසේ වෙතත්, ඔබේ කාර්යයන් කෙටි විය යුතු අතර, ඔබ ලූප සහ ඒවායේ සිරුරු ඔවුන්ගේම කෙටි කාර්යයන් සඳහා ඔතා තිබිය යුතුය. සාමාන්‍යයෙන්, ශ්‍රිතයකට තනි පිටවීමේ ලක්ෂ්‍යයක් ඇති කර ගැනීමට බල කිරීම ඉතා සංක්ෂිප්ත තර්කනයකට හේතු විය හැක.

ඔබේ ක්‍රියාකාරිත්වය ඉතා කෙටි නම්, ඔබට තනි පුඩුවක් තිබේ නම්, හෝ නරකම කැදැලි දෙකක් තිබේ නම්, සහ ලූප ශරීරය ඉතා කෙටි නම්, a breakහෝ a continueකරන්නේ කුමක්ද යන්න ඉතා පැහැදිලිය . බහුවිධ returnප්‍රකාශයන් කරන්නේ කුමක්ද යන්නත් පැහැදිලිය .

රොබට් සී. මාටින් විසින් "පිරිසිදු කේතය" සහ මාටින් ෆෝලර් විසින් "ප්‍රතිනිර්මාණය කිරීම" යන කරුණු වලදී මෙම ගැටළු විසඳනු ලැබේ.

නරක ක්‍රමලේඛකයින් නිරපේක්ෂව කථා කරයි (සිත් මෙන්). හොඳ ක්‍රමලේඛකයින් හැකි පැහැදිලි විසඳුම භාවිතා කරයි ( අනෙක් සියල්ල සමාන වේ ).

විවේකය සහ නිතර භාවිතා කිරීම කේතය අනුගමනය කිරීම දුෂ්කර කරයි. නමුත් ඒවා ප්‍රතිස්ථාපනය කිරීමෙන් කේතය අනුගමනය කිරීම වඩාත් අපහසු වේ නම් එය නරක වෙනසක් වේ.

ඔබ දුන් ආදර්ශය නිසැකවම බිඳීම් සහ අඛණ්ඩව ප්‍රතිස්ථාපනය කළ යුතු තත්වයකි.

හැසිරීම පහසුවෙන් පුරෝකථනය කළ නොහැකි නිසා බොහෝ අය සිතන්නේ එය නරක අදහසක් බවයි. ඔබ කේතය කියවන විට සහ while(x < 1000){}x> = 1000 වන තෙක් එය ක්‍රියාත්මක වනු ඇතැයි ඔබ සිතන්නේ නම් ... නමුත් මැද විවේක තිබේ නම් එය සත්‍යයක් නොවේ, එබැවින් ඔබට ඔබේ විශ්වාස කළ නොහැක ලූප් ...

මිනිසුන් GOTO ට අකමැති එකම හේතුව එයයි: නිසැකවම, එය හොඳින් භාවිතා කළ හැකිය, නමුත් එය දේවභක්තික ස්පැගටි කේතයට ද හේතු විය හැක, එහිදී කේතය අහඹු ලෙස කොටසේ සිට අංශයට පැනේ.

මට නම්, මම එක කොන්දේසියකට වඩා වැඩි ගණනක් බිඳ දැමූ ලූපයක් කිරීමට යන්නේ නම්, මම පිටතට යාමට while(x){}අවශ්‍ය වූ විට X ව්‍යාජ ලෙස ටොගල් කරන්නෙමි. අවසාන ප්‍රති result ලය සමාන වනු ඇති අතර, කේතය කියවන ඕනෑම කෙනෙකුට X හි අගය වෙනස් කළ දේවල් දෙස වඩාත් සමීපව බැලීමට දැන ගත හැකිය.

ඔව්, ඔබට විවේක ප්‍රකාශයකින් තොරව වැඩසටහන් නැවත ලිවිය හැකිය (නැතහොත් එකම දේ කරන ලූප මැද සිට ආපසු). නමුත් ඔබට අතිරේක විචල්‍යයන් සහ / හෝ කේත අනුපිටපත් හඳුන්වා දීමට සිදුවනු ඇත, මේ දෙකම සාමාන්‍යයෙන් වැඩසටහන තේරුම් ගැනීමට අපහසු වේ. පැස්කල් (ක්‍රමලේඛන භාෂාව) විශේෂයෙන් ආරම්භක ක්‍රමලේඛකයින්ට එම හේතුව නිසා ඉතා නරක විය. ඔබේ ලොක්කාට මූලිකවම අවශ්‍ය වන්නේ ඔබ පැස්කල්ගේ පාලන ව්‍යුහයන් තුළ වැඩසටහන්ගත කිරීමයි. ලිනස් ටොවල්ඩ්ස් ඔබේ සපත්තු තුළ සිටියා නම්, ඔහු බොහෝ විට ඔබේ ලොක්කාට මැද ඇඟිල්ල පෙන්වනු ඇත!

කොසරාජුගේ පාලන ව්‍යුහයන්ගේ ධූරාවලිය නමින් පරිගණක විද්‍යා ප්‍රති result ලයක් ඇත, එය 1973 තරම් and ත අතීතයේ සිට 1974 සිට ගොත් පිළිබඳ නූත්ගේ (තවත්) ප්‍රසිද්ධ පුවත්පතේ සඳහන් වේ. (මෙම නුත් පත්‍රය දැනටමත් ඩේවිඩ් තෝර්න්ලි විසින් නිර්දේශ කර ඇත. .) එස්. රාඕ කොසරාජු 1973 දී ඔප්පු කළ දෙය නම්, අතිරේක විචල්‍යයන් හඳුන්වා නොදී n ට වඩා අඩු බිඳීම් ගැඹුර සහිත වැඩසටහන් වලට ගැඹුර n හි බහු මට්ටමේ බිඳීම් ඇති සියලුම වැඩසටහන් නැවත ලිවිය නොහැකි බවයි . නමුත් එය හුදු න්‍යායාත්මක ප්‍රති .ලයක් පමණක් යැයි කියමු. (අමතර විචල්‍යයන් කිහිපයක් එකතු කරන්න ?! ඔබේ ලොක්කා සතුටු කිරීම සඳහා ඔබට එය කළ හැකිය ...)

මෘදුකාංග ඉංජිනේරු දෘෂ්ටි කෝණයකින් වඩා වැදගත් වන්නේ 1995 දී එරික් එස්. රොබට්ස් විසින් ලූප් පිටවීම් සහ ව්‍යුහගත වැඩසටහන්කරණය: විවාදය නැවත විවෘත කිරීම ( http://cs.stanford.edu/people/eroberts/papers/SIGCSE- 1995 / LoopExits.pdf ). තමාට පෙර සිටි අය විසින් කරන ලද ආනුභවික අධ්‍යයන කිහිපයක් රොබට්ස් සාරාංශ කරයි. නිදසුනක් ලෙස, CS101 වර්ගයේ සිසුන් කණ්ඩායමක් අරාවෙහි අනුක්‍රමික සෙවුමක් ක්‍රියාත්මක කරන ශ්‍රිතයක් සඳහා කේත ලිවීමට ඉල්ලා සිටි විට, අධ්‍යයනයේ කතුවරයා පහත සඳහන් පරිදි, පිටවීම සඳහා විවේකයක් / ආපසු / ගොටෝ භාවිතා කළ සිසුන් ගැන මූලද්රව්යය සොයාගත් විට අනුක්රමික සෙවුම් ලූපය:

වැරදි විසඳුමක් ඉදිරිපත් කළ [මෙම විලාසය] භාවිතා කරමින් වැඩසටහනකට උත්සාහ කළ තනි පුද්ගලයෙකු මට තවම හමු වී නැත.

රොබට්ස් ද එසේ පවසයි:

ෆෝ ලූපයෙන් පැහැදිලි ප්‍රතිලාභයක් ලබා නොගෙන ගැටලුව විසඳීමට උත්සාහ කළ සිසුන්ට වඩා හොඳ ප්‍රති ared ල ලැබුණි: මෙම උපාය මාර්ගයට උත්සාහ කළ සිසුන් 42 දෙනාගෙන් හත් දෙනෙකු පමණක් නිවැරදි විසඳුම් ජනනය කිරීමට සමත් විය. එම අගය 20% ට වඩා අඩු සාර්ථකත්ව අනුපාතයක් නියෝජනය කරයි.

ඔව්, ඔබ CS101 සිසුන්ට වඩා පළපුරුදු විය හැකිය, නමුත් විවේක ප්‍රකාශය භාවිතා නොකර (හෝ ඒ හා සමානව ලූප මැදින් ආපසු පැමිණීම / ගොටෝ), අවසානයේදී ඔබ කේතයක් ලියනු ඇත නාමික වශයෙන් මනාව ව්‍යුහගතව තිබියදී අමතර තර්කනය අනුව හිසකෙස් ඇති බව ඔබේ ලොක්කාගේ කේතීකරණ විලාසය අනුගමනය කිරීමට උත්සාහ කරන අතරතුර යමෙකු, බොහෝ විට ඔබ විසින්ම තාර්කික දෝෂ ඇති කරන විචල්‍යයන් සහ කේත අනුපිටපත් කිරීම.

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

මෙම නරක භාවිතයන්ගෙන් එකක් හෝ භාවිතා කිරීම ගැන මම නොසිතමි, නමුත් එකම ලූපයක් තුළ ඒවා ඕනෑවට වඩා භාවිතා කිරීම මඟින් ලූපයේ භාවිතා වන තර්කනය ගැන නැවත සිතා බැලිය යුතුය. ඒවා අරපිරිමැස්මෙන් භාවිතා කරන්න.

ඔබ දුන් ආදර්ශයට විවේකයක් හෝ ඉදිරියට යාමට අවශ්‍ය නැත:

while (primary-condition AND
       loop-count <= 1000 AND
       time-exec <= 3600) {
   when (data != "undefined" AND
           NOT skip)
      do-something-useful;
   }

ඔබේ උදාහරණයේ ඇති පේළි 4 සමඟ ඇති මගේ 'ගැටලුව' නම්, ඒවා සියල්ලම එකම මට්ටමක පවතින නමුත් ඒවා වෙනස් දේ කරයි: සමහර බිඳීම්, සමහරක් දිගටම ... ඔබ එක් එක් පේළිය කියවිය යුතුය.

මගේ කැදැලි ප්‍රවේශය තුළ, ඔබ වඩාත් ගැඹුරට යන විට, කේතය වඩාත් 'ප්‍රයෝජනවත්' වේ.

එහෙත්, ගැඹුරින් ඔබ ලූපය නැවැත්වීමට හේතුවක් සොයා ගනී නම් (ප්‍රාථමික තත්වය හැර), විවේකයක් හෝ නැවත පැමිණීම එහි භාවිතය සඳහා හේතු වේ. ඉහළ මට්ටමේ තත්වයේදී පරීක්ෂා කළ යුතු අතිරේක ධජයක් භාවිතා කිරීමට වඩා මම කැමතියි. විවේකය / ආපසු පැමිණීම වඩාත් සෘජු ය; එය තවත් විචල්‍යයක් සැකසීමට වඩා අභිප්‍රාය ප්‍රකාශ කරයි.

"නරකකම" රඳා පවතින්නේ ඔබ ඒවා භාවිතා කරන ආකාරය මත ය. ඇල්ගොරිතමයක් නැවත ප්‍රතිනිර්මාණය කිරීමෙන් සුරැකිය නොහැකි චක්‍රයන් ඉතිරි කරන විට මම සාමාන්‍යයෙන් ලූප ඉදිකිරීම් වල විවේක භාවිතා කරමි. නිදසුනක් ලෙස, නිශ්චිත දේපලක වටිනාකමක් ඇති අයිතමයක් සත්‍ය ලෙස සකසා ඇති එකතුවක් හරහා පාපැදි පැදීම. ඔබ දැනගත යුතු සියල්ල නම්, එක් අයිතමයක් මෙම දේපල සත්‍ය ලෙස සකසා ඇත්නම්, ඔබ එම ප්‍රති result ලය ලබා ගත් පසු, නිසි පරිදි ලූපය අවසන් කිරීම සඳහා විවේකයක් හොඳයි.

විවේකයක් භාවිතා කිරීමෙන් කේතය කියවීමට පහසු නොවනු ඇත, සැලකිය යුතු ආකාරයකින් සැකසීමේදී චක්‍ර ධාවනය කිරීමට හෝ සුරැකීමට කෙටි නොවේ නම්, ඒවා භාවිතා නොකිරීම වඩාත් සුදුසුය. මා අනුගමනය කරන ඕනෑම කෙනෙකුට මගේ කේතය පහසුවෙන් බැලීමට සහ සිදුවන්නේ කුමක්දැයි සොයා ගැනීමට හැකි බව සහතික කර ගැනීමට හැකි සෑම විටම මම "අඩුම පොදු හරයට" කේත කිරීමට නැඹුරු වෙමි (මම මෙය සැමවිටම සාර්ථක නොවේ). අමුතු පිවිසුම් / පිටවීමේ ස්ථාන හඳුන්වා දෙන නිසා විවේක එය අඩු කරයි. අනිසි ලෙස භාවිතා කිරීමෙන් ඔවුන්ට "ගොටෝ" ප්‍රකාශය මෙන් හැසිරිය හැකිය.

නියත වශයෙන්ම නැත ... ඔව් භාවිතය gotoනරක ය, මන්ද එය ඔබගේ වැඩසටහනේ ව්‍යුහය පිරිහීමට ලක්වන අතර පාලන ප්‍රවාහය තේරුම් ගැනීම ද දුෂ්කර ය.

නමුත් ප්රකාශ භාවිතය කැමති breakසහ continueමේ දින පරම අවශ්ය සියලු නරක වැඩසටහන් පුහුණු ලෙස සැලකුවේ නැත.

ද භාවිතා දී පාලනය ගලා අවබෝධ කර ගැනීමට අපහසු නොවන බව breakසහ continue. වැනි නිර්මාණය කරන දී switchමෙම breakප්රකාශය පරම අවශ්ය වේ.

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

අර්ධ වශයෙන්, මෙම දුෂ්කරතාවයෙන් පිළිබිඹු වන්නේ ඔබේ කේතය පිළිබඳව සංකල්පමය වශයෙන් තර්ක කිරීමට හැකි වීමයි.

අවංකවම, ඔබේ දෙවන කේතය පැහැදිලි නැත. එය කරන්නේ කුමක්ද? දිගටම 'ඉදිරියට' යනවාද, නැතහොත් එය 'ඊළඟ' ලූපයද? මට අදහසක් නැහැ. අවම වශයෙන් ඔබේ පළමු උදාහරණය පැහැදිලි ය.

මම ඔබේ දෙවන කේත ස්නිපටය ආදේශ කරමි

while (primary_condition && (loop_count <= 1000 && time_exect <= 3600)) {
    if (this->data != "undefined" && this->skip != true) {
        ..
    }
}

නොසන්සුන්තාවයේ කිසිදු හේතුවක් නිසා නොවේ - ඇත්ත වශයෙන්ම මම සිතන්නේ මෙය කියවීමට පහසු වන අතර සිදුවන්නේ කුමක්ද යන්න යමෙකුට තේරුම් ගත හැකිය. පොදුවේ ගත් කල, ඔබේ ලූප සඳහා කොන්දේසි ශරීරය පුරා පැටලී නැති එම ලූප තත්වයන් තුළ පමණක් අඩංගු විය යුතුය. කෙසේ වෙතත් කියවීමේ හැකියාව සඳහා breakසහ continueඋපකාර කළ හැකි අවස්ථා කිහිපයක් තිබේ. මා එකතු කළ හැකි breakප්‍රමාණයට වඩා continue: ඩී

මම ඔබේ ලොක්කා සමඟ එකඟ නොවෙමි. සඳහා නිසි ස්ථාන ඇත breakහා continueභාවිතා කිරීමට. ඇත්ත වශයෙන්ම නවීන ක්‍රමලේඛන භාෂාවන්ට ව්‍යතිරේකයන් සහ ව්‍යතිරේක හැසිරවීම් හඳුන්වා දීමට හේතුව නම් ඔබට සෑම ගැටලුවක්ම සාධාරණ ලෙස භාවිතා කළ නොහැකි structured techniquesවීමයි.

පැත්තක සටහනක මට මෙහි ආගමික සාකච්ඡාවක් ආරම්භ කිරීමට අවශ්‍ය නැති නමුත් ඔබේ කේතය මේ ආකාරයෙන් කියවිය හැකි පරිදි ප්‍රතිව්‍යුහගත කළ හැකිය:

while (primary_condition) {
    if (loop_count > 1000) || (time_exect > 3600) {
        break;
    } else if ( ( this->data != "undefined") && ( !this->skip ) ) {
       ... // where the real work of the loop happens
    }
}

තවත් පැත්තක සටහනක

මම ( flag == true )දැනටමත් කොන්දේසි සහිතව භාවිතා කිරීමට අකමැතියි, මන්ද විචල්‍යය දැනටමත් බූලියන් නම්, ඔබ බූලියන් වල වටිනාකමට අවශ්‍ය පිළිතුර ඇති විට සිදුවිය යුතු අතිරේක සංසන්දනයක් ඔබ හඳුන්වා දෙයි - ඇත්ත වශයෙන්ම ඔබේ සම්පාදකයාට එය විශ්වාස කළ නොහැකි නම් එම අමතර සංසන්දනය දුරස් කරන්න.

මම ඔබේ ලොක්කා සමඟ එකඟ වෙමි. ඉහළ චක්‍රීය සංකීර්ණතාවයකින් යුත් ක්‍රම නිපදවන බැවින් ඒවා නරක ය. එවැනි ක්රම කියවීමට අපහසු වන අතර පරීක්ෂා කිරීමට අපහසු වේ. වාසනාවකට පහසු විසඳුමක් තිබේ. ලූප් බොඩි වෙනම ක්‍රමයකට නිස්සාරණය කරන්න, එහිදී “ඉදිරියට” “ආපසු” යයි. "නැවත පැමිණීම" වඩා හොඳ වන්නේ "ආපසු" ගිය පසු එය අවසන් වී ඇති හෙයිනි - ප්‍රාදේශීය රාජ්‍යය ගැන කරදරයක් නැත.

"බිඳීම" සඳහා ලූපය වෙනම ක්‍රමයකට උකහා ගන්න, "විවේකය" වෙනුවට "ආපසු" යන්න.

උපුටා ගත් ක්‍රමවලට තර්ක විශාල සංඛ්‍යාවක් අවශ්‍ය නම්, එය පන්තියක් උපුටා ගැනීම සඳහා ඇඟවීමකි - එක්කෝ ඒවා සන්දර්භය වස්තුවකට එකතු කරන්න.

මම හිතන්නේ එය ගැටළුවක් වන්නේ බහුවිධ වළලු තුළ ගැඹුරින් කූඩු කළ විට පමණි. ඔබ කුමන ලූපයකට කැඩී ඇත්දැයි දැන ගැනීම දුෂ්කර ය. දිගටම කරගෙන යාමද දුෂ්කර විය හැකිය, නමුත් මම සිතන්නේ සැබෑ වේදනාව පැමිණෙන්නේ විවේකයෙන් - තර්කනය අනුගමනය කිරීමට අපහසු විය හැකිය.

පහත දැක්වෙන උදාහරණයේ දී මෙන් වෙස්වළාගත් ගොටෝ ලෙස ඒවා භාවිතා නොකරන තාක් කල්:

do
{
      if (foo)
      {
             /*** code ***/
             break;
      }

      if (bar)
      {
             /*** code ***/
             break;
      }
} while (0);

මම ඔවුන් සමඟ හොඳින්. (නිෂ්පාදන කේතයේ දැක්වෙන උදාහරණය, ​​මෙහ්)

මම මේ විලාසිතාවන්ටවත් කැමති නැහැ. මෙන්න මම කැමති දේ:

function verify(object)
{
    if not (object->value < 0) 
       and not(object->value > object->max_value)
       and not(object->name == "") 
       {
         do somethign important
       }
    else return false; //probably not necessary since this function doesn't even seem to be defined to return anything...?
}

returnශ්‍රිතයක් නවතා දැමීමට භාවිතා කිරීමට මම ඇත්තටම කැමති නැත . එය අපයෝජනයක් ලෙස දැනේ return.

භාවිතා breakකිරීම සැමවිටම කියවීමට පැහැදිලි නැත.

වඩා හොඳ තවමත් විය හැකිය:

notdone := primarycondition    
while (notDone)
{
    if (loop_count > 1000) or (time_exect > 3600)
    {
       notDone := false; 
    }
    else
    { 
        skipCurrentIteration := (this->data == "undefined") or (this->skip == true) 

        if not skipCurrentIteration
        {
           do something
        } 
        ...
    }
}

අඩු කැදැල්ල සහ සංකීර්ණ තත්වයන් විචල්‍යයන් බවට ප්‍රතිනිර්මාණය වේ (සැබෑ වැඩසටහනකදී ඔබට වඩා හොඳ නම් තිබිය යුතුය, පැහැදිලිවම ...)

(ඉහත කේත සියල්ලම ව්‍යාජ කේත වේ)

නැත. එය ගැටළුවක් විසඳීමට ක්‍රමයක් වන අතර එය විසඳීමට වෙනත් ක්‍රම තිබේ.

බොහෝ වර්තමාන ප්‍රධාන ධාරාවේ භාෂා (ජාවා, .නෙට් (සී # + වීබී), පීඑච්පී, ඔබේම දෑ ලියන්න) ලූප මඟ හැරීම සඳහා "බිඳීම" සහ "දිගටම" භාවිතා කරන්න. ඔවුන් දෙදෙනාම "ව්‍යුහගත ගොටෝ (ය)" වාක්‍ය.

ඔවුන් නොමැතිව:

String myKey = "mars";

int i = 0; bool found = false;
while ((i < MyList.Count) && (not found)) {
  found = (MyList[i].key == myKey);
  i++;   
}
if (found)
  ShowMessage("Key is " + i.toString());
else
  ShowMessage("Not found.");

ඔවුන් සමග:

String myKey = "mars";

for (i = 0; i < MyList.Count; i++) {
  if (MyList[i].key == myKey)
    break;
}
ShowMessage("Key is " + i.toString());

"බිඳීම" සහ "ඉදිරියට" කේතය කෙටි වන අතර සාමාන්‍යයෙන් "වාක්‍ය" සඳහා "හෝ" හෝ "පුරෝකථනය" වාක්‍ය බවට හැරෙන බව සලකන්න.

මෙම අවස්ථා දෙකම කේතීකරණ විලාසය පිළිබඳ කාරණයකි. මම ඒවා භාවිතා නොකිරීමට කැමැත්තෙමි , මන්ද වාචික විලාසය මට කේතය වැඩි පාලනයක් ලබා ගැනීමට ඉඩ සලසයි.

මම ඇත්ත වශයෙන්ම, සමහර ව්‍යාපෘතිවල වැඩ කරමි, එහිදී එම වාක්‍ය භාවිතා කිරීම අනිවාර්ය විය.

සමහර සංවර්ධකයින් සිතන්නේ ඔවුන් නෙක්සරිලි නොවන බවයි, නමුත් උපකල්පිතයි, අපට ඒවා ඉවත් කිරීමට සිදු වූවා නම්, අපට "අතර" සහ "අතරතුර" ඉවත් කිරීමට සිදු වේ ("පැස්කල් යාලුවනේ)";

නිගමනය, මම ඒවා භාවිතා නොකිරීමට කැමති වුවද, මම හිතන්නේ එය විකල්පයක් මිස නරක ක්‍රමලේඛ පුහුණුවක් නොවේ.

මම විරුද්ධ continueහා breakප්‍රතිපත්තිමය වශයෙන් නොවේ, නමුත් මම සිතන්නේ ඒවා ඉතා පහත් මට්ටමේ ඉදිකිරීම් වන අතර ඒවා බොහෝ විට ඊටත් වඩා හොඳ දෙයක් මගින් ප්‍රතිස්ථාපනය කළ හැකිය.

මම මෙහි නිදසුනක් ලෙස C # භාවිතා කරමි, එකතුවක් හරහා නැවත කියවීමට අවශ්‍ය අවස්ථාව සලකා බලන්න, නමුත් අපට අවශ්‍ය වන්නේ යම් පුරෝකථනයක් ඉටු කරන මූලද්‍රව්‍යයන් පමණක් වන අතර උපරිම පුනරාවර්තන 100 කට වඩා වැඩි ප්‍රමාණයක් කිරීමට අපට අවශ්‍ය නැත.

for (var i = 0; i < collection.Count; i++)
{
    if (!Predicate(item)) continue;
    if (i >= 100) break; // at first I used a > here which is a bug. another good thing about the more declarative style!

    DoStuff(item);
}

මෙය පිරිසිදු ලෙස පෙනේ. එය තේරුම් ගැනීම එතරම් අපහසු නැත. මම හිතන්නේ එය වඩා ප්‍රකාශිත වුවත් බොහෝ දේ ලබා ගැනීමට හැකි වනු ඇත. එය පහත සඳහන් දෑ සමඟ සසඳන්න:

foreach (var item in collection.Where(Predicate).Take(100))
    DoStuff(item);

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

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

කේත සම්පුර්ණ කිරීම භාවිතා කිරීම පිළිබඳ හොඳ අංශයක් gotoසහ සාමාන්‍ය හෝ ලූප වලින් බහු ප්‍රතිලාභ ඇත.

පොදුවේ එය නරක පුරුද්දක් නොවේ. breakනැතහොත් continueඊළඟට කුමක් සිදුවේදැයි හරියටම කියන්න. මම මේකට එකඟයි.

විවිධ gotoප්‍රකාශ භාවිතා කිරීමේ වාසි පෙන්වීමට ස්ටීව් මැක්කොනෙල් (කේත සම්පුර්ණ කතුවරයා) ඔබ හා සමාන උදාහරණ භාවිතා කරයි .

කෙසේ වෙතත්, අධික ලෙස භාවිතා කිරීම breakහෝ continueසංකීර්ණ හා හඳුනාගත නොහැකි මෘදුකාංගයකට තුඩු දිය හැකිය.