bağlam

Geçenlerde daha iyi biçimlendirilmiş kod üretmek ilgimi çekti. Ve daha iyisi, "bunu iyi bir uygulama olarak kabul edecek kadar insan tarafından onaylanmış kuralları takip etmek" demek istiyorum (çünkü elbette kodlamanın eşsiz bir "en iyi" yolu olmayacak).

Bugünlerde çoğunlukla Ruby'de kod yazıyorum, bu yüzden bana kodumun "kalitesi" hakkında biraz bilgi sağlamak için bir linter (Rubocop) kullanmaya başladım (bu "kalite" topluluk odaklı proje ruby-style-guide tarafından tanımlanıyor ).

Bazı durumlarda, kod verimi aslında bile, çok değil kodun verimliliğine ilişkin "biçimlendirme kalitesi" gibi "kalite" kullanacağı Not edilmektedir kod yazılır nasıl etkilenir.

Her neyse, tüm bunları yaparak, birkaç şey fark ettim (veya en azından hatırladım):

• Bazı diller (özellikle Python, Ruby ve benzeri) mükemmel bir kod satırı oluşturmaya izin verir
• Kodunuz için bazı yönergelere uymanız, kodu önemli ölçüde kısaltabilir ve yine de çok açık hale getirebilir
• Yine de, bu yönergeleri çok sıkı bir şekilde uygulamak, kodu daha az net / okunması kolay hale getirebilir
• Kod, bazı yönergelere neredeyse mükemmel şekilde saygı gösterebilir ve yine de düşük kalitede olabilir
• Kod okunabilirliği çoğunlukla özneldir ("açık bulduğum şey, bir geliştirici için tamamen belirsiz olabilir" de olduğu gibi)

Bunlar sadece gözlemler, elbette mutlak kurallar değil. Ayrıca, kod okunabilirliğinin ve aşağıdaki yönergelerin bu noktada alakasız görünebileceğini de unutmayın, ancak burada yönergeler, bir kod parçasını yeniden yazmanın yol sayısını daraltmanın bir yoludur.

Şimdi, bazı örnekler, bunları daha açık hale getirmek için.

Örnekler

Basit bir kullanım örneği ele alalım: " User" modeli olan bir uygulamamız var . Bir kullanıcının isteğe bağlı firstnameve surnamezorunlu bir emailadresi vardır.

Ben en azından onun veya varsa kullanıcının nameadı ( firstname + surname) , ya da değilse bir geri dönüş değeri olarak dönecektir bir yöntem " " yazmak istiyorum .firstnamesurnameemail

Ben de bu yöntemi bir use_emailparametre olarak "(boolean) almak, kullanıcı e-posta yedek değer olarak kullanmak için izin istiyorum. Bu " use_email" parametresi varsayılan olarak ("geçilmezse)" true" olarak ayarlanmalıdır .

Bunu Ruby'de yazmanın en basit yolu:

def name(use_email = true)
 # If firstname and surname are both blank (empty string or undefined)
 # and we can use the email...
 if (firstname.blank? && surname.blank?) && use_email
  # ... then, return the email
  return email
 else
  # ... else, concatenate the firstname and surname...
  name = "#{firstname} #{surname}"
  # ... and return the result striped from leading and trailing spaces
  return name.strip
 end
end

Bu kod, bunu yapmanın en basit ve anlaşılması kolay yoludur. Ruby konuşmayan biri için bile.

Şimdi bunu kısaltmaya çalışalım:

def name(use_email = true)
 # 'if' condition is used as a guard clause instead of a conditional block
 return email if (firstname.blank? && surname.blank?) && use_email
 # Use of 'return' makes 'else' useless anyway
 name = "#{firstname} #{surname}"
 return name.strip
end

Bu, daha kolay olmasa bile daha kısa, anlaşılması kolaydır (koruma maddesi bir koşullu bloktan daha doğaldır). Guard yan tümcesi ayrıca kullandığım yönergelerle daha uyumlu olmasını sağlar, bu yüzden burada kazan-kazan. Girinti seviyesini de düşürüyoruz.

Şimdi biraz daha kısa yapmak için Ruby sihri kullanalım:

def name(use_email = true)
 return email if (firstname.blank? && surname.blank?) && use_email
 # Ruby can return the last called value, making 'return' useless
 # and we can apply strip directly to our string, no need to store it
 "#{firstname} #{surname}".strip
end

