Bu iki değerli programlama uygulamasını sık sık duyuyorum: (1) kod satırı 80 veya daha az karakter olmalı ve (2) değişkenler, yöntemler, sınıflar vb. İçin açıklayıcı adlar kullanmalı. Ancak bu iki tavsiye kelimesinin de gerekçelerini anlıyorum. , sık sık birbirlerinin ödünleşimleri gibi görünüyorlar. Kodumu 80 karakter / satırın altında tutarsam daha az açıklayıcı adlar kullanırım (özellikle her girintinin 4 karakter olduğu sayılan Python'da), ancak daha açıklayıcı adlar kullanırsam, 80 karakterden uzun satırlarla sonuçlanırım.

Öyleyse sorum şu iki seçim tavsiyesinden hangisinin seçim yapılması gerekiyorsa uyması daha önemli? Bunu bağımsız (hobi) bir programcı olarak merak ediyorum, ama daha da önemlisi, daha büyük bir şirkette çalışan bir yazılım mühendisi açısından.

Girintilerinizi az, adlarınızı açıklayıcı tutun ve bir satırı kırmaktan korkmayın.

Girintilerinizi az tutun.

Genellikle kendimi girintiler ile açıklayıcı adlandırma arasındaki bir mücadelede bulduğumda, bir adım geriye gidip girinti düzeyime bakarım. 3 veya 4 seviyeden daha fazla girintiliyorsanız (2 seviye birçok durumda otomatik ve kaçınılmazdır. Oku: sınıf yöntemi tanımı), kodunuzu yeniden yapılandırmak, bir işlevi veya yönteme işlevselliği soyutlamak isteyebilirsiniz.

Adlarınız açıklayıcı

Adlarınızı her zaman açıklayıcı tutmalısınız. Açıklayıcı isimler kendi kendini belgeleyen kodlar oluşturur. Bazı durumlarda adları kısaltmayı deneyebilirsiniz, ancak önce okunabilirlik gelir.

Çizgiyi kırmaktan korkma

Kahretsin olur. 80 karakterin üzerine çıkarsanız ve hatta herhangi bir boşluk geri kazanmayı görmüyorsanız - onu kırın. Çoğu dil satır sonlarını umursamaz, bu nedenle satırı birden çok bölüme ayırın. Sadece rastgele bir yer seçmeyin. İşleri mantıksal olarak gruplandırın ve çizgiyi kırdığınızda başka bir seviyeye girinti uygulayın.

Neden ikisi de olmasın?

Her şeyden önce, "tanımlayıcı" ve "ayrıntılı" aynı değildir. Örneğin, oldukça yerel bir döngü yazıyorsanız i, döngü değişkeni için çok iyi bir değişken adıdır; current_iteration_indextartışmasız daha açıklayıcı ve kesinlikle daha ayrıntılı olsa da, çok daha kötüdür ve hiç bilgi eklemez, çünkü ibir döngü değişkeni olarak kullanımı hemen hemen evrensel olarak kabul edilir ve bundan başka bir anlamı yoktur i.

İyi değişken isimleri açıklayıcıdır, çünkü dilin deyimine ve kod tabanının kurallarına aşina olan bir programcı rollerinin ne olduğunu kolayca tahmin edebilir, ancak işleri kompakt tutacak kadar özlüdür.

80 karakterlik sınır, 1970'lerin metin terminallerinin teknik sınırlamalarının bir sonucu olarak, bugün hala birçok kişi tarafından değer görüyor ve hala teknik nedenler olsa da (bazı ağ protokollerinde maksimum satır uzunlukları, özellikle e-posta ile ilgili), daha zorlayıcı nedenler psikolojik ve sosyal nedenlerdir. 66 karakter işaretinin etrafındaki satır uzunluklarının doğal dil nesirleri için en rahat okuma deneyimini sağladığı ortaya çıkıyor (yazı tipi boyutu ilginç bir şekilde çok fazla bir fark yaratmıyor ve sonuç olarak ekran veya kağıt boyutu da yok); 80 karakterlik çizgi sınırları buna oldukça yakındır, ancak tipik bir kod parçasının büyük kısmı genellikle en az bir veya iki seviyeye girintili olduğundan (girinti ayarlarına bağlı olarak 4 ila 16 karakter arasında anlamına gelir),

80 karakterlik çizgilere yapışmanın bir diğer etkisi de, işlerin ne zaman çok karmaşık olduğunun oldukça iyi bir göstergesidir. Uzun satırlara genellikle aşağıdakilerden biri neden olur:

• Uzun bir argüman listesi olan fonksiyonlar; bu olması hoş bir şey değildir, çünkü okunabilirliği engeller ve kolayca hatalara neden olabilirler, örneğin insanlar argüman sırasını derleyicinin yakalayamayacağı bir şekilde değiştirdiğinde.
• Genellikle koşullu olarak bulunan karmaşık ifadeler (örn. if ((user.isLoggedIn && user.hasPermission(page.getRequiredPermission()) && !user.isBanned) || page.getRequiredPermission() == null)); bunun da çözülmesi oldukça zordur ve kod daha yapılandırılmış bir şeye yeniden yazılmalıdır. Büyük olasılıkla, ifade çok fazla şey yapar ve bir yönteme veya işleve dahil edilmelidir.
• İşlev çağrılarında veya ifadelerinde kullanılan uzun değişmez değerler, ör print(translate(LANG_EN, LANG_ES, "This is the home page. Feel welcome to click around and see what we have."));. Değişmezi bir değişkene veya sabite taşıyın; yine de satır uzunluğunu aşabilir, ancak tutarlı bir şekilde yaparsanız, okuyucu, sadece hazır bilginin geri kalanının takip ettiği varsayılarak, çizginin görünmez kısmını en azından güvenli bir şekilde göz ardı edebilir. Veya daha da iyisi, değişmezleri kodun dışına ve bir dış veri deposuna (dosya, veritabanı, her neyse) taşıyın.
• Derin iç içe ifadeler, örneğin ifbir sınıf yöntemindeki altı deyim düzeyi ( tipik ayarlar için 32 girinti sütunu). Yine, derin yuvalama karmaşık ve okunması zor kod oluşturur ve veba gibi kaçınılmalıdır - basitçe, derin yuvalama okuma sırasında insan beyninin yığınını taşar.

Tüm bunlar sonuçta uzun vadede kod tabanınızda olmasını istemediğiniz şeylerin belirtileridir ve 80 karakter sınırlarını zorlamak, karmaşıklığı düşük ve okunabilirliği korumanıza yardımcı olan güzel ve basit bir yoldur. (Bu, 80 sütuna mükemmel okunamayan kod yazamayacağınız anlamına gelmez: çeşitli gizli-şey-kod yarışmaları açık bir karşı örnektir).

Açıklayıcı adlandırma FAR'a göre daha önemlidir. Çoğu arayüzde daha uzun çizgiler görmek için kaydırılabilir. Hiçbir durumda sistem, kötü adlandırılmış değişkenleri ve işlevleri çevirmenize yardımcı olamaz.

Satır başına 80 karakter, adlandırma uzun olsa bile zor değildir, çünkü uzun kodun tek bir satırını birden fazla kısa koda bölmenin birçok yolu vardır, örneğin, 40'tan az sığacak şekilde C'deki bir koşul ifadesini birden çok satıra bölebilirim karakterler,

if ( a == b || c == d  || d == e
    || c == e || c == a || c == k
    || c == l)

işlev çağrısını da birden çok satıra bölebilirsiniz.

Bu nedenle, hem tanımlayıcı adlandırma kurallarının hem de 80 karakter satırının çelişkisi yoktur, okunabilirliği artırmak için bir arada bulunabilirler.

80 sınırı, uzun zaman önce arttırılması gereken bir şeydir. Bu sınırlamanın, her tanımlayıcının uzunluğunun 8 karakterle sınırlı olduğu ve ekranda / yazıcıda yalnızca bir yazı tipiyle yaşlandığından beri kullanıldığını unutmayın. Yazı tipi boyutunu değiştirme imkanı yoktur.

Tanrım, şimdi farklı ekran ve baskı teknolojimiz var. Çok farklı programlama dilleri var. Artık 80 karakter kullanmak için bir neden yok. En az 120 karaktere çıkar.

O zaman bile zor bir sınır olmamalı. Satırdan bir karakter mi gidiyorsun? Hiçbir şey olmuyor!

Düzenle:

80 karakterlik limit tarihi hakkında detaylı cevaplar

Wikipedia'da Satır Başına Karakter

Wichita Eyalet Üniversitesi'nde yapılan bir araştırma, CPL'nin okunabilirlik üzerinde sadece hız ve kavrama faktörleri de dahil olmak üzere sadece küçük etkileri olduğunu buldu. Bununla birlikte, tercih istendiğinde, katılımcıların% 60'ı, çalışmada kullanılan en kısa (35 CPL) veya en uzun (95 CPL) hatlar için bir tercih belirtmiştir. Aynı zamanda, katılımcıların% 100'ü bu miktarlardan birini en az arzu edilen olarak seçmiştir.