Koddaki satır sayısını azaltmak ne kadar önemlidir?

J2SE (core java) üzerinde çalışan bir Yazılım geliştiricisiyim.
Genellikle kod incelemelerimiz sırasında kodumuzdaki satır sayısını azaltmamız istenir.

Gereksiz kodu kaldırmakla ilgili değil, kodda daha az satırla aynı şeyleri yapmaya odaklanan bir stil izlemekten ibarettir, bununla birlikte satır sayısını artırmak anlamına gelse bile kodda açıklığa sahip olduğuma inanıyorum.

Sizce şeyleri yapmanın doğru yolu nedir?
LOC (kod satırı) küçük bir sayıysa, kodu nasıl etkiler? LOC daha büyük bir sayı ise, kodu nasıl etkiler?

web sitesinden örnek: "javaranch" -

public static void happyBirthday(int age)
{  
    if ((age == 16) || (age == 21) || ((age > 21) && (((age % 10) == 0) || ((age % 25) == 0))))        
    {
        System.out.println("Super special party, this year!");
    }
    else
    {
        System.out.println("One year older. Again.");
    }
}

VS

public static void happyBirthday(int age)
{

    boolean sweet_sixteen = (age == 16);
    boolean majority = (age == 21);
    boolean adult = (age > 21);
    boolean decade = (age % 10) == 0;
    boolean quarter = (age % 25) == 0;

    if (sweet_sixteen || majority || (adult && (decade || quarter)))
    {
        System.out.println("Super special party, this year!");
    }
    else
    {
        System.out.println("One year older. Again.");
    }
}

Ölçümlerle ilgili sorun, ne kadar iyi amaçlanmış olursa olsun, maddenin ölçülmesi eylemi onu önemli kılar ve sonuç olarak, bir öğeyi ölçmeme eylemi onu önemsiz kılar. Neyin önemli olduğunu ölçmek kesinlikle önemlidir ve neyin önemsiz olduğunu ölçmemelidir.

SLOC'u ölçmek (Yorumlarınızın ne kadar etkili olduğunu), SLOC'yi önemli kılıyor .... SLOC önemli mi? - kesinlikle hayır, asla ( Karışık programlama yarışmaları dışında ), asla ticari bir organizasyonda bulunmayacak.

Kendinize basit bir soru sorun: "Bu rutinin SLOC'sini azaltın" herkesin kodunu nasıl daha iyi hale getirir? Muhtemelen bu durumda olan şey, SLOC'nin karmaşıklığı ölçmek için saf bir yol olarak kullanılmasıdır. Ne pahasına olursa olsun kaçınmanız gereken, kolay sayılan fasulyeleri saymaktır - önemli olanları saymak yerine SLOC gibi objektif önlemler, fakat sayılması zor olanları - örneğin Okunabilirlik, karmaşıklık vb.

Kod gözden geçirmene katılıyorum ama yıldız işareti ile aynı fikirdeyim. Kodunuza yazdığınız her ifade teknik bir sorumluluktur - bu potansiyel bir başarısızlık noktasıdır. 10 ifadeli bir yöntem yazarsanız ve iş arkadaşınız 5 ifadeyle aynı işlevselliği sağlayan bir yazar yazarsa, bunun sorunların olasılığı ile ölçülen “daha ​​iyi” olması muhtemeldir (kodunuzun yanlış olabileceği iki kat fazla olabilir, aşırı karmaşık veya sorunlu).

İşte yine de yıldız işareti. Bu fikirdeki gerçek kod satırı sayısıyla ilgili değil, çünkü aşağıdaki gibi satır sayısını azaltabilirsiniz:

void someMethod() {   
 someobject.doSomething(someSingleton.getInstance().with().a().lot().of().law().of().demeter().violations()).and().if().that().werent().enough().theres().more();
}

Bu bir kod satırı, ancak inanılmaz miktarda şeyin yanlış gidebileceği bir yer. Bu yüzden, en az ifadeyle en iyisini yapmaya odaklanmam gerektiğini söyleyebilirim - işleri halletmek için ihtiyaç duyduğunuz kadar kod yazıp daha fazlasını yapmayın. En azından, kod gözden geçirenlerin kullandığı şey bence.

