Negatif kod nedir?


Yanıtlar:


501

Fazlalıkları kaldırarak veya daha özlü yapılar kullanarak kod satırlarını azaltmak anlamına gelir.

Örneğin , orijinal Apple Lisa geliştirici ekibindeki bu ünlü fıkralara bakınız :

Lisa ekibi 1982'de yazılımlarını sonlandırmaya zorlandığında, proje yöneticileri programcıların yazdıkları kod satırı hakkında haftalık raporlar göndermelerini talep etmeye başladı. Bill Atkinson bunun aptalca olduğunu düşündü. QuickDraw'ın bölge hesaplama rutinlerini altı kat daha hızlı ve 2000 satır daha kısa olacak şekilde yeniden yazdığı hafta için forma "-2000" koydu. Birkaç hafta sonra yöneticiler formu doldurmasını istemekten vazgeçti ve memnuniyetle yerine getirdi.


257
Eklenecek başka bir şey olmadığında değil,
alınacak bir

7
#LOC iyi bir kod kalitesi ölçüsü mü? Herhangi bir C veya C ++ kodunu 'küçültebilirim' ve satır sayımını önemli ölçüde azaltabilirim ama sürdürmesi kabus olurdu.
JBRWilkinson

8
@systempuntout - ve sonra Einstein'ın "(Bilimsel bir teori) mümkün olduğu kadar basit olması gerekirdi, ama daha basit olmamalı" vardı
Jonathan Day

32
Hiçbir şey, orada olmayan koddan daha hızlı veya daha güvenilir olamaz ya da daha az bakım gerektirmez. "Şüphe duyduğunda, kes şunu!"
TMN

4
@JBRWilkinson: Kodun kısalıklığı ile ilgili "tatlı bir nokta" olduğunu söyleyebilirim. Genel olarak, daha kısa olan daha iyidir, ancak kodun çok titizce büyüyebildiği ve başka bir programlayıcıya deşifre etmenin kolay olmadığı bir nokta vardır.
GordonM

131

Programcı verimliliğini ölçmek için kod satırlarına göre bir Bill Gates teklifi var.

LOC metrikinin aşırı uzun sargılı dillerin kullanılmasını teşvik ettiğini ve kotayı karşılamak için tekerleği yeniden icat etmeyi kastettiğini eklemek isterim.


30
Evet, bu her türlü metriğin sorunu. İnsanların performansını değerlendirmek için onları kullanır kullanmaz, sayıları oynamaya başlayacaklar.

5
Aslında hiç kimse LOC'yi performans ölçütü olarak kullandı mı? Sadece "burada bir projenin böceği hakkında ne diyoruz?" Gibi şeyler için kullanıldığını gördüm.
Michael Borgwardt

5
@Michael: evet. Ne yazık ki evet.
Michael Petrotta

4
Aynı metaforun 10000 GTON jet ürettiği bir şirketi olan aynı Bill G. hakkında mı konuşuyoruz? :)
Daniel Mošmondor 27.09.2011

37
Space Shuttle'ın onboard bilgisayarlarına kod yazan bir programcı bana yazılımın ağırlığını hesaba katması gerektiğini söyledi! Yazılım gerçekti (parası ödendi); mekik üzerindeydi; Mekiğe yüklenen her şeyin ağırlığı dikkate alınmalıdır. Programcı verimliliğini ölçmenin ilk örneği kod ağırlığına göre. (Sıfır'a izin verilmedi, bu yüzden 0.00001 gram belirtti ve hepsi tatmin
ediciydi

118

Lisedeyken - ve evet, 70'lerde bilgisayar kullanıyorduk, ama taş bıçak kullanarak onları hayvan derilerinden çıkarmak zorunda kaldık - matematik öğretmenlerinden biri bir programlama yarışması düzenledi. Kurallar, kazanan programın doğru çıktıyı üreten program olacağını ve zamanın en az kod satırına sahip olduğunu gösteriyordu. Yani, eğer programınız 100 satır kod aldıysa ve 5 saniye koştuysa, puanınız 500'dü. Eğer bir başkası 90 satır kod yazıp 6 saniye koştuysa, skoru 540'dı. Düşük puan, golf gibi kazanır.

Hem özlülük hem de performansı ödüllendiren parlak bir puanlama sistemi olarak beni etkiledi.

Ancak teknik olarak kazanan kriterleri karşılayan giriş diskalifiye edildi. Sorun, 100'den küçük tüm asal sayıların bir listesini yazdırmaktı. Diskalifiye edilen giriş, bunun gibi bir şeydi (öğrencilerin çoğu o zaman BASIC kullanıyordu):

100 print "2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 53, 59, 61,"
110 print "67, 71, 73, 79, 83, 87, 89, 91, 97"

Bu girişi yazan öğrenci, sadece kısa ve çok etkili olduğunu değil, aynı zamanda algoritmayı, programın oldukça sürdürülebilir hale getirecek şekilde en az programlama bilgisine sahip olan herkes için açık olması gerektiğini belirtti.


10
Kod satırlarını saymanın çok iyi oynanabilir bir ölçü olduğunun kanıtı :-)

