স্পষ্টভাবে কোনও ফাংশনে রিটার্ন কল করুন বা না করুন

Question

কিছুক্ষণ আগেই আমি সি কর্ণ টিম (আমার বিশ্বাস) থেকে কোনও ব্যবহারকারীকে returnকোনও ফাংশন শেষে স্পষ্টভাবে কল করার জন্য সুপারিশ করার জন্য সাইমন আরবানেক তাকে তিরস্কার করেছিল (তার মন্তব্যটি মুছে ফেলা হয়েছিল):

foo = function() {
  return(value)
}

পরিবর্তে তিনি সুপারিশ করেছেন:

foo = function() {
  value
}

সম্ভবত এই জাতীয় পরিস্থিতিতে এটি প্রয়োজন:

foo = function() {
 if(a) {
   return(a)
 } else {
   return(b)
 }
}

তার মন্তব্যটি returnকঠোরভাবে প্রয়োজন না হলে কল করা কেন ভাল জিনিস তা সম্পর্কে কিছুটা আলোকপাত করেছে , তবে এটি মুছে ফেলা হয়েছিল।

আমার প্রশ্ন হ'ল: কেন returnদ্রুত বা আরও ভাল কল করা হচ্ছে না এবং এইভাবে ভাল?

Comments

returnএমনকি শেষ উদাহরণে অপ্রয়োজনীয়। অপসারণ returnএটি আরও দ্রুততর করে তুলতে পারে, তবে আমার মতে এটি হ'ল কারণ বলা হয় যে একটি মজাদার প্রোগ্রামিং ভাষা।

— কোহসকে

@ কোহস্কে আপনার মন্তব্যটি উত্তরের জন্য কীভাবে এটি আরও দ্রুত করা যায় এবং আরও কীভাবে এটি কার্যকরী প্রোগ্রামিং ভাষা হওয়ার সাথে আর সম্পর্কিত?

— পল হিমস্ট্র্রা

returnস্থানীয়-অ-স্থানীয় লাফ প্রেরণা দেয় এবং এফপির পক্ষে সুস্পষ্ট অ-স্থানীয় লাফ অস্বাভাবিক। প্রকৃতপক্ষে, উদাহরণস্বরূপ, স্কিমটি নেই return। আমি মনে করি উত্তর হিসাবে আমার মন্তব্য খুব ছোট (এবং সম্ভবত ভুল)।

— কোহসকে

এফ # নেই return, break, continueযা ক্লান্তিকর কখনও কখনও হয়।

— কলিনফ্যাং

Answer 1

প্রশ্ন ছিল: কেন (সুস্পষ্টভাবে) কলটি দ্রুত বা ভালতর নয় এবং এভাবে অগ্রাধিকারযোগ্য?

আর ডকুমেন্টেশনে এ জাতীয় ধারণা গ্রহণের কোনও বিবৃতি নেই।
মূল পৃষ্ঠা? 'ফাংশন' বলেছেন:

function( arglist ) expr
return(value)

ফিরতি কল না করে কি দ্রুত?

উভয় function()এবং return()আদিম ফাংশন এবং function()নিজেই ফাংশন অন্তর্ভুক্ত না করে শেষ মূল্যায়িত মান ফেরত return()দেয়।

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

bench_nor2 <- function(x,repeats) { system.time(rep(
# without explicit return
(function(x) vector(length=x,mode="numeric"))(x)
,repeats)) }

bench_ret2 <- function(x,repeats) { system.time(rep(
# with explicit return
(function(x) return(vector(length=x,mode="numeric")))(x)
,repeats)) }

maxlen <- 1000
reps <- 10000
along <- seq(from=1,to=maxlen,by=5)
ret <- sapply(along,FUN=bench_ret2,repeats=reps)
nor <- sapply(along,FUN=bench_nor2,repeats=reps)
res <- data.frame(N=along,ELAPSED_RET=ret["elapsed",],ELAPSED_NOR=nor["elapsed",])

# res object is then visualized
# R version 2.15

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

রিটার্ন কল না করে কি ভাল?

Return কোডের "পাতাগুলি" স্পষ্টভাবে ডিজাইনের জন্য ভাল সরঞ্জাম যেখানে রুটিনটি শেষ হওয়া উচিত, ফাংশনটি থেকে ঝাঁপিয়ে পড়ুন এবং মানটি ফেরান।

# here without calling .Primitive('return')
> (function() {10;20;30;40})()
[1] 40
# here with .Primitive('return')
> (function() {10;20;30;40;return(40)})()
[1] 40
# here return terminates flow
> (function() {10;20;return();30;40})()
NULL
> (function() {10;20;return(25);30;40})()
[1] 25
> 