Şahsen, vurulacak bir denge olduğunu düşünüyorum. Söylediğim gibi, yazdığınız her ifade bir sorumluluktur, ancak açıklayıcı bir adla yerel bir değişken çıkarmak, yönteminizi çok daha net ve daha okunaklı hale getirirse, bunun için de yapılması gereken bir durum vardır. İnsanların nispeten küçük estetik farklılıklar üzerinde titreyen durumlara kolayca girebileceğinizi düşünüyorum, ancak genel olarak, gözden geçirenlerin doğru bir fikre sahip olduğunu düşünüyorum - yanlış gidebilecek şeylerin sayısını en aza indirmenin lehine.

Hakemlerin tavsiyelerine tam anlamıyla bakmak, hiçbir işe yaramayacaktır, çünkü açık doğrudan sonuç tek taraflı gömlekleri teşvik etmektir (buna rağmen çizgi uzunluğu sınırı). Burada öğrenilecek dersin , kodunuzun daha az şey yapmasını sağlamak olduğuna inanıyorum .

Başka bir deyişle, bu basitlik çağrısıdır. Kodun varlık değil bir sorumluluk olduğu iddiası oldukça popülerdir , bu nedenle işlevselliğini korurken miktarını azaltmak asil bir çabadır. Bu, sorunu doğrudan ele alan ve özlü çözümleri tercih eden doğrudan, daha aşağıdan yere bir yaklaşımla gerçekleştirilebilir.

Ken Thompson'un bir keresinde dediği gibi: En üretken günlerimden biri 1000 kod satırı atıyordu .

"Satır sayısını artırmak anlamına gelse bile kodda açıklığa sahip olma" konumunuzu kabul etme eğilimindeyim.

Oldukça özlü olan çok fazla tek gömlek gördüm, ancak yaptıkları hemen belli değil. Okunabilirlik kraldır, çünkü diğer geliştiriciler kodunuzu korumalıdır.

Amaçlanacak daha iyi bir şeyin kısa yöntemler olduğunu iddia ediyorum. Birkaç kod satırı için kısa değil, tek bir şey yaptıkları için kısa.

Şu anda büyük bir şirket için kıdemli bir uygulama geliştiricisi ve proje iş analisti olarak çalışıyorum ve gelişimimin satır sayısı hiç bir zaman ilgi çekici olmamıştı. Ancak, bir kodun ne kadar yoğunlaştırıldığının daha iyi olabileceğine inanıyorum, ancak çabuk bir şekilde analiz etme ve düzeltme (veya ekleme) pahasına olamaz. Bana göre, çok geniş bir ölçeklenebilirlik seviyesine sahip olması gereken ve sürekli değişmeyen bir ortamda anında değişiklik yapabilen Kritik bir uygulama sorumlusuysanız, özlü, okunması kolay kod geliştirme konusunda en önemli unsurlardan biri. . Kredi için Erik Dietrich'in cevapta , bu:

void someMethod() {   
someobject.doSomething(someSingleton.getInstance().with().a().lot().of().law().of().demeter().violations()).and().if().that().werent().enough().theres().more();
}

benim için tamamen kabul edilemez olurdu, ancak şu anki kodları değiştirerek buldum.

if (boolean == true){
value.prop = option1;
}
else{
value.prop = option2;
}

için:

value.prop =  boolean ? option1 : option2;

okunabilirliği feda etmeyen mükemmel bir kod yoğunlaştırma seçeneğidir.

Kodu nasıl etkilediği kadarıyla? Diyelim ki, 100 kod satırından herhangi bir performans artışı veya düşüşü görmedim. Basit gerçek şu ki, nihai ürüne ulaşmak için kullandığınız işlem, oraya ulaşmak için harcadığınız satır sayısından daha fazla. Çok yoğun yazılmış, ancak verimsiz, daha iyi kod akışı olan daha uzun kodlardan farklı performans gösteren bazı işlemler gördüm.

