Kodlama Rehberi: Yöntemler 7'den fazla ifade içermemeli midir?

C # için AvSol Kodlama Kılavuzuna bakıyordum ve neredeyse her şeye katılıyorum ama başka bir kural hakkında ne düşündüğünü görmek gerçekten merak ediyorum.

AV1500

Yöntemler 7 ifadeyi geçmemelidir. 7'den fazla ifade gerektiren bir yöntem çok fazla veya çok fazla sorumluluk alıyor. Ayrıca, kodun ne yaptığını anlamak için insan zihninin kesin ifadeleri analiz etmesini gerektirir. Kendini açıklayan isimlerle, çok sayıda küçük ve odaklanmış yöntemle parçalayın.

Çoğunuz bu kurala uyuyor mu? Yeni bir yöntem oluşturmaktan kurtarılacak çok az şey olsa bile (kodunuz hala KURUYOR ) okunabilirliği büyük ölçüde arttırmanın yanı sıra? Ve numaran hala 7'ye kadar mı düşük? 10'a daha fazla eğilirdim.

Her yerde bu kuralı ihlal ettiğimi söylemiyorum - aksine, yöntemlerin% 95'i küçük ve odaklanmış ancak bu kuralı asla ihlal etmemen gerektiğini söyleyerek beni gerçekten mahvettim.

Gerçekten herkesin ASLA bu kuralı ihlal etmeyeceğini düşündüğünü bilmek istiyorum (Kodlama standardında '1' - yani ASLA bunu yapmayın). Ama bence olmayan bir kod temeli bulmakta zorlanacaksınız.

Bu bana bir "standart kokusu" dir. Kodlama standartlarını kendi sınırlarında görebildiğim zaman endişeleniyorum. Neredeyse her zaman bir yöntemin standart izin verdiğinden daha büyük olması gereken bir durumla karşı karşıya kalırsınız (satır uzunluğu / sayısı, değişken sayısı, çıkış noktası sayısı vb.). Standartlar daha çok kurallara benzer olmalı ve iyi karar vermek için yeterli yer bırakmalıdır. Beni yanlış anlamayın, standartlara sahip olmak iyidir, ancak “vekaleten mikro yönetim” olmamalıdır.

Eşyaları küçük yöntemlere ayırmak genellikle iyi bir fikirdir. Fakat önemli olan şeyleri mantıklı bir yerlere bölmektir.

Eğer ayrılmak mantıklı değilse, ayrılmayın. Bu genellikle bazı prosedürler veya GUI kodları için geçerlidir.

Steve McConnell , Code Complete'de kısa yöntemleri kullanırken her zaman daha üretken olmadığınızı belirtti . Mantıklı gelmediğinde bölünürseniz, hiçbir fayda için koda karmaşıklık eklersiniz.

Her zaman kurallarda olduğu gibi, kısıtlamaların neden mevcut olduğunu hatırlamak iyidir, böylece ne zaman geçerli olmadığını öğrenebilirsiniz. Kodun çoğunda yöntemler kısa olacaktır, ya da muhtemelen DRY ya da endişelerin ayrılması ile ilgili bir probleminiz var . Fakat durum böyle değilse, sorun değil.

Bir kural olarak kabul edilmelidir.

"En fazla 80 (100,120) metin sütunu", "yöntem başına bir çıkış noktası", "en fazla 2 iç içe geçme düzeyi" gibi şeyler kod kokusu göstergeleri için eşik dediğim şeydir. Bazen onları ihlal ediyorsanız, kodun kötü olduğu anlamına gelmez. Onları sürekli olarak ihlal ettiğinizi tespit ederseniz, kodda bir şeyler kokar ve duraklatmak ve yaklaşımınızı yeniden düşünmek isteyebilirsiniz.

Bana göre, en önemli kriterler "Bu kod anlaşılabilir mi?", "Tekrarlı mı?", "Mantıksal yerlerde mi bozuluyor?", "Gevşek bir şekilde bağlandı mı?" Birkaç tane var, ancak temel düşüncenin Donald Knuth'un tavsiyesini hatırlayarak özetlenebileceğini düşünüyorum: "Programlar insanlar tarafından okunmak içindir ve sadece bilgisayarların çalışması için tesadüf eseridir."