এটি প্রোগ্রামারটির কৌশল এবং প্রোগ্রামিং শৈলীর উপর নির্ভর করে যে তিনি কোন স্টাইলটি ব্যবহার করেন, তিনি কোনও রিটার্ন () ব্যবহার করতে পারবেন না কারণ এটি প্রয়োজন হয় না।

আর কোর প্রোগ্রামার উভয় পন্থা ব্যবহার করে। সুস্পষ্ট রিটার্ন সহ এবং ছাড়াই () হিসাবে এটি 'বেস' ফাংশনের উত্সগুলিতে সন্ধান করা সম্ভব।

বেশিরভাগ সময় ফাংশনটি বিনয়ীভাবে বন্ধ করার জন্য কেবল পুনরায় () কোনও যুক্তি নেই N

এটি ব্যবহারকারীর বা বিশ্লেষকরা আর ব্যবহার করে প্রকৃত পার্থক্যটি দেখতে না পারলে আরও ভাল কিনা তা পরিষ্কার নয়।

আমার মতামতটি হল যে প্রশ্নটি হওয়া উচিত: আর বাস্তবায়ন থেকে স্পষ্টত রিটার্ন ব্যবহার করার কোনও বিপদ আছে কি?

অথবা, হয়তো ভাল, ব্যবহারকারী লেখা ফাংশন কোড সবসময় জিজ্ঞেস করা উচিত: মধ্যে প্রভাব কি না স্পষ্ট আগমন ব্যবহার (বা বস্তুর কোড স্থাপন শাখার শেষ পাতা যেমন ফেরত পাঠানো পর্যন্ত) ফাংশন কোডে?

Comments

খুব ভাল উত্তরের জন্য ধন্যবাদ। আমি বিশ্বাস করি যে ব্যবহারে কোনও বিপদ নেই return, এবং এটি প্রোগ্রামারটি ব্যবহার করবেন কিনা তা তার পছন্দকেই নেমে আসে।

— পল হিমস্ট্র্রা

গতিটি returnআপনার পক্ষে চিন্তিত হওয়া উচিত really

— হ্যাডলি

আমি মনে করি এটি একটি খারাপ উত্তর। কারণগুলি অপ্রয়োজনীয় returnফাংশন কলগুলি ব্যবহারের মূল্যের এক মৌলিক মতবিরোধে নেমে আসে । আপনার যে প্রশ্নটি জিজ্ঞাসা করা উচিত তা হ'ল শেষে আপনি প্রস্তাব করেছেন। পরিবর্তে, এটা হল: "কেন উচিত আমি একজন অপ্রয়োজনীয় ব্যবহার return? এটি কোন উপকার সরবরাহ করে? ” দেখা যাচ্ছে যে, উত্তরটি "খুব বেশি নয়", এমনকি "যা কিছুই নয়"। আপনার উত্তর এটি প্রশংসা করতে ব্যর্থ।

— কনরাড রুডলফ

@ কনরাড রুডল্ফ ... আপনি বাস্তবে পুনরাবৃত্তি করেছিলেন যে পল মূলত যা জিজ্ঞাসা করেছিলেন (কেন স্পষ্ট প্রত্যাবর্তন খারাপ)। এবং আমি সঠিক (সবার জন্য এক অধিকার) উত্তরটিও জানতে চাই :)। আপনি কি এই সাইটের ব্যবহারকারীদের জন্য আপনার ব্যাখ্যা প্রদান বিবেচনা করেন?

— পেটর মতাউসু

@ ডেসন আমি অন্য কোথাও একটি রেডডিট পোস্ট যুক্ত করেছি যেখানে এই যুক্তিটি এই প্রসঙ্গে ত্রুটিযুক্ত তা ব্যাখ্যা করে। দুর্ভাগ্যক্রমে মন্তব্যটি প্রতিবার স্বয়ংক্রিয়ভাবে মুছে ফেলা হবে বলে মনে হচ্ছে। সংক্ষিপ্ত সংস্করণটি হ'ল returnএকটি স্পষ্ট মন্তব্যের মতো যা কোডের কিছু অংশের পাশে "ইনক্রিমেন্ট এক্স দ্বারা 1" বলে x = x + 2। অন্য কথায়, এর স্পষ্ট সাক্ষ্যদান হ'ল (ক) সম্পূর্ণ অপ্রাসঙ্গিক এবং (খ) এটি ভুল তথ্য জানায় । কারণ returnআর এর শব্দার্থবিজ্ঞানগুলি হ'ল বিশুদ্ধভাবে "এই ফাংশনটি বাতিল করুন" ” এর অর্থ অন্য ভাষার মতো একই নয়return ।