IMO, önemsiz bir LOC sayımıyla kod etkinliğini ölçmek kötü bir fikirdir. Doğru tasarlanmış ve etkili kod kılan daha çok şey var.

Tecrübelerime göre, etkili kod:

• SOLID ilkelerinin hiçbirini ihlal etmiyor
• okunabilir ve kendi kendini açıklayıcı
• Albert Einstein'ın basitlik testini geçiyor: "Her şey mümkün olduğunca basit yapılmalı, ancak daha basit olmamalı."

Burada, LOC’yi düşük tutmanın teknik avantajlarını ve dezavantajlarını ve anlamlı bir kaliteli yazılım ölçütü olup olmadığını ele alan pek çok cevap var. Bu, bununla ilgili değil. Bunun anlamı, belirli bir kodlama kuralına saf bir dogmatik bağlılık konusunda ısrar eden yönetim ile nasıl başa çıkılacağıdır.

Ne yazık ki, insanların uygun bağlamda kullanıldığında ve pragmatik olarak uygulandığında iyi tavsiye olan şeylere mandallaşma, bu bağlamdan çıkarma ve dogmatik olarak uygulamada, tavsiyenin ilk etapta hafifletmek için var olan sorunları takdir etmemek oldukça yaygındır. .

LOC’yu düşük tutmaya yönelik tavsiyelerin amacı tek seferde çok fazla şey yapmaya çalışan metotların yaratılmasından kaçınmak ve kendileri olmayan bir tasarım hakkında çok şey bilen “tanrı sınıflarının” yaratılmasını engellemektir. doğrudan sorumluluk ve sistemdeki diğer tüm sınıfların hangilerine dayandığı. Kısa kodun bir başka avantajı, daha okunabilir olmasıdır, ancak belirttiğiniz gibi, okunabilirliğin gerçekte acı çekmeye başladığı noktaya geçebilirsiniz.

Düşük LOC sayımlarının bariz avantajları vardır (küçük yöntemler kafanıza büyük olanlardan daha kolay uyar, koddaki daha az şey yanlış gitmek için daha az şey anlamına gelir, vb.), Ama aynı zamanda azalan verim yasasına tabidir. 150 çizgi yönteminin 20 çizgi yöntemine yeniden yansıtılması, 10 çizgi yönteminin 7 çizgi yöntemine yeniden yansıtılmasından çok daha büyük bir kazançtır.

Böyle bir yeniden düzenleme, başka iyi yazılım tasarımının başka yönleriyle (okunabilirlik gibi) pahasına olduğunda, bunu yapmamayı haklı çıkarabileceğiniz bir noktaya ulaştınız. Kodun ne anlama geldiğine bağlam veren değişkenleri kaldırmak ve bunları değişmeyen harflerle değiştirmek, yapmak için çok kötü bir şeydir. İyi kodun içinde neredeyse hiç değişmez vardır. Bununla birlikte, bu değişkenler (ve isimlendirilen sabitler) programa doğrudan katkıda bulunmayan kod satırlarıdır ve eğer LOC bir tür tanrı olarak tapınıyorsa, bu açıklama satırları hızlı bir kazanç için budanmış olmanın tehlikesi altındadır ve yönetimden bazı yanlış yönlendirilmiş övgüler.

Bunu gerçekleştirecek kadar akıllı olduğuna inanıyorum, aslına bakarsanız asıl sorunuzun etkisi bu. Sorun, kod azaltma işleminin ne zaman iyi olduğu ve ne zaman yapılmaması gerektiği konusundaki anlayışınız değildir; sorun normalde farkedilmeden makul bir uygulama olanı uygularken dogmatizmdir.