Yöntemlerimdeki ifadelerin sayısını gerçekten saymak için hiç zaman ayırmadım, ancak tek ve açık bir amacı net bir şekilde yerine getiren yöntemler yazmaya gayret ediyorum. Kodunuz temiz, okunaklı olduğu ve DRY ve Tek Sorumluluk ilkelerini takip ettiği sürece muhtemelen işinizi yaptınız. Yedi ifadeli limiti uygulamak için bir yöntemi keyfi olarak bölmenin kodunuzu daha az okunabilir / sürdürülebilir hale getirebileceğini düşünüyorum.

Yaklaşık

Bu tür kurallar tam anlamıyla alınmamalıdır. " Yöntemler kısa olmalı " diyebilirdi . Bununla birlikte, bazı insanlar bunu "1 sayfadan az" ve diğerleri "en fazla 2 satır" olarak yorumlayacaklardır.

Size kaba bir fikir vermek için "7 ifade" dediklerini sanıyorum ("7 hakkında" demeleri gerektiğini düşündüğüm halde). Arada bir 9'a ihtiyacınız varsa, terlemeyin. Ancak, 20'ye vurursanız, bu kural için doğru oyunda olmadığınızı bileceksiniz.

7 kesinlikle hiçbir önemi olmayan tamamen keyfi bir sayıdır.

Döngüsel karmaşıklık ifade sayısından daha büyük bir konudur. Tek bir yöntemde (korkunç olduğunu düşündüğüm) 100'lerin ifadesini içeren bir kod gördüm, ancak 1'in döngüsel karmaşıklığı vardı ve gerçekten sadece 1 şey yaptı. Çok fazla adım atıldı. Bunu daha küçük yöntemlere bölmeyi tartıştık, ancak bu yöntemlere yalnızca bu yöntemle çağrılabilirdi.

Bu oldukça aşırı bir durum olsa da, önemli olan nokta DRY kodunu ve düşük döngüsel karmaşıklığı korumanız gerektiğidir. Bu, bir yöntemdeki satır sayısından daha önemlidir.

Örneğin bir switch / case ifadesi alın. Eğer 7'den fazla olası değeriniz varsa, değerlendirmeyi birden fazla yönteme ayırmanız mı gerekiyor? Tabii ki hayır, bu aptalca olurdu.

Yapay olarak kodu sadece 7'nin altındaki ifadelerin sayısını korumak için daha fazla yönteme bölmek, yalnızca kodunuzu daha da kötüleştirir.

Yönerge olmalı Her yöntem 1 şey yapmalı ve kodunuzu KURMALIDIR.

Şey, biraz değişir. Veritabanlarına erişen çok sayıda kod yazıyorum. İstisna işleme için kazan plakası kodu, birçok durumda uzun süren yedi ifadeden daha fazladır. En iyi rehberin, işlevin bir amacı olduğundan emin olmak olduğunu söyleyebilirim.

Her şey bir takas. Önerilen yaklaşımla ilgili sorun - her yöntemin kısa olması için çeşitli yöntem ve sınıflara yeniden yansıtma - farklı nedenlerle rağmen, uç noktalarına alındığında okunamayan kodlara yol açmasıdır.

foo()7 şey yapan bir yöntem düşünün . 7 şeyin çok fazla olduğunu iddia edebilirsiniz. Belki de çoğu zaman haklısın. Öte yandan, bu 7 şey yakından ilişkili olabilir; mantık düzgün akabilir ve nesir gibi okuyabilir; Gerçekten ihtiyaç duyduğunuzda bunu anlamakta hiç zorlanmayabilirsiniz. Daha da kötüsü, 7 kaynağın büyük bir kaynak ağacına dağılmasını sağlamaktır, böylece size bakarsanız, foo()7 farklı yere bakmadan ne yaptığı hakkında hiçbir fikriniz yoktur.