— কনরাড রুডল্ফ

Answer 2

সবাই যদি তাতে একমত হয়

1. return একটি ফাংশন এর শরীরের শেষে প্রয়োজন হয় না
2. ব্যবহার না করা returnপ্রান্তিকভাবে দ্রুত (@ অ্যালানের পরীক্ষার মতে, ৪.৩ মাইক্রোসেকেন্ড বনাম ৫.১)

returnএকটি ফাংশন শেষে আমাদের সকলের ব্যবহার বন্ধ করা উচিত ? আমি অবশ্যই করব না, এবং আমি কেন তা ব্যাখ্যা করতে চাই। আমি আশা করি অন্য লোকেরা আমার মতামতটি ভাগ করে নিলে hear এবং আমি যদি ক্ষমাপ্রার্থনা করি তবে এটি যদি ওপির সরাসরি উত্তর না হয় তবে দীর্ঘতর বিষয়গত মন্তব্যের মতোই হয়।

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

পল এই উদাহরণটি ব্যবহার করেছেন:

foo = function() {
 if(a) {
   return(a)
 } else {
   return(b)
 }
}

দুর্ভাগ্যক্রমে, কেউ উল্লেখ করতে পারে যে এটি সহজেই আবার লিখিত হতে পারে:

foo = function() {
 if(a) {
   output <- a
 } else {
   output <- b
 }
output
}

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

bar <- function() {
   while (a) {
      do_stuff
      for (b) {
         do_stuff
         if (c) return(1)
         for (d) {
            do_stuff
            if (e) return(2)
         }
      }
   }
   return(3)
}

একক রিটার্ন স্টেটমেন্ট ব্যবহার করে এটি পুনরায় লিখতে অনেক বেশি কঠিন হবে: breakএগুলির প্রচারের জন্য একাধিক গুলি এবং বুলিয়ান ভেরিয়েবলগুলির একটি জটিল সিস্টেমের প্রয়োজন হবে । এই সব বলার জন্য যে সিঙ্গল রিটার্ন নিয়মটি আর এর সাথে ভালভাবে খেলছে না তাই আপনার যদি returnআপনার ফাংশনটির শরীরের কিছু জায়গায় ব্যবহার করার দরকার হয় তবে কেন সামঞ্জস্য থাকবেন না এবং সর্বত্র এটি ব্যবহার করবেন না কেন?

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

Comments

+1, returnকিছু ক্ষেত্রে বিবৃতিটির স্পষ্ট প্রয়োজন রয়েছে , যেমন @ ফ্লোডেল দেখিয়েছে। বিকল্পভাবে, এমন পরিস্থিতি রয়েছে যেখানে রিটার্নের বিবৃতিটি সবচেয়ে ভাল বাদ দেওয়া হয়, যেমন প্রচুর এবং ছোট ছোট ফাংশন কল। অন্য সব ক্ষেত্রে, 95% বলুন, কেসগুলি ব্যবহার করে returnবা না ব্যবহার করে সে বিষয়ে আসলেই কিছু আসে যায় না এবং এটি অগ্রাধিকারে নেমে আসে। আমি রিটার্নটি ব্যবহার করতে পছন্দ করি কারণ এটি আপনার অর্থের চেয়ে আরও স্পষ্ট, যেমনটি আরও পাঠযোগ্য। সম্ভবত এই আলোচনা <-বনাম অনুরূপ =?

— পল হিমস্ট্র্রা

এটি আরকে একটি অত্যাবশ্যক প্রোগ্রামিং ভাষা হিসাবে বিবেচনা করছে, যা এটি নয়: এটি কার্যকরী প্রোগ্রামিং ভাষা। কার্যকরী প্রোগ্রামিং কেবল ভিন্নভাবে কাজ করে, এবং ব্যবহার returnলেখার সঙ্গে একটি মান অর্থহীন হয় ফিরে যাও, সমাবস্থা উপর if (x == TRUE)পরিবর্তে if (x)।

— কনরাড রুডলফ

এছাড়াও আপনি পুনর্লিখন fooযেমন foo <- function(x) if (a) a else b(প্রয়োজনীয় হিসাবে linebreaks সহ)। সুস্পষ্ট রিটার্ন বা মধ্যবর্তী মানের দরকার নেই।

— হ্যাডলি

Answer 3

এটি একটি মজার আলোচনা হয়। আমি মনে করি @ ফ্লোডেলের উদাহরণটি দুর্দান্ত। যাইহোক, আমি মনে করি এটি আমার পয়েন্টটি চিত্রিত করে (এবং @ কোশকে একটি মন্তব্যে এটি উল্লেখ করেছে) returnযখন আপনি কার্যকরী কোডিং শৈলীর পরিবর্তে অপরিহার্য ব্যবহার করেন তখন তা বোধগম্য হয় ।