Yöneticinizle sohbet etmek için zaman ayırmanızı, konumunuzu ve neden yapmanız istenenin size yardım etmek yerine koda zarar verdiğini düşündüğünüzü açıklamanızı tavsiye ederim. Karşı karşıya gelmekten kaçının, ancak böyle bir tartışma sırasında rasyonel ve sakin kalmaya çalışın. Yönetiminizin programlamanın pragmatik bir faaliyet olduğunu anlaması önemlidir ve en iyi uygulama önerileri yalnızca pragmatik bir şekilde uygulanırsa yararlıdır. En iyi uygulama, bir taşa oyulmamış bir taşa yazılmıştır ve çakıştığında (okunabilir kod yerine kısa kod), daha sonra hangi en iyi uygulamanın uygulanacağı konusundaki kararlarını uygulamak programcının elindedir. Umarım böyle bir girişi takdir eden makul insanlardır.

Ayrıca biraz cesur olmalısınız, çünkü gereksiz veya uygunsuz olduğunu düşündüğünüz LOC'yi azaltmak için baskı altındaysanız, o zaman sessiz bir yaşam uğruna yine de değişiklik yapmanız doğaldır. Buna karşı koymalısın ve bu karara "sahip" olmalısın. Yönetimin makul olduğu bir durumda, kurallarına tam olarak uymak zorunda kalmamalısınız, ancak yapmadığınız tüm durumları haklı gösterebilmelisiniz.

Ne yazık ki, insanlar kararsızlık seviyesine gelince, kararlarını ve size dayatılan kuralları sorgulayan hiyerarşi düzenine daha düşük olan insanlara gelince mantıksız olabilir. Makul olmamayı tercih edebilirler. Bunun için de hazırlıklı olmalısın. LOC en iyi uygulamasının diğer en iyi uygulamalarla doğrudan çatışmaya neden olduğu durumları ve bunun neden ürüne zarar verdiğini gösterebiliyorsanız ve bunu, çok az kişisel bir katılımın olduğu veya hiç olmadığı bir kod üssü bölümlerinde yapabilirseniz (bu işlerine ya da denetledikleri işlere kişisel bir saldırı gibi görünmüyorlar) o zaman bu argümanınızı desteklemeye yardımcı olabilir. Yine, kendinizi sakin ve rasyonel bir şekilde haklı göstermeye ve yaptığınız argümanları "sahiplenebilmeye" hazırlıklı olmalısınız.

Yönetiminizin makul kişiler olması koşuluyla, iddialarınızı desteklemek için kanıt sağlayabildiğiniz takdirde söylediklerinizin haklı olduğunu takdir etmeleri gerekir.

Bence, az sayıda SLOC ile işlevler yapmak için gerçekten çaba göstermelisiniz.

LOC (kod satırı) küçük bir sayıysa, kodu nasıl etkiler ve LOC daha büyük bir sayıysa, kodu nasıl etkiler?

İdeal olarak, bir bakışta 8 satır kodun anlaşılması, 30 satırdan anlaşılması gerektiğinden daha kolay olmalıdır.

Bu, 8 satırda sıkıştırılmış 30 LOC'nin anlaşılmasının daha kolay olacağı anlamına gelmez.

Sizce şeyleri yapmanın doğru yolu budur.

Normalde bir fonksiyonda, onu soyutlama seviyelerine göre gruplandırmaya çalışırım ("IO kodu burada", "burada doğrulama", "burada hesaplama" vb.)

Sonra, boş bir satırla ayırarak bloklara böldüm. Kod on satırdan fazlaysa, her bloğu farklı bir işleve çıkarırım (yine de birden fazla görünen kod için yapıyorum). Performansı bu şekilde bozma konusunda bir argüman duydum (gereksiz fonksiyon çağrıları) ancak pratikte bunun neden olduğu bir performans darboğazım olmadı.

Bununla birlikte, bu çıkarma işleminin yapıldığı fonksiyonlarım oldu ve ondan sonra fonksiyon ~ 40 satır uzunluğundaydı (C kodu). Eğer kod mümkün olduğunca gruplandırılır, ben artık fonksiyonları ile ilgili bir sorun görmüyorum.

