Adlandırma: Açıklık için kısalığı feda etmeli misiniz?

Örneğin, aşağıdaki işlev, bir giriş alanının adını ve hatalarını içeren bir dizide dolaşır. Bunu, doğrulama alanının adını kontrol edip hata bilgisini geçersiz alanlar dizisine iterek yapar.

Kısa olmak ve bunu yazmak daha iyi mi?

addInvalidField (field, message) {
  const foundField = this.invalidFields.find(value => {
    return value.name === field.name
  })
  const errors = foundField.errors
  if (!errors.some(error => error.name === message)) {
    errors.push({ name: message, message })
  }
},

Yoksa daha spesifik olmak ister misiniz?

addInvalidField (validatingField, message) {
  const foundField = this.invalidFields.find(invalidField => {
    return validatingField.name === invalidField.name
  })
  if (!foundField.errors.some(foundFieldError => foundFieldError.name === message)) {
    fouldField.errors.push({ name: message, message })
  }
},

Eğer kısalık netlik için feda edilebilirse, olmalıdır. Ancak ayrıntı düzeyi netlik için feda edilebilirse, daha da iyisi.

addInvalidField (field, message) {
  const foundInvalidField = this.invalidFields.find(x => x.name === field.name)
  if (!foundInvalidField.errors.some(x => x.name === message)) {
    foundInvalidField.errors.push({ name: message, message })
  }
},

Bir değişken sadece bir çizgi kadar yaşadığı zaman gerçekten çok kısa olabilir. FoundInvalidFieldüç satırda kullanılır ve bu çalışmanın odak noktasıdır. Açıklayıcı bir ismi hak ediyor.

Her zaman olduğu gibi, bağlam kraldır.

Aslında ilk kod örneğinizi tercih ederim.

Kodun sadece okuyarak ne yaptığı açıktır. Değişken adlarını olabildiğince küçük tutarak, kodun daha kolay okunmasını sağlarsınız. Daha açıklayıcı değişken adları, yalnızca işlevleriniz daha uzun, değişkenleriniz daha çok sayıda ve / veya değişken (ler) daha büyük bir kod kapsamı üzerinde kullanıldıysa gerekli olacaktır.

Çünkü işlevlerinizi kısa tuttunuz, değişken adlarınızı da kısa tutabilirsiniz. Tüm diğer şeyler eşit olduğunda, daha az kod her zaman daha iyidir.

Bence Bob Amca'ya aşırı ayrıntıya girmeden açıklığı tercih etme konusunda katılıyorum . Gösterdiğiniz örneklerde , ikincisinin niyetinin aşırı ayrıntıya girmeden daha açık olduğunu söyleyebilirim . Ayrıca kod tabanı olsa ararken o belirli parçacığını bulmak daha kolay olacaktır invalidFieldiçin daha value.