বিন্দুটি বেলার কথা নয়, তবে আমি এটি আবার লিখে ফেলতাম foo:

foo = function() ifelse(a,a,b)

একটি কার্যকরী শৈলীর মান সংরক্ষণের মতো, রাষ্ট্রীয় পরিবর্তনগুলি এড়ানো হয় output। এই শৈলীতে, returnজায়গা বাইরে; fooআরও গাণিতিক ফাংশনের মতো দেখাচ্ছে।

আমি @ ফ্লোডেলের সাথে একমত: আপনার বুলিয়ান ভেরিয়েবলগুলির একটি জটিল পদ্ধতি ব্যবহার barকরা কম পরিষ্কার হবে এবং আপনার কাছে থাকা অর্থহীন return। যে বক্তব্যগুলিকে barএতটা সহজলভ্য করে তোলে returnতা হ'ল এটি একটি আবশ্যকীয় স্টাইলে লেখা হয়েছে। প্রকৃতপক্ষে, বুলিয়ান ভেরিয়েবলগুলি কার্যকরী শৈলীতে এড়ানো "রাষ্ট্র" পরিবর্তনগুলি উপস্থাপন করে।

barকার্যকরী শৈলীতে পুনর্লিখন করা সত্যিই কঠিন , কারণ এটি কেবল সিউডোকোড, তবে ধারণাটি এরকম কিছু:

e_func <- function() do_stuff
d_func <- function() ifelse(any(sapply(seq(d),e_func)),2,3)
b_func <- function() {
  do_stuff
  ifelse(c,1,sapply(seq(b),d_func))
}

bar <- function () {
   do_stuff
   sapply(seq(a),b_func) # Not exactly correct, but illustrates the idea.
}

whileলুপ, সবচেয়ে কঠিন পুনর্লিখন হতে কারণ এটি রাষ্ট্র পরিবর্তন দ্বারা নিয়ন্ত্রিত হয় হবে a।

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

---

@ পলটি আবশ্যকীয় returnস্টাইলে প্রয়োজনীয় কারণ আপনি প্রায়শই লুপের বিভিন্ন পয়েন্টে ফাংশনটি থেকে বেরিয়ে আসতে চান। একটি কার্যকরী শৈলী লুপ ব্যবহার করে না, এবং তাই প্রয়োজন হয় না return। খাঁটি কার্যকরী স্টাইলে চূড়ান্ত কলটি প্রায়শই কাঙ্ক্ষিত রিটার্ন মান হয় is

পাইথনে, ফাংশনগুলির একটি returnবিবৃতি প্রয়োজন । তবে, আপনি যদি একটি ক্রিয়ামূলক শৈলীতে আপনার ফাংশনটিকে প্রোগ্রাম করে থাকেন তবে আপনার ফাংশনটির returnশেষে আপনার কেবলমাত্র একটি বক্তব্য থাকতে পারে।

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

# Procedural / Imperative
allOdd = function(x) {
  for (i in x) if (length(i) %% 2 == 0) return (FALSE)
  return (TRUE)
}

# Functional
allOdd = function(x) 
  all(length(x) %% 2 == 1)

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

@ জিএসআই-এ বর্ণিত সতর্কতাগুলি ?ifelseঅবশ্যই আকর্ষণীয়, তবে আমি মনে করি না যে তারা এই ফাংশনটির ব্যবহারকে হ্রাস করার চেষ্টা করছেন। আসলে, ifelseস্বয়ংক্রিয়ভাবে ভেক্টরাইজিং ফাংশনগুলির সুবিধা রয়েছে। উদাহরণস্বরূপ, এর কিছুটা পরিবর্তিত সংস্করণ বিবেচনা করুন foo:

foo = function(a) { # Note that it now has an argument
 if(a) {
   return(a)
 } else {
   return(b)
 }
}

এই ফাংশনটি যখন length(a)1 হয় ঠিক কাজ করে তবে আপনি যদি fooএকটি দিয়ে পুনরায় লিখেনifelse

foo = function (a) ifelse(a,a,b)

এখন fooযে কোনও দৈর্ঘ্যের উপর কাজ করে a। আসলে, এটি এমনকি aম্যাট্রিক্স যখন কাজ করবে । testকোনও বৈশিষ্ট্য যা ভেক্টোরাইজেশনে সহায়তা করে এমন কোনও বৈশিষ্ট্যের মতো একই আকারের প্রত্যাবর্তন , কোনও সমস্যা নয়।

Comments

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

— পল হিমস্ট্র্রা

