Özel sorunuzu cevaplamak için: Hayır, bir dil öğrenme açısından, özyineleme bir özellik değildir. Profesörünüz, henüz öğretmediği bir "özelliği" kullanmak için gerçekten not aldıysa, bu yanlıştı.
Satır aralarını okumak, bir olasılık, özyinelemeyi kullanarak, onun kursu için bir öğrenme sonucu olması gereken bir özelliği kullanmaktan kaçınmanızdır. Örneğin, belki hiç yineleme kullanmadınız veya belki forde forve kullanmak yerine yalnızca döngüler kullandınız while. Bir ödevin belirli şeyleri yapma yeteneğinizi test etmeyi amaçlaması yaygındır ve bunları yapmaktan kaçınırsanız, profesörünüz size bu özellik için ayrılan notları veremez. Bununla birlikte, eğer gerçekten kayıp notlarınızın nedeni buysa, profesör bunu kendi öğrenme deneyimi olarak almalıdır - eğer belirli öğrenme çıktılarını göstermek bir ödev için kriterlerden biriyse, öğrencilere açıkça anlatılmalıdır. .
Bunu söyledikten sonra, yinelemenin burada yinelemeden daha iyi bir seçim olduğu konusundaki diğer yorumların ve yanıtların çoğuna katılıyorum. Bunun birkaç nedeni var ve diğer insanlar onlara bir dereceye kadar değindiyse de, arkasındaki düşünceyi tam olarak açıkladıklarından emin değilim.
Yığın Taşmaları
Daha bariz olanı, yığın taşması hatası alma riskinizdir. Gerçekçi olarak, yazdığınız yöntemin gerçekten bir yönteme yol açması pek olası değildir, çünkü bir kullanıcının bir yığın taşmasını tetiklemek için birçok kez yanlış girdi vermesi gerekir.
Bununla birlikte, akılda tutulması gereken bir şey, yalnızca yöntemin kendisi değil, çağrı zincirinde daha yüksek veya daha düşük diğer yöntemlerin de yığında olacağıdır. Bu nedenle, mevcut yığın alanını gelişigüzel bir şekilde yutmak, herhangi bir yöntem için oldukça kaba bir şeydir. Diğer kodun gereksiz yere çoğunu kullanmış olma riski nedeniyle, hiç kimse kod yazarken sürekli olarak boş yığın alanı konusunda endişelenmek istemez.
Bu, yazılım tasarımında soyutlama adı verilen daha genel bir ilkenin parçasıdır. Esasen, aradığınızda DoThing(), önemsemeniz gereken tek şey İşin bitmiş olmasıdır. Nasıl yapıldığına dair uygulama detayları hakkında endişelenmenize gerek yok . Ancak yığının açgözlü kullanımı bu prensibi bozar, çünkü her kod parçasının, çağrı zincirinin başka bir yerindeki kodla kendisine ne kadar yığın bıraktığını güvenle varsayabileceği konusunda endişelenmesi gerekir.
Okunabilirlik
Diğer sebep okunabilirliktir. Kodun amaçlaması gereken ideal, her satırın basitçe ne yaptığını açıkladığı, insan tarafından okunabilir bir belge olmaktır. Bu iki yaklaşımı ele alın:
private int getInput() {
int input;
do {
input = promptForInput();
} while (!inputIsValid(input))
return input;
}
karşı
private int getInput() {
int input = promptForInput();
if(inputIsValid(input)) {
return input;
}
return getInput();
}
Evet, ikisi de işe yarıyor ve evet ikisi de anlaşılması oldukça kolay. Ancak bu iki yaklaşım İngilizce olarak nasıl tanımlanabilir? Sanırım şöyle bir şey olurdu:
Giriş geçerli olana kadar giriş isteyeceğim ve sonra geri göndereceğim
karşı
Giriş için bilgi isteyeceğim, sonra giriş geçerliyse geri vereceğim, aksi takdirde girişi alıp bunun yerine sonucunu döndürürüm
Belki ikincisi için biraz daha az karmaşık ifadeler düşünebilirsiniz, ancak bence her zaman ilkinin, aslında yapmaya çalıştığınız şeyin kavramsal olarak daha doğru bir açıklaması olacağını göreceksiniz. Bu, özyinelemenin her zaman daha az okunabilir olduğu anlamına gelmez . Ağaç geçişi gibi parladığı durumlar için, özyineleme ve başka bir yaklaşım arasında aynı türden yan yana analizi yapabilirsiniz ve neredeyse kesinlikle özyinelemenin, kendi kendini tanımlayan, satır satır daha net bir kod veren kod verdiğini göreceksiniz.
Tek başına, bunların ikisi de küçük noktalardır. Bunun gerçekten bir yığın taşmasına yol açması pek olası değildir ve okunabilirlikteki kazanç küçüktür. Ancak herhangi bir program, bu küçük kararların birçoğunun bir derlemesi olacaktır, bu nedenle, tek başlarına çok önemli olmasalar bile, bunları doğru yapmanın arkasındaki ilkeleri öğrenmek önemlidir.