Her işlev / yöntem argümanını yeni bir satırda listelemek kötü bir fikir midir? Neden?

Ne zaman, bir işlev çağırdıklarında, argümanları yeni bir satıra koyarlar, örneğin;

aFunction(
    byte1,
    short1,
    int1, 
    int2,
    int3,
    int4,
    int5
) ;

Kodun çok küçük olmadığı için çok can sıkıcı buluyorum, bu yüzden mantığa bir anlam vermek için yukarı ve aşağı doğru taramam gerekiyor. Bunun gerçekten kötü bir uygulama olup olmadığını bilmek istiyorum ve eğer öyleyse, onları yapmamaya nasıl ikna edebilirim?

Bu sadece sevebileceğiniz veya sevmeyeceğiniz bir kodlama rehberidir. Önemli olan, siz ve meslektaşlarınızın onu kullanmayı veya kullanmamayı kabul etmenizdir.

Açıkçası, okunabilirliği arttırmanın en iyi yolu, argüman sayısını sınırlamaktır.

Bu bir tercih meselesi. Her bir parametreyi belgelemek istediğiniz veya değişkenlerin oldukça uzun olduğu ve bunların çoğunun olduğu karmaşık işlev çağrıları için bu iyi olabilir.

Örneğin:

do_complex_op(
      0, //Starting state, always 0, ask Joe why
      X, //X-coord of thingy
      y, //Y-coord of thingy
      73, //in this case, we don't want to use Z but want constant 
      dlogMessageTitle, //message for dialogue title
      dlogMessageText, //message for dialogue contents, don't care about this.
      SomethingIP, //IP of something-or-other server, can be NULL, won't crash.
      someObject.childObject.getValue(key1).HVAL, //very long path to HVAL
      someObject.childObject.getValue(key1).LVAL, //very long path to LVAL
      this.parentWindow.owner.mainTextBox.text.value.trim, //get the trimmed text, untrimmed text causes weird output
      pvrMainSettingForLongBlahs.getObjectByPath(somePath),
      pvrMainSettingForLongBlahs.K_TCA_UPPER_LIMIT,
      pvrMainSettingForLongBlahs.K_ENDPOINT_COMPLIANCE_LEVEL,
 );