এই পরিস্থিতিতে, ব্যবহার ifelse(a,a,b)করা আমার একটি পোষা প্রুভ। মনে হচ্ছে প্রতিটি লাইনে ?ifelseচিৎকার করছে, "আমাকে তার পরিবর্তে ব্যবহার করবেন না if (a) {a} else b।" উদাহরণস্বরূপ "..." "হিসাবে একই আকারের সাথে একটি মান প্রদান করে test," যদি খুব কম yesবা noতাদের সংক্ষিপ্ত হয় তবে তাদের উপাদানগুলি পুনর্ব্যবহার করা হয়। "," ফলাফলের মোড test"," এর ফলাফলের শ্রেণীর বৈশিষ্ট্যের উপর নির্ভর করে থেকে নেওয়া হয়েছে testএবং এটি থেকে নির্বাচিত মানগুলির জন্য অনুপযুক্ত হতে পারে yesএবং no"

— জিএসি

দ্বিতীয় বর্ণনায়, fooখুব বেশি অর্থবোধ করে না; এটি সর্বদা সত্য বা ফিরে আসবে b। ifelseএটি ব্যবহার করে 1 বা একাধিক সত্য এবং / অথবা 1 বা বেশ কয়েকটি bগুলি ফিরে আসবে । প্রাথমিকভাবে, আমি ভেবেছিলাম ফাংশনটির উদ্দেশ্যটি "যদি কিছু বিবৃতি সত্য হয় তবে কিছু ফিরিয়ে দিন, অন্যথায় অন্য কিছু ফিরিয়ে দিন" to আমি মনে করি না যে ভেক্টরকৃত করা উচিত, কারণ তারপর, এটা "হয়ে যাবে কিছু বস্তু যে সত্য হয় উপাদান আসতে, এবং সমস্ত উপাদান আছে যা সত্য নয় জন্য, রিটার্ন b।

— GSee

Answer 4

দেখে মনে হচ্ছে এটি return()দ্রুত ছাড়া ...

library(rbenchmark)
x <- 1
foo <- function(value) {
  return(value)
}
fuu <- function(value) {
  value
}
benchmark(foo(x),fuu(x),replications=1e7)
    test replications elapsed relative user.self sys.self user.child sys.child
1 foo(x)     10000000   51.36 1.185322     51.11     0.11          0         0
2 fuu(x)     10000000   43.33 1.000000     42.97     0.05          0         0

____ সম্পাদনা করুন__ _ __ _ __ _ __ _ __ _ ___

আমি অন্যদের কাছে এগিয়ে যাই বেঞ্চমার্ক ( benchmark(fuu(x),foo(x),replications=1e7)) এবং ফলাফলটি বিপরীত হয় ... আমি একটি সার্ভারে চেষ্টা করব।

Comments

এই পার্থক্য হওয়ার কারণ সম্পর্কে আপনি মন্তব্য করতে পারেন?

— পল হিমস্ট্র্রা

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

— গ্যাভিন সিম্পসন

Answer 5

স্পষ্টভাবে শেষে 'রিটার্ন' না রাখার একটি সমস্যা হ'ল পদ্ধতিটির শেষে যদি কেউ অতিরিক্ত বিবৃতি যোগ করে, হঠাৎ করে ফেরতের মানটি ভুল হয়:

foo <- function() {
    dosomething()
}

এটির মান প্রদান করে dosomething()।

এখন আমরা পরের দিনটিতে এসে একটি নতুন লাইন যুক্ত করব:

foo <- function() {
    dosomething()
    dosomething2()
}

আমরা চেয়েছিলাম যে আমাদের কোডটির মান ফিরিয়ে দিন dosomething(), তবে পরিবর্তে এটি আর হয় না।

স্পষ্ট প্রত্যাবর্তনের সাথে, এটি সত্যিই সুস্পষ্ট হয়ে ওঠে:

foo <- function() {
    return( dosomething() )
    dosomething2()
}

আমরা দেখতে পাচ্ছি যে এই কোডটি সম্পর্কে অদ্ভুত কিছু রয়েছে, এবং এটি ঠিক করুন:

foo <- function() {
    dosomething2()
    return( dosomething() )
}

Comments

হ্যাঁ, আসলে আমি দেখতে পাচ্ছি যে ডিবাগ করার সময় একটি সুস্পষ্ট রিটার্ন () কার্যকর; কোডটি পরিষ্কার হয়ে গেলে, এর প্রয়োজনীয়তা কম বাধ্য হয় এবং আমি এটি না রাখার কমনীয়তা পছন্দ করি ...

— প্যাট্রিক টি