Birçok insan kafasında böyle kurallar elde eder ve sonuç OO spagetti olarak düşündüğüm şeydir. Her şey, her yerde meydana gelen küçük atomik mikro işlemlerle, kendi küçük yönteminde veya sınıfında kutulanmış, düzenli. Ancak böyle bir kod tabanına yeni gelmek ve ne yaptığını bilmek mümkün değil. Sen kayboldun.

bu kötü bir rehber değil. Yeterince iyi bir şekilde gruplandırılıp birbirleriyle ilişkilendirildiği sürece, asla ayrılma yöntemlerini ve sınıflarını (çok fazla şey bulamadım).

İşin püf noktası dikey olarak ÇIKARMAMAK (Bir yöntemi bir noktada sıkıştır ve yenisini başlat). Birim testinde olduğu gibi hile, böyle bir kuralı baştan beri aklınızda tutmaktır, böylece daha iyi tasarlarsınız, başka bir yönteme 3 veya 4 ifadeyi başka bir yönteme bırakmak gerekir; kodunuzun ortasındaki bu 3 veya 4 ifadeler.

Bu tür bir bölünme, keyfi ve yalnızca bir kez kullanılsa bile, daha sonra yeni bir kod netliği nedeniyle daha iyi yeniden alevlenmelere neden olabilir, bu daha küçük sınıflar için de geçerlidir.

Birim testi yapacağınız gibi düşünün. Gerçekten sonra birim testini eklemeye çalışırsanız, zor ve bazen imkansız görünür, ancak baştan tasarlarsanız, aslında tüm kodunuzu daha iyi hale getirir.

Özet? "7'den az ifade kullan" tasarımının "7'den fazla ifade kullandım" kodunun kokusunu karşılaştırması durumunda, kod kokusunu ortadan kaldırmayı tercih ederim.

Vaov! Yöntemlerinizin çok küçük olması gerektiğini söyleyen basit bir kılavuz üzerinde bu kadar yoğun bir tartışma bulmayı beklemiyordum. Her zaman kurallarının açık olmasını isteyen geliştiriciler oldukları için, 7'yi seçtim çünkü bu iyi bir eşik gibi geldi.

Bazılarınız belgenin başında feragatnameyi zaten verdiniz. Ancak açık olmak gerekirse, bu belge daha iyi kod yazmanıza ve daha iyi sistemler tasarlamanıza yardımcı olan bir kılavuzlar koleksiyonunu temsil eder. Bir kılavuz bir seviye 1 olarak işaretlenmiş olsa bile, hiçbir şeyin kural olması gerektiğini asla söylemedim.

Ayrıca hiçbir zaman uzman olduğunu iddia etmedim. Ancak bu meslekte 15 yıldır, 4 yıllık C ++ deneyimim ve 11 yıllık C # deneyimim var. Aslen Industrial Strength C ++ 'a dayanıyordu, ancak o zamandan beri toplumdan gelen girdilerle hassaslaştırıyorum.

Ne olursa olsun, yükseltmeye çalıştığım nokta kendin için düşünmeye devam etmen gerektiği. 7 ifadenin kılavuzunun faydalı olmadığını düşünüyorsanız, daha uzun sürmekten daha iyidir. Heck, arada bir bu kılavuzu bile ihlal ediyorum. Sadece bilinçli bir şekilde ihlal ediyorum ve sonuçlarını kabul ediyorum.

Birincisi: bu bir kuraldır, kural değil. Buna rehber denir, lütfen ona böyle davranın. Bu, kendi kararınızın da gerekli olduğu anlamına gelir (her zaman olduğu gibi)

Bunun dışında, bu kısıtlamaya uymayan çok sayıda iyi kod örneği düşünebilirim. Sadece bir rehber olmasına rağmen, fakir bir.

Üstümdeki ifadeye katılıyorum. Bu sadece bir kılavuzdur ve mükemmel bir dünyada her şey, her programda tekrar kullanılan nesneler ve dünya da güzel bir yer olacaktır. Her zaman doğru değildir ve bazen bu çok fazla ek yüke veya boşa kaynaklara yol açacaktır. Bunu da aklında tutmalısın.