Daha kısa ve yönergeleri mükemmel bir şekilde takip etmek ... ama dönüş ifadesinin eksikliği bu uygulamaya aşina olmayanlar için biraz kafa karıştırıcı hale geldiğinden çok daha az net.

Burada şu soruyu sormaya başlayabiliriz: gerçekten buna değer mi? "Hayır, okunabilir kılın ve ' return'" diyelim (bunu bilmek kurallara uymayacaktır). Yoksa "Sorun değil, Ruby yolu, lanet dili öğren!" Mi demeliyiz?

B seçeneğini kullanırsak, neden daha da kısa hale getirmeyelim:

def name(use_email = true)
 (email if (firstname.blank? && surname.blank?) && use_email) || "#{firstname} #{surname}".strip
end

İşte, tek astar! Tabii ki daha kısa ... burada Ruby'nin hangisinin tanımlandığına bağlı olarak bir değer veya diğeri döndüreceği gerçeğinden yararlanıyoruz (çünkü e-posta daha önce olduğu gibi aynı koşulda tanımlanacaktır).

Ayrıca yazabiliriz:

def name(use_email = true)
 (email if [firstname, surname].all?(&:blank?) && use_email) || "#{firstname} #{surname}".strip
end

Kısa, okumak o kadar da zor değil (yani, çirkin bir astarın neye benzeyebileceğini gördük), iyi Ruby, kullandığım kılavuza uyuyor ... Ama yine de, ilk yazma yöntemine kıyasla okuması ve anlaması çok daha az kolaydır. Bu satırın çok uzun (80 karakterden fazla) olduğunu da iddia edebiliriz.

Soru

Bazı kod örnekleri, bir "tam boyutlu" kod ile indirgenmiş sürümlerinin birçoğu (ünlü tek astara kadar) arasında seçim yapmanın zor olabileceğini gösterebilir, çünkü görebildiğimiz gibi, bir astar o kadar korkutucu olmayabilir ama yine de hiçbir şey okunabilirlik açısından "tam boyutlu" kodu geçmeyecektir ...

İşte asıl soru: nerede durmalı? Ne zaman kısa, yeterince kısa? Kodun ne zaman "çok kısa" ve daha az okunabilir hale geldiğini (oldukça öznel olduğunu akılda tutarak) nasıl öğrenebilirim? Ve daha da fazlası: nasıl her zaman buna göre kodlamak ve sadece gibi hissediyorum zaman tek satırları "tam boyutlu" kod parçaları ile karıştırmak kaçının?

TL; DR

Buradaki ana soru şudur: "uzun ama net, okunabilir ve anlaşılabilir bir kod yığını" ve "bu satırın üst ve alt sadece iki seçenek değil, bir ölçeğin altında: "yeterince net" ve "olması gerektiği kadar net değil" arasındaki sınırın nasıl tanımlanacağı?

Ana soru, klasik "Tek gömlekler ve okunabilirlik: hangisi daha iyi?" ama "Bu ikisi arasındaki denge nasıl bulunur?"

Düzenle 1

Kod örneklerindeki yorumların "yoksayılması" amaçlanmıştır, neler olduğunu açıklığa kavuşturmak için buradadırlar, ancak kodun okunabilirliğini değerlendirirken dikkate alınmamalıdırlar.

Hangi kodu yazarsanız yazın, okunabilir en iyisidir. Kısa ikinci en iyisidir. Ve okunabilir genellikle yeterince kısa anlamına gelir, böylece kodu, iyi tanımlanmış tanımlayıcıları anlayabilir ve kodun yazıldığı dilin ortak deyimlerine bağlı kalabilirsiniz.

Eğer bu dil agnostik olsaydı, bunun kesinlikle fikir temelli olacağını düşünüyorum, ama Ruby dilinin sınırları içinde buna cevap verebileceğimizi düşünüyorum.

İlk olarak, bir özellik ve deyimsel bir yazma yöntemi Ruby, returnbir yöntemden erken dönmedikçe bir değer döndürürken anahtar kelimeyi atlamaktır .

Diğer bir özellik ve deyim if, kodun okunabilirliğini artırmak için sondaki ifadeleri kullanmaktır . Ruby'nin temel fikirlerinden biri, doğal dil olarak okunan kod yazmaktır. Bunun için _why'nin Ruby ile ilgili Poignant Rehberine gidiyoruz , Bölüm 3 .

Aşağıdakileri kendinize yüksek sesle okuyun.

5.times { print "Odelay!" }