Temiz, otomatik olarak belgelenmiş koda odaklanmanın LOC'den daha önemli olduğunu düşünüyorum. Örneğini gerçekten sevmiyorum, çünkü kodun ne yaptığını, nedenini söylemeden açıklıyor. Örneğin, bu:

boolean sweet_sixteen = (yaş == 16);

oldukça gereksiz. "Yaş == 16" yazan herkes bunu bilir. Kodu şöyle yazmayı tercih ederim:

public static boolean companyShouldThrowABigParty(int age) {
    return (age == 16) || (age == 21) || ((age > 21) && (((age % 10) == 0) || ((age % 25) == 0))); 
}

public static void happyBirthday(int age)
{  
    System.out.println(companyShouldThrowABigParty(age) ? "Super special party, this year!" : "One year older. Again.");
}

Partinin ne zaman atılacağına karar verme mantığı System.out'tan ayrı, test edilebilir ve anlaşılması kolaydır. Daha önemlisi, yine de, kodu okuyan biri, bu şekilde yazılmasının nedenini anlayabilir ("şirket bazılarına büyük bir parti vermek istiyor").

Bence daha az kod satırı = daha okunabilir kod

Ancak, elbette, daha az sayıda satır elde etmek için kodunuzu küçültmeye / gizlemeye başladığınızda bazı sınırlamalar vardır.

/** Pad a number with 0 on the left */
function zeroPad(number, digits) {
    var num = number+"";
    while(num.length < digits){
        num='0'+num;
    }
    return num;
}

Bu küçültme mantığı aynı kalır, sadece daha az okunur. Bu insanlar tarafından yapılmamalı, bu küçültme bir makine tarafından okunması için makine tarafından yapılır.

function zP(e,t){var n=e+"";while(n.length<t){n="0"+n}return n}

Bir kod parçasını kaldırabilirseniz ve algoritma hala yapması gerekeni yapıyorsa, tamam devam edin. Sadece kodunuzu küçültmeyin, bunu yapmak için daha iyi araçlar var.

Daha az kod satırı olduğunu sanmıyorum == daha okunabilir kod. Bununla birlikte, teoriden çok farklı olan gerçek, çok sayıda satır içeren kodun genellikle uygun bir tasarım olmadan yazılmasıdır. Sonuç olarak, daha az sayıda satır gerekliliği, bazı programcıların yetenekli olmaları durumunda daha iyi bir tasarım elde etmelerini zorlayabilir. Büküm, birçok programcının olmadığı, gereklilik gereğinin fazla bir faydası olmadığıdır.

Normal şartlarda satır sayısını bir sorun olarak görmezdim, ancak bu sorunlara işaret edebilir. Birisi size 1000 kod satırlı bir sınıf gösteriyorsa, o zaman sınıfın nasıl yapıldığına veya tasarlandığına dair bir şeyler yanlış olmalı.

Örneğiniz, daha fazla sayıda kod satırının anlamlı olduğu bir durumu gösteriyor. Ancak bu örnektir. Her gün satır sayısının planlama eksikliğine bağlı olduğu örnekleri görüyorum

LOC, bir projenin başlangıcında fiili uygulamadan daha faydalı bir ölçüm yöntemi olduğunu düşünüyorum. İşlev noktası başına LOC bilmek, proje çabasını ve bu sürenin ne kadar süreceğini ve optimum geliştirici sayısını tahmin etmenizi sağlar.

Tasarım ve dil seçimini de etkileyebilir: fonksiyon noktalarını azaltmak veya daha düşük bir LOC / FP olan bir dile geçmek, proje çabalarını azaltmalı, diğer her şey eşit olmalıdır.

Kod satırlarının kendileri çok önemli değildir. Bakmanın bir yolu, nesirle karşılaştırmaktır. İlk fark, hem kodun hem de nesrin (doğruluğu varsayarak) önemli bir özelliğin okunabilirlik olmasıdır. Okunabilirlik (ve anlaşılabilirlik), bakım ve doğruluk gibi diğer özelliklerde yardımcı olur.

