Neden değişkenleri kullanıldıkları yere yakın bildirmeliyiz?

İnsanların değişkenlerin kullanımlarına olabildiğince yakın beyan edilmesi gerektiğini söylediklerini duydum . Bunu anlamıyorum.

Örneğin, bu politika şunu yapmamı önerir:

foreach (var item in veryLongList) {
  int whereShouldIBeDeclared = item.Id;
  //...
}

Ancak elbette bu int, her yinelemede yeni bir yaratma yükünün oluştuğu anlamına gelir . Kullanmak daha iyi olmaz mıydı:

int whereShouldIBeDeclared;
foreach (var item in veryLongList) {
  whereShouldIBeDeclared = item.Id;
  //...
}

Lütfen biri açıklayabilir mi?

Bu, birçoğu arasında bir stil kuralıdır ve mutlaka aklınıza gelebilecek tüm olası kuralların en önemli kuralı değildir. Örneğiniz, bir int içerdiğinden, süper zorlayıcı değildir, ancak bu döngü içinde kesinlikle pahalı bir yapıya sahip bir nesneye ve belki de nesneyi döngü dışında oluşturmak için iyi bir argümana sahip olabilirsiniz. Bununla birlikte, bu ilk önce bu kurala karşı iyi bir argüman yapmaz, bir döngüde pahalı nesneler inşa etmeyi içermeyen tonlarca başka yer vardır ve ikincisi iyi bir optimize edici (ve C #, böylece iyi bir optimizer var) döngü dışında başlatma vinç olabilir.

Bu kuralın gerçek nedeni, bunun neden bir kural olduğunu görmemenizin nedenidir. İnsanlar yüzlerce hatta binlerce satır uzunluğundaki işlevleri yazıyorlardı ve Visual Studio'nun sağladığı destek olmadan düz metin editörlerine (Not Defteri) yazıyorlardı. Bu ortamda, kullanıldığı yerden yüzlerce satır değişkenlik bildirilmesi, okuyan kişinin

if (flag) limit += factor;

Bayrağın, limitin ve faktörün ne olduğu hakkında çok fazla ipucu yoktu. Buna yardımcı olmak için Macarca gösterim gibi adlandırma kuralları kabul edildi ve kullanılan yerlere yakın şeyleri bildirmek gibi kurallar da kabul edildi. Tabii ki, bu günlerde, her şey yeniden düzenleme ile ilgilidir ve işlevler genellikle bir sayfadan daha azdır, bu da bildirilen yerler ile kullanıldığı yerler arasında çok fazla mesafe almayı zorlaştırır. 0-20 aralığında çalışıyorsunuz ve bu örnekte 7'nin iyi olduğunu tartışıyorsunuz, kuralı yapan kişi 7 satır almayı SEVDİ ve 700'den biriyle konuşmaya çalışıyordu. Bunun da ötesinde, Visual Studio'da herhangi bir şeyin üzerine fareyi getirebilir ve türünü görebilirsiniz, üye bir değişken olup olmadığı vb. Bu, hattın azaltıldığını görme gereğinin azaldığı anlamına gelir.

Bu hala oldukça iyi bir kural, bugünlerde kırılması oldukça zor olan ve hiç kimsenin yavaş kod yazmanın bir nedeni olarak savunulamadığı bir kural. Her şeyden önce mantıklı olun.

Döngünün içindeki değişkeni tanımlamak, onu yalnızca o döngü için yerel olarak görünür kılar. Bunun okuyucu için en az 3 avantajı vardır:

1. Değişken tanımı ve ilgili yorumların bulunması kolaydır
2. Okuyucu, bu değişkenin hiçbir zaman başka yerde kullanılmadığını bilir (beklemek için bağımlılık yoktur)
3. Kod yazıldığında veya düzenlendiğinde, bu değişkene başvurmak için döngü dışında aynı değişken adını kullanma şansınız yoktur, aksi takdirde hata alabilirsiniz.

Verimlilik bitine gelince, derleyici üretilen optimize edilmiş kodda döngü dışında tanım üretmek için akıllıdır. Değişken her döngü yinelemesinde oluşturulmaz.

İnsanlar kullanımlarına olabildiğince yakın diyorlar , bunu her zaman yapmanız gerektiğini söylemiyorlar, çünkü değişkenleri en az kapsamda beyan eden bazı durumlar yüke neden olacak. yapabileceğiniz en küçük kapsam.

Okunabilirliğe yardımcı olmasına rağmen, okunabilirlik bu durumda birincil husus değildir ve modern IDE'ler bu kurala olan ihtiyacı ortadan kaldırmaz.

Birincil endişe başlatılmamış değişkenlerdir. Bir değişkeni başlatılmasından çok uzakta bildirirseniz, sizi her türlü potansiyel soruna açar. Kendinizi daha önce RAM'de olanlarla veya işlevde daha yüksek bir hesaplamadan veya birisinin derleyicinin şikayet etmesini önlemek için koyduğu bir kukla başlatma (0 gibi) sonucu ile yanlışlıkla çalıştığını görebilirsiniz. Kullanıcılar, bu değişken için örtük ön koşullarınızın farkında olmadan bildiriminizle kullanımınız arasına kod ekleyecektir. En kötü durumlarda, bu kullanım sadece testlerinizde işe yarayacak, ancak sahada başarısız olacaktır.

Değişkenlerinizi olabildiğince küçük bir kapsamda beyan etmek ve bunları beyan noktasında uygun bir değere başlatmak, birçok bakım baş ağrısından kaçınacaktır. Geliştirilmiş okunabilirliği zorladığı gerçeği sadece hoş bir yan etkidir.

Bu bir "zorunluluk" değildir. Bu sadece bir fikir, bir şey yapmanın yolu. Örneğin, yöntemin ilk satırlarındaki tüm değişkenleri bildirmeyi seviyorum, böylece bu değişkenlerle ne yapacağımı yorumlayabiliyorum (tabii ki sayaç olmadıkça). Diğer insanlar, duyduğunuz gibi, kullanımlarına mümkün olduğunca yakın yerleştirmeyi sever (yazdığınız ikinci örnekte olduğu gibi). Her neyse, sağladığınız ilk örnek kesinlikle bir "hata" dır (anladığınız gibi bir ek yüke neden olacağı anlamında).

Sadece yolunuzu seçmeli ve takip etmelisiniz.

İki örneğiniz işlevsel olarak farklı kodlardır, birbirinin yerine kullanılamaz. (Sökülen örnekleriniz, farkı olmayan bir ayrım bırakır, ancak önemsiz olmayan kodda fark yaratır). Sitenizdeki kural her zaman "... mümkün olduğunca" ile gösterildiği gibi kapsam belirleme hususlarına tabidir.