তবে এটি প্রকৃত কোডে আসলে কোনও সমস্যা নয়, এটি নিখুঁত তাত্ত্বিক। কোডটি যা এর দ্বারা ভুগতে পারে তার একটি আরও বড় সমস্যা রয়েছে: একটি অস্পষ্ট, ভঙ্গুর কোড প্রবাহ যা এতটাই স্পষ্ট নয় যে সরল সংযোজনগুলি এটি ভেঙে দেয়।

— কনরাড রুডল্ফ

@ কনরাডরুডল্ফ আমার মনে হয় আপনি এর উপর কোনও নো-ট্রু স্কটসম্যান করছেন ;-) "এটি যদি আপনার কোডটিতে সমস্যা হয় তবে আপনি খারাপ প্রোগ্রামার!" আমি সত্যিই একমত না। আমি মনে করি যে আপনি কোডের ছোট ছোট টুকরাগুলিতে শর্ট-কাট নিয়ে চলে যেতে পারবেন, যেখানে আপনি প্রতিটি লাইন হৃদয় দিয়ে জানেন, আপনার কোডটি বড় হওয়ার সাথে সাথে এটি আপনাকে কামড় দিতে ফিরে আসবে।

— হিউ পারকিনস

@ হুগপর্কিনস এটি সত্যিকারের স্কটসম্যান নয় ; বরং এটি কোড জটিলতা সম্পর্কে এক অভিজ্ঞতামূলক পর্যবেক্ষণ, কয়েক দশক ধরে সফটওয়্যার ইঞ্জিনিয়ারিং সেরা অনুশীলনের ব্যাক আপযুক্ত: স্বতন্ত্র ফাংশনগুলি সংক্ষিপ্ত এবং কোড প্রবাহকে সুস্পষ্ট রাখুন। এবং বাদ দেওয়া returnকোনও শর্টকাট নয়, এটি কার্যকরী প্রোগ্রামিংয়ের উপযুক্ত স্টাইল। অপ্রয়োজনীয় returnফাংশন কলগুলি ব্যবহার করা কার্গো কাল্ট প্রোগ্রামিংয়ের একটি উদাহরণ ।

— কনরাড রুডলফ

ভাল ... আমি দেখতে পাচ্ছি না কীভাবে এটি আপনাকে আপনার returnবিবৃতি দেওয়ার পরে কিছু যুক্ত করা থেকে বিরত রেখেছে এবং লক্ষ্য করে না যে এটি কার্যকর করা হবে না। আপনি যে মানটি ফিরিয়ে দিতে চান তার পরে আপনি ঠিক তেমন একটি মন্তব্য যুক্ত করতে পারেন যেমনdosomething() # this is my return value, don't add anything after it unless you know goddam well what you are doing

— লেব্যাটসনক

Answer 6

আমার প্রশ্ন: returnদ্রুত কল করা হচ্ছে না কেন

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

এটি বলেছিল যে, এইভাবে কোনও আদিম ক্রিয়াকলাপটি কল করা returnআর- তে বেশ দ্রুত এবং কলের ওভারহেডকে কল করা । এটি বাদ দেওয়ার পক্ষে যুক্তি নয় return।

বা আরও ভাল, এবং এইভাবে ভাল?

কারণ এটি ব্যবহার করার কোনও কারণ নেই ।

কারণ এটি অনর্থক, এবং এটি দরকারী অপ্রয়োজনীয়তা যুক্ত করে না ।

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

একটি ব্যাখ্যামূলক মন্তব্যের নীচের উদাহরণটি বিবেচনা করুন, যা সর্বজনীনভাবে খারাপ রিডানডেন্সি হিসাবে স্বীকৃত কারণ মন্তব্যটি কোডটি ইতিমধ্যে কীভাবে প্রকাশ করেছে তা কেবল প্যারাফ্রেস করে:

# Add one to the result
result = x + 1

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

এরকম একটি ইতিবাচক কারণটি হ'ল কোনও ফাংশন থেকে প্রারম্ভিক প্রস্থানটি সিগন্যাল করা, একজন গার্ডের ক্লজে বলুন :

f = function (a, b) {
    if (! precondition(a)) return() # same as `return(NULL)`!
    calculation(b)
}

এটি একটি বৈধ, অপ্রয়োজনীয় ব্যবহার return। তবে অন্যান্য ভাষার তুলনায় আর এ জাতীয় গার্ডের ধারাগুলি বিরল, এবং যেহেতু প্রতিটি অভিব্যক্তির একটি মূল্য থাকে, তাই নিয়মিত ifপ্রয়োজন হয় না return:

sign = function (num) {
    if (num > 0) {
        1
    } else if (num < 0) {
        -1
    } else {
        0
    }
}