44
Bu BASIC programı mükemmel! Öğretmenin programı diskalifiye etmesi oldukça üzücü. Sonuçta, arama tabloları (programın biraz benzer olduğu) kesinlikle gerçek dünya programlamasında bulunabilir.
Noctis Skytower

6
Bilge bir öğretmen bu BASIC programını kabul etmiş ve SRS hakkını almanın önemini vurgulamak için kullanmıştır. Bana nasıl oynanacağını göstermek için ekibi ile çok sinirli olan bir beyzbol koçunu hatırlatıyor, yarasayı aldı, arka arkaya üç vuruş yaptı ve aşılmaması için, ekibine bağırdı "Gördün mü! ***** oynuyorlar. Şimdi sopayı al ve düzgün oyna! " Ayrıca bana “yaratılışın yaratıcısı görüp kızardığını” yazan ve “şarap” üzerine deneme yarışmasını kazanan kişiyi hatırlatıyor.
Nav

3
@Nav: Bana aynı şekilde başlayan benzer bir hikayeyi hatırlatıyor. Sonra antrenör havaya fırlatır, sallanır ve ıskalar. Yine havaya atar, sallanır ve ıskalar. Üçüncü kez havaya fırlatır, sallanır ve ıskalar. Sonra takıma şöyle dedi: "Bakın, bu nasıl olmalı!" (Bu hikayenin yazılım geliştirme ile ne yapabileceği hakkında hiçbir fikrim yok.)
Jay

13
Bunun için diskalifiye olsaydım çok üzülürdüm. Deterministik bir problem deterministik bir çözümü hak ediyor, değil mi? 'Merhaba Dünya' uygulaması yazarken, doğru şekilde 'Merhaba' yazım olup olmadığını kontrol etmek için kod yazmıyorum.
Kirk Broadhurst

34

Yanak dili. Ortalama kodlanmış satır başına N $ tutarsa, "negatif satırları" kodlamak kesinlikle kazanır.

Bu, pratik öneri olarak, işi yapan küçük kodun, aynı şeyi yapan diğer tüm kodların eşit olması nedeniyle çok daha iyi olduğu anlamına gelir.


2
Nereden geldiğini anlıyorum ama kısa, anlaşılması kolay küçük alan kodu tek seferde nadiren elde edilir. Genellikle çalışır, böylece çalışır (birçok satır), hız için optimize eder (biraz daha az satır) ve bakım / okunabilirlik için optimize eder (daha az satır hala). Uzun yatırım getirisi ile gerçek maliyet, ikinci ve üçüncü adımdır, bu yüzden genellikle tamamen atlanırlar. Sanki "ucuz, hızlı ve iyi - iki tane seçme şansınız var" gibi.

2
Aslında, bakım / okunabilirlik için en iyi duruma getirme IME aslında LOC'yi artırabilir , çünkü yeniden yazma kodu daha fazla kendini belgelemek için kod daha ayrıntılı hale getirme eğilimindedir.

1
@Visage: "... diğer tüm şeyler eşit".
Ira Baxter

Mesele şu ki, sanırım, diğer her şey özlü kod ve ayrıntılı kod arasında eşit olamaz.
Tomas Narros

Ortalama kod satırının N $ tutarının nedeni, önce zamanınızı Xsatır yazarak geçirmenizdir . Ardından, birkaç yinelemeden sonra, nihai ürünü Yçizgiler halinde azaltır . Bu nedenle, (X-Y)geri kalan hatlar oldukça maliyetli görünüyor çünkü yeniden yapılanma katliamı tüm boşluğu kesti.

27

Aynı programı daha az kodla yazmak herkes için bir amaçtır.

Bir program kod için 200 LOC aldıysa ve 150'de yazsam, -50 LOC yazdım. Bu yüzden negatif kod yazdım.


3
Ayrıca, daha az LOC yazmak, daha az hata yapabileceğiniz ve kolayca
fark

3
Haskell ve rastgele gürültüye sıkıştırılabilecek diğer diller için doğru değil. :)
Macke

1
Tabii ki, benim açımdan "sıkıştırma kodu" değildi, ama daha az LOC içinde inceleyen verimli algoritmalar yazıyorsunuz.
LucaB

9

Thilo'nun cevabı muhtemelen tarihsel olarak en doğrudur, ancak "negatif kod" metaforu performans ve bellek kullanımını da içerebilir - aslında ihtiyaç duyulana kadar bir şeyin yürütülmesini veya tahsis edilmesini erteleme çabalarını ödüllendirir.

Bu “erteleme”, “hiçbir şey yapmamak her zaman bir şey yapmaktan daha hızlıdır”, “En hızlı kod hiçbir zaman yürütmeyen koddur” ve “Yeterince uzun süre koyabiliyorsanız, bunu asla yapmak zorunda kalmayabilirsiniz "(gerçekten gerekli olana kadar pahalı işlemlerin ertelenmesi anlamına gelir)

Olumsuz kodu gerçekleştirmenin bir tekniği, ilk varsayımlara ve sorunun tanımlarına meydan okumaktır. Sorun / girdi alanını "yapışkan konu # 3" kategorik olarak imkansız olacak şekilde yeniden tanımlayabiliyorsanız, yapışkan sayı # 3 ile ilgili zaman veya kod harcamak zorunda kalmazsınız. Tasarımı optimize ederek kodu sildiniz.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.