Adlandırılmış parametrelere izin veren dillerde, parametre adlarını kullanırsanız bu daha yaygındır (örneğin, PL / SQL'de):

PKG_SOME_TEST_CODE.FN_DO_SOMETHING( in_text => 'test text',
                                    in_id => v_id,
                                    in_ref_id => v_ref_id,
                                    out_array_for_storage => v_bArray); 

Ancak, eğer işlev çağrısı basitse ve çok fazla parametre değilse, bunun sinir bozucu olabileceğini kabul ediyorum:

setColour (
    r,
    g,
    b
 );

Olarak okumayı çok daha kolay buluyorum

 setColour(r,g,b);

@ AmmoQ için:

rc=a(b,c(d,e(f)))

rc=a(
     b,
     c(
       d,
       e(
         f
        )
      )
    )

Nadir olduğu IMO her şey olduğu zamanki tarzı üzerinde 's üstünlüğü olumlu kanıtlanabilir sürece kötü uygulama. “Tat alma meselesi”, programcıların çoğu için okunması zor olan kod yazmak için kötü bir bahanedir, çünkü bir gün, o stile alışkın olmayan bir ruhun, o stile uyması gerekmeyecektir.

Alışılmadık olduğunu kanıtlamak nispeten kolaydır, örneklerin kaynağını MSDN'de veya benzeri sitelerde gösterin, büyük açık kaynak kodlu tabanları gösterin vb. Kod güzelleştiricilerin çıktısını gösterin. Başka Everbody nasıl Sonuçta, göstermek senin takımın yapıyor. Kötü bir tarzı kabul etme, çünkü birisi çok inatçı.

Peki, işte bazı aşağı yemi-yem. Popüler bir şeyi yapmakla suçlanmadım. Açıkçası, işler bir satıra sığarsa, o zaman tamam, bunları bir satıra sığdırın.

Ancak benim asıl endişem, kodun "çirkin" veya "güzel" olması değil. Asıl endişem, hata yapmadan anlaşmanın ve değiştirmenin ne kadar kolay olduğu.

Eğer argümanlar uzunsa ve birçoğu varsa, neden onları ayrı satırlara koymuyorsunuz? Aklıma, onların ne olduğunu görmeyi kolaylaştıracak ve gerekirse onları değiştirmeyi kolaylaştıracak. Ayrıca istersem her bir argümana bir yorum eklemek için bana yer veriyor.

Ayrıca, bir argüman listesinin sonunda olandan daha muhtemel olan bir işleve argüman ekler veya kaldırırsam, hata yapma şansını en aza indirmek isterim. Bu nedenle, virgül (,) 'ü bir satırın başına, sonuna kadar koymayı tercih ederim. Ardından, örneğin listenin sonuna bir argüman silmek veya eklemek istersem, tek satırlık bir düzenlemedir. Bütün satırların sonunda, sonuncunun parantez ile bitmesi gereken virgülle dolaşmak zorunda değilim.

Böylece (oğlum, bunun için alev alacağım) şöyle yazarım:

nameOfFunction(firstArgument
    , secondArgument // optional comment
       ...
    , lastArgument   // optional comment
    );

Beş ila yirmi argüman içeren bir işlev olduğunda, işlev aynı anda bu şekilde olmadı. Zamanla büyüdü, bu da birçok düzenleme yapıldığı anlamına geliyordu. Tamamlanmayan herhangi bir düzenleme bir sözdizimi hatası veya bir hatadır. Bu yüzden bunun güzel olduğunu iddia etmiyorum. Düzenlemelerin doğru yapılmasında yardımcı olduğunu iddia ediyorum.

(Ve bunun yerine bir yapıyı geçmem gerektiğini söyleyenler için, tek sorun sorunun yerini almaktır, çünkü yapıyı doldurmak için bir demet kod satırına ihtiyacınız vardır, beyan etmek ve tahsis etmek için fazladan koddan bahsetmek gerekmez.)

Ben de öyle demezdim. Çalıştığım en iyi uygulama, tüm aramayı görmek için önemli miktarda yatay kaydırma yapmanız gerekmediği sürece, tipik olarak işlev çağrılarının tek bir satırda yapılmasıydı. Bu bir yargılama çağrısıdır, ancak şunu söyleyeyim, bunun gibi tüm fonksiyonları koymak , örgütünüzün belirlediği standart olmadığı sürece, satırın dışında kalıyor.

Bu nedenle bir kuruluşun tüm programcıların uyması gereken bir dizi kılavuz oluşturması iyi bir uygulamadır. Her şey tutarlılık ve okunabilirlikle ilgili.

Aşağıdakileri kolaylaştırır:

• Argümanları yeniden sırala.
• Bağımsız değişkenleri yorumlayın veya devre dışı bırakın.
• Sürüm kontrol sisteminizde farklılıkları gördüğünüzde tam olarak hangi argümanın değiştiğini görün
• Bir argüman eklediğinizde veya kaldırdığınızda ya da işlev ismini değiştirirken her şeyi yeniden girmekten ve kelimeyi silmekten kaçının. (Editörünüz otomatik olarak girintili olsa bile, sürüm kontrol sisteminizdeki değişiklikleri izlemenizi zorlaştıran çok sayıda yararsız boşluk değişimi yaratıyorsunuz.)

Standart kod genişliğinizin ne olduğunu önemli ölçüde aşmadıkça, işlev çağrılarının tek bir satırda olması gerektiğini söyleyebilirim (genellikle 80 karakter, genellikle bir argüman nedeni :-).

Bu stile hiçbir avantaj göremiyorum. Öznel bir şekilde çirkin görünüyor ve kod ararken bir acı buluyorum. Örneğin, hızlı bir şekilde aramak ve işlevin NULL olarak geçirilen belirli bir parametre ile çağrılıp çağrılmadığını görmek isteyebilirsiniz. Tüm parametreler bir satırdayken görsel olarak kolaydır ve bu şekilde bölündüklerinde daha zordur.

Bu stili işlev bildirimlerinde veya tanımlarında sık sık gördüm , ancak hiçbir zaman bir aramada (şimdiye kadar). Orada, tek tek parametreler için daha net bir yorum ekleyebildiğiniz için bazen mantıklı geliyor. Arkasındaki nedenleri gerçekten bilmeden bu stili çağrılara kopyalamış gibi görünüyor. Buna karşı iyi bir tartışmanız var ve onun için iyi bir tartışması yok gibi görünüyor, bu yüzden benim oyum var ama ikna etmeniz gereken ben değilim.

Şirketin kodlama standartlarına aykırı mı?

Değilse, standartlar ve insanların neyin değiştiğini görmek istediği hakkında bir tartışma başlatınız. Bunu, değiştirmek istediğiniz şeylerden biri olarak getirdiğinizden emin olun.

Bunun neden yararlı olmadığını düşündüğünüz hakkında tam bir tartışma yapın ve umarım günü kazanırsınız. Meslektaşınızın sizi, onun yolunda en iyisi olduğuna ikna edebileceğinizi asla bilemezsiniz;)