আমরা এমনকি এটি আবার লিখতে fপারেন:

f = function (a, b) {
    if (precondition(a)) calculation(b)
}

… যেখানে if (cond) exprএকই if (cond) expr else NULL।

শেষ অবধি, আমি তিনটি সাধারণ আপত্তি বানাতে চাই:

1. কিছু লোক যুক্তি দেয় যে ব্যবহার returnস্পষ্টতা যুক্ত করে, কারণ এটি "এই ফাংশনটির একটি মূল্য দেয়" সংকেত দেয়। তবে উপরে বর্ণিত হিসাবে প্রতিটি ফাংশন আর-তে কিছু returnফিরিয়ে দেয় a একটি মান ফেরত দেওয়ার মার্কার হিসাবে ভাবা কেবল নিরর্থক নয়, এটি সক্রিয়ভাবে বিভ্রান্তিকর ।

2. সম্পর্কিত, পাইথনের জেনের একটি দুর্দান্ত নির্দেশিকা রয়েছে যা সর্বদা অনুসরণ করা উচিত:

   সুস্পষ্ট বর্ণিত চেয়ে ভাল।

   রিডানডেন্টকে বাদ দেওয়া কীভাবে এটি returnলঙ্ঘন করে না? কারণ একটি কার্যকরী ভাষায় কোনও ফাংশনের রিটার্ন মান সর্বদা সুস্পষ্ট: এটি এটির শেষ প্রকাশ। এক্সপ্লোসিটিস বনাম রিডানডেন্সি সম্পর্কে এটি আবার একই যুক্তি ।

   বস্তুত, যদি আপনি explicitness চাই, এটি ব্যবহার নিয়মের ব্যতিক্রম হাইলাইট করতে: মার্ক ফাংশন যে না একটি অর্থপূর্ণ মান, যা শুধুমাত্র তাদের পার্শ্ব প্রতিক্রিয়া (যেমন জন্য বলা হয় ফিরে cat)। ছাড়া আর চেয়ে ভাল মার্কার হয়েছে returnএই ক্ষেত্রে জন্য: invisible। উদাহরণস্বরূপ, আমি লিখতে হবে

   save_results = function (results, file) {
       # … code that writes the results to a file …
       invisible()
   }

3. কিন্তু দীর্ঘ ফাংশন সম্পর্কে কি? কী ফিরিয়ে দেওয়া হচ্ছে তার ট্র্যাক হারানো কি সহজ হবে না?

   দুটি উত্তর: প্রথম, সত্যিই না। নিয়মটি পরিষ্কার: কোনও ফাংশনের শেষ প্রকাশটি এর মান। ট্র্যাক রাখার মতো কিছুই নেই।

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

Comments

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

— কনরাড রুডল্ফ

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

— ক্যাস্পার থাইস্ট্রপ কার্স্টেনসেন

Answer 7

আমি returnএকটি কৌশল হিসাবে মনে করি । একটি সাধারণ নিয়ম হিসাবে, কোনও ফাংশনে মূল্যায়ন করা শেষ অভিব্যক্তির মান ফাংশনের মান হয়ে যায় - এবং এই সাধারণ প্যাটার্নটি অনেক জায়গায় পাওয়া যায়। নিম্নলিখিত সমস্ত 3 টি মূল্যায়ন:

local({
1
2
3
})

eval(expression({
1
2
3
}))

(function() {
1
2
3
})()

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

 if(a) {
   return(a)
 } else {
   return(b)
 }

... এটি আবার লিখিত হতে পারে if(a) a else bযা আরও ভাল পাঠযোগ্য এবং কম কোঁকড়ানো বন্ধনী। এখানে মোটেই দরকার নেই return। আমার "রিটার্ন" ব্যবহারের প্রোটোটাইপিকাল কেসটি এমন কিছু হবে ...

ugly <- function(species, x, y){
   if(length(species)>1) stop("First argument is too long.")
   if(species=="Mickey Mouse") return("You're kidding!")
   ### do some calculations 
   if(grepl("mouse", species)) {
      ## do some more calculations
      if(species=="Dormouse") return(paste0("You're sleeping until", x+y))
      ## do some more calculations
      return(paste0("You're a mouse and will be eating for ", x^y, " more minutes."))
      }
   ## some more ugly conditions
   # ...
   ### finally
   return("The end")
   }

সাধারণত, অনেক রিটার্নের প্রয়োজনীয়তার পরামর্শ দেয় যে সমস্যাটি হয় কুৎসিত বা খারাপভাবে কাঠামোগত .g

<>

return কাজ করার জন্য সত্যই কোনও ফাংশনের প্রয়োজন নেই: আপনি মূল্যায়নের জন্য এটির মত প্রকাশের সেটটি ভেঙে ব্যবহার করতে পারেন।

