Bu sembolik bir sabit overkill kullanımı mı?

Yazılım mühendisliği konusunda oldukça yeniyim ve bir öğrenme alıştırması olarak bir satranç oyunu yazdım. Arkadaşım bir göz attı ve kodumun böyle göründüğünü belirtti.

for (int i = 0; i < 8; i++){
    for (int j = 0; j < 8; j++){

Olması gerektiği konusunda ısrar ederken

for (int i = 0; i < CHESS_CONST; i++){
    for (int j = 0; j < CHESS_CONST; j++){

daha iyi bir sembol ismi ile şu anda düşünmek için canımı sıkmayacağım.

Şimdi tabii ki genellikle sihirli sayılar kullanmaktan kaçınmayı biliyorum, ama o zamandan beri hissediyorum

1. bu sayı asla değişmeyecek;
2. isim kod boyunca pek çok yerde kullanıldığı için bu isim bu kadar açıklayıcı olamazdı; ve
3. Bir satranç programı için kaynak kodundan geçen herkes satranç hakkında 8'in ne işe yaradığını bilecek kadar çok şey bilmeli,

sembolik bir sabite gerçekten gerek yok.

Peki siz ne düşünüyorsunuz? Bu overkill mi, yoksa kongre ile gidip bir sembol kullanmalı mıyım?

Ben isim kesinlikle (gibi daha açıklayıcı olması gerektiğini düşünüyorum gerçi imho arkadaşınız, sembolik adı kullanılarak haklı BOARD_WIDTHyerine CHESS_CONST).

Sayı, programın ömrü boyunca hiçbir zaman değişmeyecek olsa bile, programınızda 8 sayısının farklı bir anlamla ortaya çıkacağı başka yerler olabilir. BOARD_WIDTHTahta genişliğinin kastedildiği her yerde "8" değiştirilmesi ve farklı bir şey kastedildiğinde başka bir sembolik isim kullanılması, bu farklı anlamları açık, açık ve genel programınızın daha okunaklı ve sürdürülebilir olmasını sağlar. Ayrıca, kodun pano genişliğine bağlı tüm kodları hızlı bir şekilde tanımlamanız gerektiğinde, programınız üzerinde genel bir arama (veya ortamınız sağlarsa ters sembol araması) yapmanızı sağlar.

Ayrıca , numaralar için adların nasıl seçileceğini (veya nasıl seçmeyeceğini) bir tartışma için bu eski SE.SE yayınına bakınız .

Bir yan not olarak, burada yorumlarda tartışıldığı için : eğer gerçek programınızın kodunda, değişkenin isatırlara ve jtahtanın sütunlarına mı yoksa tersi olduğuna mı dikkat eder, o zaman değişken isimlerinin seçilmesi önerilir. rowve gibi ayrım netleştirmek col. Bu tür isimlerin yararı, yanlış kodun yanlış görünmesidir.

Tamam, işte birkaç yorumum:

Sihirli sayılardan kurtulmak harika bir fikir. DRY olarak bilinen ve genellikle yanlış tanıtılan bir kavram var, ancak fikir projenizdeki kavramların bilgisini çoğaltmamanızdır. Yani ChessBoard adlı bir sınıfınız varsa, buna bağlı olarak BOARD_SIZE veya ChessBoard.SIZE adlı bir sabit tutabilirsiniz. Bu şekilde, bu bilgi için tek bir kaynak var. Ayrıca, bu daha sonra okunabilirliğe yardımcı olur:

for (int i = 0; i < ChessBoard.SIZE; i++){
  for (int j = 0; j < ChessBoard.SIZE; j++){

Sayı hiç değişmese bile, programınız kesinlikle daha iyi. Bunu okuyan herhangi biri kodun ne yaptığı hakkında daha fazla bilgi bilir.

Kötü bir isim, isimsiz olmaktan daha kötüdür, ancak bu, bir şeyin isimlendirilmemesi gerektiği anlamına gelmez. Sadece adını değiştir. Bebeği banyo suyuyla atmayın. : p Adın ne tarif ettiğini iyi anladığınız sürece açıklayıcı olabilir. Ardından, bu kavram birden fazla farklı şey için kullanılabilir.

Asıl istediğin, ad nauseum adındaki veya çıplak olan ad nauseum referanslarını sabitlere atmak.

for_each_chess_square (row, col) {
  /*...*/
}

Eğer gerçekten bu tür döngüleri tekrarlayarak ve ne olursa olsun tekrarlayarak sabiti çoğaltacaksanız, buna bağlı kalmak en iyisidir 8.

8kendini tanımlayan; başka bir şey için duran bir makro değil.

Asla Gonna'yı (TM) 9x9'luk bir satranç programına dönüştürmüyorsunuz ve eğer yaparsanız, 8'in çoğalması en büyük zorluk olmayacak.

Belirteç 8 için 150.000 satırlık bir kod tabanı arayabilir ve hangi olayların saniye cinsinden ne anlama geldiğini sınıflandırabiliriz.

Daha da önemlisi, kodu modüler hale getirerek satranç bilgisinin mümkün olduğu kadar az yerde yoğunlaşmasını sağlamaktır. Sembolik bir isimle 8'e atıfta bulunan, satrança özgü sorumlulukla bağlanmış otuz yedi modülden, edebi bir 8'in gerçekleştiği bir satrança özgü üç modüle sahip olmak daha iyidir.

Bu 8 sabit programınızdaki bir gerilim kaynağı olduğunda veya bu durumda kolayca düzeltebilirsiniz. Şimdi olan gerçek sorunları düzeltin. Bu belirli 8 tarafından engellendiğinizi hissetmiyorsanız, bu içgüdü ile gidin.

Gelecekte alternatif tahta boyutlarını desteklemek istediğinizi varsayalım. Bu durumda, bu döngüler adlandırılmış bir sabit kullanıp kullanmadıklarını değiştirmek zorunda kalacaklardır 8, çünkü boyutlar board.widthve gibi bir ifade tarafından alınacaktır board.height. BOARD_SIZEBunun yerine varsa 8, bu yerleri bulmak daha kolay olacaktır. Yani bu daha az çaba. Ancak, değiştirilmesi çaba hakkında unutmamak gerekir 8ile BOARD_SIZEilk etapta. Genel çaba daha düşük değil. Birinin kod üzerinde geçiş 8yapması BOARD_SIZEve ardından alternatif boyutları desteklemek için bir başkasının değiştirilmesi, sadece 8alternatif boyut desteğinden geçmekten daha ucuz değildir .

Buna tamamen soğuk, nesnel bir risk / fayda analizinden de bakabiliriz. Programın içinde şimdi çıplak sabitler var. Bunlar sabit ile değiştirilirse, faydası yoktur; program aynı. Her türlü değişiklikte sıfır riski yoktur. Bu durumda, küçük. Yine de, hiçbir faydası olmadan risk alınmamalıdır. Bu akıl yürütme karşısındaki değişikliği "satmak" için, bir fayda varsaymak zorundayız: farklı bir programla yardımcı olacak gelecekteki bir fayda: Programın şimdi bulunmayan gelecekteki bir versiyonu. Böyle bir program planlanmış ediliyorsa, bu hipotez ve ilişkili akıl vardır niyetli bona ve ciddiye alınmalıdır.

Örneğin, bu sabitleri daha da artıracak daha fazla kod eklemekten kaçınıyorsanız, onlardan kurtulmak isteyebilirsiniz. Bu sabitlerin örnekleri, yaklaşık olarak şimdiye kadar varolanların hepsi ise, neden rahatsız ediyorlarsa.

Ticari bir yazılım üzerinde çalıştıysanız, yatırım getirisi argümanları da geçerli olacaktır. Bir program satmıyorsa ve bazı sabit kodlanmış sayıları sabit olarak değiştirmek satışları iyileştirmeyecekse, çaba için tazminat almayacaksınız. Değişimin zaman yatırımının getirisi sıfırdır. Yatırım Getirisi argümanları paranın ötesine geçiyor. Bir program yazdınız, zamana ve emeğe yatırım yaptınız ve bundan bir şey çıkardınız: iadeniz, "R" iniz. Bu değişikliği tek başına yaparak, "R" den daha fazlasını elde edersiniz, ne olursa olsun, o zaman elbette. Daha fazla gelişme için bir planınız varsa ve bu değişiklik "R" inizi geliştirirse, aynen öyle. Değişiklik sizin için acil veya öngörülebilir "R" içermiyorsa, unut gitsin.