Güncellenmiş bir standarda sahip olduktan sonra, herkesin neye kod vermesi gerektiği belgelenir, böylece meslektaşınız bunu yapmaya devam ederse, kod incelemelerinde yükseltebilirsiniz.

Size korkak gelebilir ama kod üzerinde çalışmayı kolaylaştırır. Yeniden düzenleme yaparken, bağımsız değişkenleri çok kolay bir şekilde yorumlayabilir ve bir şeyleri silmeden önce yeniden denetleyicinizi kontrol edebilirsiniz. Ayrıca türleri kolayca yorumlayabilir ve geçici olarak değiştirebilirsiniz.

Okumak daha kolay:

int f(int, int, int,
      char, double, int
      X const&, Y)
{}

Gösterdiğiniz kadar uçmadım (çok fazla kullanımın olmadığı parametrelerde isim olmadığı için), ancak her parametreyi kendi satırında bölme ya da hiç bölme alışkanlığı edinmedim.

Önemli kısım, kodunuzun standart, 80col ekranlarda basılabilmesi veya gösterilebilmesi ve yine de okunabilir olmasıdır.

Böyle bir şey için nadiren programcının dışına dürüst bir cevap alırsınız. Herkes sadece yaptıklarını ya da yapmadıklarını cevaplayacaktır. Gerçek şu ki, zaman zaman hepimizle mücadele ettiğimiz gibi, buradaki tek "kötü uygulama" sizin kendi esneksizliğinizdir.

Gerçekten kötü olan şeyleri ve sizi rahatsız eden şeyleri ayırt edebilmek için kendinize karşı vahşice dürüst olmalısınız. Gerçek şu ki, C / C ++ ve benzer dillerde, nadiren kodun anlaşılabilirliği üzerinde somut bir etkiye sahip olan bir girinti uygulaması bulacaksınız. Bu tür şeyler hakkındaki tartışmaların çoğu, her iki tarafın da kendi kişisel tercihlerini haklı çıkarmaya çalışmak için gülünç, aldatıcı argümanlar yapan insanlarla istiflenmesine neden oldu.

Okumam için hangisi ... tam olarak bu soruda istediğiniz şey: kişisel tercihinizi haklı çıkarmak için saçma, titiz bir tartışma.

Dürüst olmak gerekirse, kişiye göre değişir. FrustratedWithForms ilk örneğinde gösterildiği gibi karmaşık işlevler için, sonra evet; Aksi takdirde büyük bir NO. O zaman yine bu yüzden IDE'nin fonksiyonelliğini keyfi bir şekilde uygulamayı tercih ediyorum.

“Bunun gerçekten kötü bir uygulama olup olmadığını bilmek istiyorum…”

Evet, değişken listesinin anormal derecede uzun olması dışında, bu kötü bir uygulamadır. Ancak bu durumda, problem muhtemelen fonksiyonun tasarımından kaynaklanmaktadır. Neden birçok parametrenin bulunduğu bir nesneyi iletmiyorsunuz?

“... ve eğer öyleyse, onları yapmamasını nasıl ikna edebilirim?”

Onları bağlayın ve bu saçmalığı durdurmayı kabul edene kadar onları gıdıklayın.

Neden bu kadar önemsiz bir endişe ile ilgili döngüleri boşa harcıyorsunuz? Güvenilir IDE'nizi ateşleyin, dosyayı açın ve yeniden biçimlendirin. İşte bu kadar! İstediğiniz herhangi bir biçimde olacaktır.

Şimdi gerçekten önemli konuya geçelim - vi veya emacs, LOL.

Argümanlar bir satıra sığarsa, bunu söylerim. Olmazsa, o zaman satır başına bir argüman büyük okunabilirlik sağlar.

foo(arg1, arg2, arg3, arg4, arg5)

vs.

foo(
    arg1=arg1,
    arg2=arg2,
    arg3=arg3,
    arg4=arg4,
    arg5=arg5,
    arg6=arg6,
    arg7=arg7
)