Az sayıda hatta bir işleve sığabilmenin avantajları vardır. Ancak paragrafsız bir metne sahip olmak okunaklılığını azaltır. Zor kavramlar, zor (nadir) kelimeler ve karmaşık anlatım biçimlerinin kullanılması, genellikle bir fikri ifade etmek için gereken kelimelerin miktarını azaltır, ancak aynı zamanda metnin okuma seviyesini ortaokul seviyesinden profesyonel akademisyenlere (örneğin; nesir durumu).

Genel olarak, kodunuza soyutlamalar eklemek ve yardımcıları vb. Kullanmak faydalı olacaktır, ancak yine de, bu soyutlamalar çok fazla olabilir. Aynı zamanda gerçekleşebilecek olan, karmaşıklığı kodun başka bir bölümüne taşımak. Bazen, bir uzman olarak genç programcılar (veya öğrenciler) tarafından kullanılmak üzere bir çerçeve / kütüphane tasarlarken olduğu gibi, bunu yapmak iyi bir fikirdir. Ancak gençlerin kodunuzun nasıl çalıştığını anlamalarını beklemeyin, sadece yanlış kullanmaları çok zor.

Kod yazarken, özellikle kodunuza boş satırlar eklemekten çekinmeyin. Paragraf olarak işlev görürler ve işlevinizin farklı bölümlerini ayırmanıza yardımcı olurlar (henüz yardımcısına konulmasalar bile).

Her resmi kod değerlendirme yöntemindeki en büyük sorun, bazı kodlarda kesinlikle başarısızlığa uğramasıdır. Bunun nedeni, programlamanın bir tür sanat olması ve bu nedenle değerlendirme için net standartların bulunamamasıdır. Elbette farklı sanat türleri var - resimlerin seri üretimi de var ve belki de bu işte bir tabloya kaç tane boya harcanması önemlidir. :)

Dürüst olmak gerekirse, LOC ölçümü hakkında bir bilgi vermem. Elbette, bir fonksiyonun veya prosedürün mümkün olduğu kadar kısa olması güzel, ancak günün her saatinde okunabilir kod alıyorum.

Her zaman LOC'nin düşürülmesinin istenmesinin, okunması zor bir koda yol açacağına katılıyorum.

Ancak, belki de kodlama stiliniz çok ayrıntılı ve incelemeciniz daha özlü bir yolun daha iyi olduğunu düşünüyor. Örneğin, yalnızca değişken isimlerin seçimi sayesinde oldukça açık bir ifadeyi açıklayan bir yorum kullanışsızdır.

Kod satırlarının ölçtüğü tek bir şey var ve bu sahip olduğunuz kod satırlarının sayısı. Her şey sıcak hava, spekülasyon ve önyargıdır.

Orada bir şey daha kötü değil daha iyi yapabilir az kod satırı olan nasıl diğer cevaplar büyük bir çok örnek vardır, ama tek çekirdekli noktası cevapsız edilmiş görünüyor ve işte: kaç satır gerçekte yapmak gerek bu işi yapmak için ?

Görevin yerine getirilmesi için 10 satırlık bir kod gerekiyorsa, 10 satırda yapmalısınız. Bunu başarmak 10.000 satıra ihtiyaç duyuyorsa, o zaman aynı şekilde, 10.000 satırda yapın. "Birkaç kod satırına" kültü olacak değil sen 1.000 veya 2.000 ya da her neyse bunu yaparsanız daha iyi ikincisi örnek olun. İş 10.000 satıra ihtiyaç duyuyordu ve bu 10.000 satır, daha azını yapsanız kaçırmanız gereken doğrulama katmanları, hata denetimi, güvenlik vb . İçerebilir.

Düzenle

Bu birkaç olumsuzluk kazandığından, burada söylediklerim hakkında daha spesifik olmam gerektiğini düşünüyorum. Yapmanız gereken ilk şey herkesin okunur bu - Artık yazmak üst düzey kod aslında işletilirse makine koduna az veya hiçbir benzerlik taşıyabilir ki sizi götürmek soruyorum noktayı. Bu noktanın alaka düzeyi, altında gerçekte neler olup bittiğini anlamadan yüksek seviye koda odaklanmanın yanlış yönlendirilmiş olmasıdır.