İngilizce cümlelerde noktalama işaretleri (nokta, ünlem işareti, parantez gibi) sessizdir. Noktalama işaretleri kelimelere anlam katar, yazarın bir cümlenin neyi amaçladığına dair ipuçları vermeye yardımcı olur. Yukarıdakileri şu şekilde okuyalım: Beş kez “Odelay!” Yazdıralım.

Bu göz önüne alındığında, kod örneği # 3 Ruby için en deyimseldir:

def name(use_email = true)
  return email if firstname.blank? && surname.blank? && use_email

  "#{firstname} #{surname}".strip
end

Şimdi kodu okuduğumuzda şöyle diyor:

Ad boş ve soyadı boşsa e-posta döndür ve e-posta kullan

(dönüş) ad ve soyadı alındı

Hangi gerçek Ruby koduna oldukça darn.

Sadece 2 satır gerçek kod, bu yüzden oldukça keskindir ve dilin deyimlerine yapışır.

"En iyi yargınızı kullanın" dan daha iyi bir cevap alacağınızı sanmıyorum. Kısacası kısalık yerine netlik için çaba göstermelisiniz . Genellikle, en kısa kod da en açık olanıdır, ancak sadece kısalık elde etmeye odaklanırsanız, netlik zarar görebilir. Bu, önceki iki örnekten daha fazla çaba gerektiren, son iki örnekte açıkça görülmektedir.

Önemli bir husus, kodun izleyicisidir. Okunabilirlik elbette tamamen okuyan kişiye bağlıdır. Kodu okumayı beklediğiniz insanlar (kendinizin yanında) Ruby dilinin deyimlerini gerçekten biliyor mu? Peki bu soru internetteki rastgele insanların cevaplayabileceği bir şey değil, bu sadece sizin kendi kararınız.

Buradaki sorunun bir kısmı “okunabilirlik nedir”. Benim için ilk kod örneğine bakıyorum:

def name(use_email = true)
 # If firstname and surname are both blank (empty string or undefined)
 # and we can use the email...
 if (firstname.blank? && surname.blank?) && use_email
  # ... then, return the email
  return email
 else
  # ... else, concatenate the firstname and surname...
  name = "#{firstname} #{surname}"
  # ... and return the result striped from leading and trailing spaces
  return name.strip
 end
end

Ve sadece kodu tekrarlayan "gürültülü" yorumlarla dolu okumak zor. Onları çıkarın:

def name(use_email = true)
 if (firstname.blank? && surname.blank?) && use_email
  return email
 else
  name = "#{firstname} #{surname}"
  return name.strip
 end
end

ve şimdi çok daha okunabilir. Sonra okurken, "hmm, Ruby üçlü operatörü destekliyor mu acaba? C #, ben şöyle yazabilirsiniz:

string Name(bool useEmail = true) => 
    firstName.Blank() && surname.Blank() && useEmail 
    ? email 
    : $"{firstname} {surname}".Strip();

Ruby'de böyle bir şey mümkün mü? Gönderiniz boyunca çalışırken, şunu görüyorum:

def name(use_email = true)
 (email if (firstname.blank? && surname.blank?) && use_email) || "#{firstname} #{surname}".strip
end

Tüm iyi şeyler. Ama bu benim için okunabilir değil; çünkü tüm çizgiyi görmek için kaydırmam gerekiyor. Bu yüzden düzeltelim:

def name(use_email = true)
 (email if (firstname.blank? && surname.blank?) && use_email) 
 || "#{firstname} #{surname}".strip
end

Şimdi mutluyum. Sözdiziminin nasıl çalıştığından tamamen emin değilim, ancak kodun ne yaptığını anlayabiliyorum.

Ama bu sadece benim. Diğer halkın güzel bir kod parçasını okuması için çok farklı fikirleri vardır. Bu yüzden kod yazarken kitlenizi tanımanız gerekir. Eğer mutlak bir başlangıç ​​öğretiyorsanız, bunu basit tutmak ve muhtemelen ilk örneğiniz gibi yazmak istersiniz. Uzun yıllar yakut deneyime sahip bir dizi profesyonel geliştirici arasında çalışıyorsanız, dilden yararlanan kodu yazın ve kısa tutun. Eğer arada bir yerdeyse, arada bir yer hedefleyin.