getout <- TRUE 
# if getout==TRUE then the value of EXP, LOC, and FUN will be "OUTTA HERE"
# .... if getout==FALSE then it will be `3` for all these variables    

EXP <- eval(expression({
   1
   2
   if(getout) return("OUTTA HERE")
   3
   }))

LOC <- local({
   1
   2
   if(getout) return("OUTTA HERE")
   3
   })

FUN <- (function(){
   1
   2
   if(getout) return("OUTTA HERE")
   3
   })()

identical(EXP,LOC)
identical(EXP,FUN)

Comments

আজ আমি একটি মামলা এক আসলে যেখানে প্রয়োজন হতে পারে পাওয়া returnআপনি পরীক্ষা করতে প্রয়োজন কিনা মান অনুমান: (আমার কুশ্রী উদাহরণটি অত্যন্ত কৃত্রিম হয়) NULLবা NAএসব ক্ষেত্রে, একটি খালি স্ট্রিং ফিরে অন্যথায় আসতে characterমান। তবে একটি পরীক্ষা is.na(NULL)একটি ত্রুটি দেয়, সুতরাং দেখে মনে হচ্ছে এটি কেবল তখনই করা যেতে পারে if(is.null(x)) return("")এবং এরপরে চালিয়ে যাওয়া যায় if(is.na(x)) .....। (একটি ব্যবহার করতে পারেন length(x)==0পরিবর্তে is.null(x)কিন্তু এখনও এটি ব্যবহার করা সম্ভব নয় length(x)==0 | is.na(x)যদি xহয় NULL।)

— lebatsnok

এর কারণ আপনি ব্যবহার করেছেন |(ভেক্টরাইজড OR যেখানে উভয় পক্ষের মূল্যায়ন করা হয়) এর পরিবর্তে ||(শর্ট সার্কিট OR, ভেক্টরাইজড নয়, যেখানে পূর্বাভাসগুলি পরিবর্তে মূল্যায়ন করা হয়)। if (TRUE | stop()) print(1)বনাম বিবেচনা করুনif (TRUE || stop()) print(1)

— asac

Answer 8

return কোড পাঠযোগ্যতা বৃদ্ধি করতে পারে:

foo <- function() {
    if (a) return(a)       
    b     
}

Comments

সম্ভবত এটি পারে । তবে এটি আপনার উদাহরণে এটি করে না। পরিবর্তে এটি কোড প্রবাহকে অস্পষ্ট করে (বা বরং জটিল করে তোলে)।

— কনরাড রুডল্ফ

আপনার ফাংশনটি এটিকে সহজতর করা যেতে পারে: foo <- function() a || b(যা আইএমও আরও পাঠযোগ্য; কোনও

— অবস্থাতেই

Answer 9

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

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

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

আমি এই যেখানে দাঁড়িয়ে তাই এখানে।

function(){
  #do stuff
  ...
  abcd
}

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

function(){
  #do stuff
  ...
  return(abdc)
}

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

অবশ্যই, ফাংশনটি শেষ হয়ে গেলে এবং কাজ করার পরে আমি রিটার্নটি সরিয়ে ফেলতে পারি। তবে এটিকে সরিয়ে ফেলা নিজেই একটি অতিরিক্ত অতিরিক্ত পদক্ষেপ এবং আমার দৃষ্টিতে return()প্রথম স্থানটি অন্তর্ভুক্ত করার চেয়ে বেশি অকেজো ।

যা কিছু বলেছিল, আমি return()সংক্ষিপ্ত নামবিহীন ওয়ান-লাইন ফাংশনে ব্যবহার করি না । সেখানে এটি ফাংশনের কোডের একটি বৃহত ভগ্নাংশ তৈরি করে এবং তাই বেশিরভাগ ক্ষেত্রে ভিজ্যুয়াল ক্লোটার সৃষ্টি করে যা কোডকে কম স্পষ্ট করে তোলে। তবে বৃহত্তর আনুষ্ঠানিকভাবে সংজ্ঞায়িত এবং নামযুক্ত ফাংশনগুলির জন্য, আমি এটি ব্যবহার করি এবং সম্ভবত এটি অবিরত রাখব।

Comments

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

— কনরাড রুডল্ফ

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

— সাইমন

এছাড়াও, আমি কোনও সফটওয়্যার ইঞ্জিনিয়ার বা কম্পিউটার বিজ্ঞানী নই। আমার পরিভাষা ব্যবহারের ক্ষেত্রে খুব বেশি উপদ্রব পড়বেন না।

— সাইমন

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

— কনরাড রুডল্ফ