Şimdi aşağıdakileri göz önünde bulundurun:

• Tek bir satırla gerçekten kötü ve yavaş kod yazmak mümkündür - sağladığım bağlantının sonunda üçlü operatör hakkındaki yorumu not edin.

• Bir kod satırı bir API çağrısı yaparsa (veya harici bir kütüphaneye yapılan başka bir çağrı yaparsa), tanım gereği ne yapıldığını veya ne kadar etkili olduğunu doğrudan kontrol etme biçiminiz çok az olur.

• Hata denetimi, temizleme, vs tüm kod ekstra satırları ekleyin ve birkaç kod satırına bile en ateşli fan karşı iddia etmeyeceğini oldukça eminim o .

Yani - kod satırları bozuk bir ölçüdür. Daha az sayıda kod satırı ekstra performans sağlamaz - bu API veya kütüphane çağrısı bir satırdır ve kontrolünüz dışında olabilir. Daha az sayıda kod satırı ekstra sağlamlık garanti etmez - hata kontrolü ve temizleme her zaman fazladan satır gerektirir. Daha az sayıda kod satırı bile fazladan okunabilirlik veya bakım kolaylığı garanti etmez - sadece bunu bilmek için IOCCC'ye bakmanız gerekir .

Peki daha az kod satırı neyi garanti ediyor? Daha az kod satırı, hepsi bu.

Aynı işi 2.000 hatta 10.000'de yapmaya odaklanmak çok yanlış. Bunun yerine, çalışan, sağlam, kabul edilen toleranslar dahilinde çalışan ve ilerlemenin okunması ve bakımı daha kolay olan koda odaklanın. Bazen bu, düşük bir LoC sayımında yapabileceğiniz anlamına gelir , bazen bunu daha yüksek bir LoC sayımında yapmanız gerektiği anlamına gelir, ancak LoC sayımı burada önemli olan olmamalıdır.

Koddaki satır sayısını azaltmak ne kadar önemlidir? Çoğu durumda, hiç de değil. Aslında, çoğu durumda, karmaşık işlemleri daha okunabilir adımlara bölerek kod satırlarının sayısını artırmak ve her adımı yorumlamak ve genel olarak kodu diğer kullanıcılar tarafından daha okunaklı ve genişletilebilir hale getirmek için yorum eklemek daha önemlidir. peşinden gelen geliştiriciler.

Daha önceki dönemde eğer kodun kod satırı sayısının büyük olması durumunda kodun etkili olduğu ve yapması gereken tüm görevleri yerine getirdiği varsayılırdı, ancak bir süre sonra daha az konumun daha az olduğu anlaşılırdı. Kodun yürütülmesinde sistem tarafından yapılan maliyetler çok daha azdır. Sistem lokasyonunun iyileştirilmesi için daha az yapılması gerekiyordu. O zamandan beri lokal gücünün daha az olacağı varsayıldı. Hesaba katılmalıdır.

1. Sorununuzun akış şemasını yapın
2. Yapabildiğiniz kadar az sayıda döngü kullanmaya çalışın
3. İşlev çağrıları fazla olmamalıdır
4. İlgili bilgilerin depolanması için istif veya sıranın kullanılması durumunda TRIE gibi yeni veri yapıları kullanılmalıdır.
5. Ve sorunu çok büyük bir dizide büyük miktarda sayı sakladığınız ve daha sonra dizilim üzerinden erişmeye çalıştığınız, yaratıcı değil, gerçekçi bir yaklaşımla çözmeye çalışın.]
6. Mümkün olduğunca çok sayıda makro kullanın. Ayrıca kullanma yaklaşımı da soruna bağlıdır. Eğer gerçekten karmaşıksa, o zaman bazen basit yaklaşımı kullanmak da karmaşık olana eşdeğerdir.