Peki burada Temiz Kod alıntı yapıyorum (Bob Amca'nın vaazından bıkmışsanız atlayın (ki ben değilim):

Niyet Ortaya Çıkaran İsimler Kullanın

İsimlerin niyeti ortaya koyması gerektiğini söylemek kolaydır. Sizi etkilemek istediğimiz şey bu konuda ciddi olduğumuzdur. İyi isimler seçmek zaman alır, ancak gerekenden daha fazla tasarruf sağlar. Bu yüzden isimlerinize dikkat edin ve daha iyi olanları bulduğunuzda değiştirin. Kodunuzu okuyan herkes (siz dahil) yaparsanız daha mutlu olur.

Dezenfeksiyondan Kaçının

Programcılar, kodun anlamını gizleyen yanlış ipuçları bırakmaktan kaçınmalıdır. Yerleşik anlamları bizimkilerden farklı olan kelimelerden kaçınmalıyız.

Anlamlı Ayrımlar Yaratın

Programcılar yalnızca bir derleyici veya yorumlayıcıyı karşılamak için kod yazdıklarında kendileri için sorun yaratırlar.

Aranabilir Adları Kullan

Eğer bir konuda yardımcı olacağını Kullanım adları grep -iIR whateveryouaresearching . (burada, bir Temiz Kod CC sadece tek harf değişkenleri hakkında konuştuk).

Zihinsel Haritalamadan Kaçının

Okuyucular, adlarınızı zihinsel olarak zaten bildikleri diğer adlara çevirmek zorunda olmamalıdır. Bu sorun genellikle ne sorun etki alanı terimlerini ne de çözüm etki alanı terimlerini kullanma seçeneğinden kaynaklanır.

Sorunlu Etki Alanı Adlarını Kullan

Yaptığınız şey için “programcı-eese” yoksa, sorunlu etki alanından adı kullanın. En azından kodunuzu koruyan programcı bir alan uzmanına bunun ne anlama geldiğini sorabilir.

Bu günlerde her zaman daha açıklayıcı olmayı tercih ediyorum - IDE kodunun tamamlanması, açıklayıcı değişken adları yazmak zorunda kalmayacağınız anlamına geliyor, bu yüzden bir dezavantaj göremiyorum.

Önceki tarihte, değişken ad kısıtlamalarınız vardı ve anlamlı değişken adları kullanmak aslında ölçülebilir bir maliyete neden olabilir (örneğin, BBC BASIC'de tamsayı statik değişkenleri kullanan% A vb.) Anlamlı bir tamsayı kullanmaktan çok daha ucuzdu - ve 1MHz'li bir sistemde işlemci, aslında önemli bir döngüde birkaç saat döngüsü kaydetmek)

İkinci varyant görünümü beni şaşırtıyor. Sadece imzama baktığımda, alanın zaten beeing geçersiz olarak bilinip bilinmediğini merak ediyorum? Yoksa validatingFieldgerçekten geçersiz olup olmadığını öğrenmek için ilk önce (denildiği gibi ) doğrulanacak mı? Yani bu sadece gereksiz bilgi değil, fazladan bilgi biraz yanıltıcı görünüyor. Bu tür "açıklık" daha net değil, tam tersi.

Aslında, ilk fonksiyonunu gördüğümde, beni de şaşırttı. Kendi fonksiyonumun neden sadece bir alan aldığını sordum ama sonra onu kullanmıyor ve içinde başka bir tane arıyor invalidFields? Bir alan aramak, sadece bir alan adı verildiğinde çok daha mantıklı görünmektedir, şöyle:

addInvalidField (fieldname, message) {
  const foundField = this.invalidFields.find(value => {
    return value.name === fieldname
  })
  const errors = foundField.errors
  if (!errors.some(error => error.name === message)) {
    errors.push({ name: message, message })
  }
}

Ancak, sanırım Bob Martin muhtemelen bir adım daha ileri gidecek ve kodu daha açık bir şekilde - daha fazla netlik için - farklı bir yönde yapacaktır. "Temiz Kod" kitabının satırları boyunca tipik bir yeniden düzenleme muhtemelen şöyle görünecektir:

addInvalidField (fieldname, message) {
  const foundField = findInvalidField(fieldName)
  addMessageForInvalidField(foundField,message)
}

üç ek fonksiyon ile

  findInvalidField(fieldname){
    return this.invalidFields.find(value => { return value.name === fieldname })
  }

  addMessageForInvalidField(field,message){
    const errors = field.errors
    if (!doesErrorsContain(message)) {
      errors.push({ name: message, message })
    }
  }

  doesErrorsContain(message){
     return errors.some(error => error.name === message)
  }

Tek sorumluluk prensibi ile bu kadar ileri gitmenin işe yarayıp yaramadığı tartışmalıdır. Aslında bazı artıları ve eksileri vardır. Benim kişisel görüşüm, orijinal kodun çoğu üretim kodu için "yeterince temiz" olması, ancak yeniden düzenlenmiş kodun daha iyi olmasıdır.

İlk varyanta bir şeyler eklemek zorunda olduğumu bildiğimde, daha fazla büyüyecekti, önceden bu daha küçük işlevlere bölüyordum, bu yüzden kod bir karışıklık olmaya başlamayacaktı.

Adlandırmada genel olarak doğru cevap yoktur. Aynı görev seti verildiğinde birçok kişi ortaya çıkan işlevleri ve değişkenleri çok farklı adlandırır. Elbette kodunuzu okuyan diğerlerinin anlamasını istersiniz, ancak daha uzun her zaman bir şeyin daha net olduğu anlamına gelmez. Kodunuz daha yoğun ise, o zaman olması gerekir, o zaman fonksiyonlarınızın her satırının olabildiğince açık ve açıklayıcı olduğunu anlamak daha fazla zaman alacaktır.

Şahsen, ilk örneği daha çok seviyorum. Değişkenler ikinci örnekte olduğu gibi açıklayıcı isimlere sahip olmasa bile düzdür. Dürüst olmak gerekirse, ikinci örnekteki değişken isimleri bence ilkinden çok daha net değildir ve işlevi kısa tutmak işlevin kendisini anlamayı kolaylaştırır.

Günün sonunda, hangisi daha iyi size ve kiminle çalışacağınıza bağlı olacaktır. Sonuçta, onu okuyacak ve koruyacak olan budur.