Ama söyleyeceğim bir şey: son örneğiniz gibi "akıllı kod" dikkat edin. Kendinize sorun, [firstname, surname].all?(&:blank?)zekice hissetmekten başka bir şey ekleyin , çünkü şimdi okumak biraz zor olsa bile becerilerinizi gösteriyor mu? Bu örneğin büyük olasılıkla bu kategoriyi tamamladığını söyleyebilirim. Beş değeri karşılaştıracak olsaydınız, iyi bir kod olarak görürdüm. Yani yine, burada mutlak bir çizgi yok, sadece çok zeki olmaya dikkat edin.

Özetle: okunabilirlik, kitlenizi tanımanızı ve kodunuzu buna göre hedeflemenizi ve özlü ama net bir kod yazmanızı gerektirir; asla "akıllı" kod yazmayın. Kısa tutun, ama çok kısa değil.

Bu muhtemelen bir fikir tabanlı cevap vermemenin zor olduğu bir soru, ama işte benim iki sentim.

Kodu kısaltmanın okunabilirliği etkilemediğini veya hatta geliştirmediğini fark ederseniz, buna gidin. Kod daha az okunabilir hale gelirse, bu şekilde bırakmak için oldukça iyi bir neden olup olmadığını düşünmeniz gerekir. Bunu daha kısa veya havalı olduğu ya da yapabildiğiniz için yapmak kötü nedenlere örnektir. Kodu kısaltmanın, birlikte çalıştığınız diğer kişiler için daha az anlaşılır olup olmayacağını da düşünmeniz gerekir.

Peki bunun iyi bir nedeni ne olabilir? Gerçekten bir yargılama çağrısıdır, ancak bir örnek performans optimizasyonu gibi bir şey olabilir (performans testinden sonra, elbette, önceden değil). Daha az okunabilirlik ile ödemek istediğiniz bazı faydalar sağlayan bir şey. Bu durumda, yararlı bir yorum (kodun ne yaptığını ve neden biraz şifreli yapılması gerektiğini açıklayarak) dezavantajı azaltabilirsiniz. Daha da iyisi, bu kodu anlamlı bir adla ayrı bir işleve çıkarabilirsiniz, böylece çağrı sitesinde ne olduğunu (işlevin adı aracılığıyla) ayrıntılara girmeden açıklayan sadece bir satırdır (ancak, insanlar farklıdır) bu konuda görüşler, bu yüzden yapmanız gereken başka bir karar çağrısı).

Cevap biraz özneldir, ancak bir ya da iki ay içinde geri döndüğünüzde bu kodu anlayabiliyorsanız, toplayabileceğiniz tüm dürüstlükle kendinize sormanız gerekir.

Her değişiklik, ortalama bir kişinin kodu anlama yeteneğini geliştirmelidir. Kodu anlaşılır kılmak için aşağıdaki yönergeleri kullanmaya yardımcı olur:

• Dilin deyimlerine saygı gösterin . C #, Java, Ruby, Python'un hepsinde aynı şeyi yapmanın tercih edilen yolları var. Deyimsel yapılar, aşina olmadığınız kodu anlamanıza yardımcı olur.
• Kodunuz daha az okunabilir hale geldiğinde durun . Sağladığınız örnekte, bu son azaltma kod çiftlerinize ulaştığınızda oldu. Önceki örneğin deyimsel avantajını kaybettiniz ve neler olduğunu gerçekten anlamak için çok fazla düşünme gerektiren çok sayıda sembol getirdiniz.
• Yorumları yalnızca beklenmedik bir şeyi gerekçelendirmeniz gerektiğinde kullanın . Örneklerinizin Ruby'ye daha az aşina olan insanlara yapıları açıklamak için orada olduğunu biliyorum ve bu bir soru için sorun değil. Beklenmedik iş kurallarını açıklamak ve kodun kendisi için konuşabiliyorsa bunlardan kaçınmak için yorumları kullanmayı tercih ederim.

Bununla birlikte, genişletilmiş kodun nelerin daha iyi olduğunu anlamaya yardımcı olduğu zamanlar vardır. Bununla bir örnek C # ve LINQ'dan geliyor. LINQ harika bir araçtır ve bazı durumlarda okunabilirliği artırabilir, ancak çok daha kafa karıştırıcı olduğu birkaç durumla da karşılaştım. Ben başkalarının daha iyi korumak böylece uygun ifadeleri ile bir döngü içine ifade dönüm önerdi akran gözden bazı geri bildirimler vardı. Uyduğumda haklıydılar. Teknik olarak, LINQ C # için daha deyimseldir, ancak anlaşılabilirliği bozduğu ve daha ayrıntılı bir çözümün onu geliştirdiği durumlar vardır.