Karışıma istisna kullanımı eklediğinizde oldukça saçma.

"Deneyin, yakalayın, nihayet" den sonra, yöntem başına dört cümle ile kalırsınız!

Ayrıca, 20 ayrı alan formu için "validateForm" metodunu göz önünde bulundurun, tüm bireysel onaylamaları ayrı metotlarla yapsanız bile, çağırmak için 20 alan doğrulama metoduna sahipsiniz. Bu kılavuzlara göre "validateTopOfScreen", "validateMiddleOfScreen" ve "validateBottomOfScreen" gibi bazı anlamsız bölmelere sahip olursunuz.

Soru, "kuralları" "kurallar" ile birleştirmektir. Kurallara uyulması amaçlanmıştır - kurallar, ne yaptığınızı ve gerçekten daha iyi bir şekilde yapılıp yapılmadığını düşünmenize neden olacak tavsiyelerdir.

Bence ortalama olarak, çoğu programlama muhtemelen yönergeleri izleyerek daha da gelişmiştir ancak yönergeleri dogmatik olarak izlemenin çözülenden daha fazla soruna neden olacağı durumlar her zaman olacaktır. Bu yüzden kural değil, kural olarak sunulurlar.

Önceki bir cevaplayıcı, rehberin yazarlarının asla dogmatik olarak kullanılmalarını istemediklerini ve bu etkiyi belgelerine dahil ettiklerini göstermiştir.

Yukarıdaki yorumların haberi ile aynı fikirdeyim. 7 benim için sağlıksız ve yakut olan bazı dillerde faydalı olabilir, ancak C #, Java, C ++ gibi diller için bu "7 satırlı" kuraldan şüpheliyim. Size bir örnek vereyim. Mevcut uygulamanın 22 metin alanı var ve sunucu tarafında doğrulama yapıyorum. Yönteme validateInput () adı verilir ve tercihim, checkEmailFormat () gibi karmaşık bir şeyi doğrulamadığım sürece, tüm alanları tek bir yöntemde doğrulamaktır. Yani temelde validateInput yöntem kodum, zaman zaman karmaşık doğrulamaya çağıran 108 satırdır.

Şimdi, her bir alanı doğrulamak için 25 yöntem çağırdığımı düşünün. Eğer yeni bir geliştirici gelirse ana yöntemden içeri girip çıkması gerekecek ve sırayla birkaç tane arayabilecek olan 25 yöntemi atlayacaktır. Büyük projelerde kaybolmak zorunda.

Kodumu netleştirmek için gerçekten yaptığım şey, temelde bu 4 satırın ne yaptığını söyleyen temiz yorumlar sağlamaktır.

validateInput (UserObj kullanıcısı) {

// İlk adı doğrula ....... ......

// soyadını doğrula ...... ......

// e-postayı doğrulayın ..... // e-posta biçimini kontrol etmek için çok karmaşık düzenli ifade checkEmailFormat (); .... .....

ve bunun gibi.. }

Kötü kural İstisnaların ele alınması, veritabanı alanlarının belirlenmesi, doğrulanması, çoğu yöntem yedi ifadenin altında nasıl olabilir? Satır içi lambda işlevlerini asla yapmamalı mıyız?

Kod satırları rastgele bir karmaşıklık sayısıdır. Eklenti yöntemleri ile gibi kodlar oluşturabilirim

                Parallel.ForEach(regions, region => {   Console.Write(region.Resorts.Where(x => x.name == "Four Seasons").OrderBy(x => x.RegionId).ThenBy(x => x.ResortId).ThenBy(x => x.name).ToList());   });

Tüm genç programcılar bu ilkeye uymaya zorlanmalıdır. Bu, onları daha fazla satır kodu eklemek yerine, meşgul oldukları şeyin yapısı hakkında düşünmeye zorlar.

Şu anda 550 ifadeli kod yöntemine birçok if ifadesi ve devam edip geri dönüşlü bir yöntem arıyorum. Bu saçmalık. Programcı sadece ne yaptığını düşünmeye zorlanmış olsaydı ...