Bunu söylemek için bütün bunları söylüyorum:

Kodunuzu ne zaman daha iyi hale getirebileceğinizi (daha anlaşılır) geliştirin

Unutmayın, siz veya sizin gibi biri bu kodu daha sonra korumak zorunda kalacaktır. Bir daha karşılaştığınız zaman aylarca sürebilir. Kendinize bir iyilik yapın ve kod sayınızı anlayabilme pahasına azalan satır sayısını takip etmeyin.

Okunabilirlik , sahip olmak istediğiniz bir özelliktir, çok sayıda astara sahip olmak değildir. Bu yüzden "tek gömlekler ile okunabilirlik" yerine soru şu olmalıdır:

Tek gömlekler ne zaman okunabilirliği artırır ve ne zaman zarar verir?

Tek gömleklerin bu iki koşulu yerine getirdiklerinde okunabilirlik için iyi olduğuna inanıyorum:

1. Bir işleve çıkarılamayacak kadar özeldirler.
2. Etraftaki kodu okumanın “akışını” kesmek istemezsiniz.

Diyelim ki nameyönteminiz için iyi bir isim değildi. Adı ve soyadı birleştirmek veya ad yerine e-postayı kullanmak doğal şeyler değildi. Böylece nameen iyi şey yerine uzun ve hantal çıktı:

puts "Name: #{user.email_if_there_is_no_name_otherwise_use_firstname_and_surname(use_email)}"

Böyle uzun bir isim bunun çok spesifik olduğunu gösterir - daha genel olsaydı daha genel bir isim bulabilirdiniz. Bu nedenle, bir yönteme sarmak ne okunabilirliğe (çok uzun) ne de DRYness'e (başka hiçbir yerde kullanılmak için çok spesifik) yardımcı olmaz, bu nedenle kodu orada bırakmak daha iyidir.

Yine de - neden tek astar yapalım? Genellikle çok satırlı koddan daha az okunabilir. Burada ikinci durumumu kontrol etmeliyiz - çevreleyen kodun akışı. Ya böyle bir şey varsa:

puts "Group: #{user.group}"
puts "Title: #{user.title}"
if user.firstname.blank? && user.surname.blank?) && use_email
  name = email
else
  name = "#{firstname} #{surname}"
  name.strip
end
puts "Name: #{name}"
puts "Age: #{user.age}"
puts "Address: #{user.address}"

Çok satırlı kodun kendisi okunabilir - ancak çevreleyen kodu (çeşitli alanları yazdırırken) okumaya çalıştığınızda, çok satırlı yapı akışı kesintiye uğratır. Bunu okumak daha kolay:

puts "Group: #{user.group}"
puts "Title: #{user.title}"
puts "Name: #{(email if (user.firstname.blank? && user.surname.blank?) && use_email) || "#{user.firstname} #{user.surname}".strip}"
puts "Age: #{user.age}"
puts "Address: #{user.address}"

Akışınız kesintiye uğramaz ve gerekirse belirli ifadeye odaklanabilirsiniz.

Bu senin durumun mu? Kesinlikle hayır!

İlk koşul daha az alakalı - zaten bir yöntemi hak edecek kadar genel olduğunu düşündünüz ve bu yöntem için uygulanmasından çok daha okunabilir bir ad buldunuz. Açıkçası tekrar bir işleve çıkartamazsınız.

İkinci koşul gelince - çevreleyen kodun akışını kesiyor mu? Hayır! Etraftaki kod bir yöntem beyanıdır, onu seçmek nametek amaçtır. Adı seçmenin mantığı, çevreleyen kodun akışını kesintiye uğratmaz - çevreleyen kodun amacı budur!

Sonuç - tüm işlev gövdesini tek astar yapmayın

Akışı kesmeden biraz karmaşık bir şey yapmak istediğinizde tek astarlar iyidir. Bir işlev bildirimi zaten akışı kesiyor (bu işlevi çağırdığınızda kesilmeyecek şekilde), bu nedenle tüm işlev gövdesini bir astar haline getirmek okunabilirliğe yardımcı olmuyor.

Not

Satır içi değil işlevler veya lambda ifadeleri - Ben "tam gaz" işlevleri ve yöntemlere bahsediyorum vardır genellikle çevredeki kodu ve 's akışına sığacak şekilde ihtiyacı parçası.