Acemi programcı (lar), derleyici hataları sözlüğünün eksikliği yüzünden engelleniyor

Ailemin bir arkadaşı, programlamayı öğrenirken benden biraz yardım istedi. (C dilinde). Biz konuşurken, derleyicisinin (GCC) hata yaptığında verdiği hata mesajlarını anlamakta zorlanmanın sıkıntısı olduğunu dile getirdi. Kullanılan tüm terimleri anlamıyor ve bazen anlamalarının ötesinde onların kombinasyonu. Bana "Derleyici belgeleri neden hata mesajlarıyla ilgili daha uzun açıklamalar içermiyor?" Diye soruyordu. - ve onun için iyi bir cevabım yoktu.

Ben kendim - daha deneyimli bir programcı olarak - çok nadiren bu durumdayım, ancak bu nadir olaylar oluyor - daha önce karşılaşmadığım egzotik bir hata mesajı. Bir arama motorunda hata mesajını arayarak uğraşmayı başardım, ancak görünüşe göre bu her zaman işe yaramadı - özellikle karşılaştığı hatalar daha yaygın olduğu ve kendisiyle ilgili sorun yaşadığı birden fazla farklı durumda ortaya çıktığı için kendi.

Peki acemi bir programcı, derleyici hata mesajlarını anlama zorluğuna nasıl yaklaşmalıdır? Spesifik olarak, C ve GCC kombinasyonu ile?

Birkaç faydalı teknik:

• Açın -Wallve -Werror. Daha da fazla hata mesajı oluşturmak için hata mesajlarını deşifre etmekle uğraşırken, bu durumun sezgisel görünmesine neden olabilir , ancak uyarılar genellikle sorunun asıl kaynağını anlamak ve onlara daha yakın olmak ve bunları görmezden gelmek anlaşılması zor hatalara yol açabilir .
• Sadece listedeki ilk hatayı düzeltmeye çalışın. Genellikle hatalar birbirine karışır ve sonraki hata mesajlarının gerçekten gerçek hatalar olmamasına yol açar. Birini düzeltin ve yeniden derleyin. Daha fazla deneyim edindiğinizde birden fazla hata iletisini düzeltmekte daha iyi olursunuz.
• Mümkün olan en yeni derleyici sürümünü kullanın. C son derece kararlı bir dildir. Bu nedenle, yeni derleyicilerdeki gelişmelerin büyük bir kısmı dil özellikleri eklemek değil, daha iyi hata mesajları dahil olmak üzere geliştirici deneyimini geliştirmek. Yaygın olarak kullanılan birçok linux dağıtımı, varsayılan olarak çok eski gcc sürümlerine sahiptir.
• Artımlı olarak programlayın. Derlemeden önce bir ton kod yazmaya çalışmayın. Hala derlenecek en kısa miktarı yazınız. Son derleme işleminden bu yana yalnızca bir satırı değiştirdiyseniz, asıl sorunu içeren çizgiyi bulmak çok daha kolaydır.
• Birim testleri yaz. Derleme hatalarını düzeltirken yeniden yapılanma değişikliklerini açıklığa kavuşturmak için size daha fazla güven veriyor.

Arkadaşınızın bir sözlüğe ihtiyacı yok. Bir sözlük ona yardım etmeyecek. Onun ihtiyacı olan derleyici hataları meydana geldiğinde yapmanız gerekenler hakkında daha iyi sezgi.

C derleyici hataları, C # derleyici hataları kadar sezgisel değildir, çoğu zaman C'nin "metale yakın" doğası ile ilgili olan birçok nedenden ötürü, C'deki derleyici hatalarının çözülmesi bir kalıp eşleştirme alıştırması değildir, çünkü Alma asıl sorunla ilgisi olmayabilir. Bir hata iletisinin tipik olarak kesin bir kod konumuna ve soruna eşleştiği C # veya Java'nın aksine, C'deki hataların çok sayıda ve daha uzakta olması muhtemeldir.

Buna bir örnek "noktalı virgül bekleniyor" veya ayrıştırıcının bir şey üzerine asılı olduğunu gösteren herhangi bir sayıda sözdizimi hatası olabilir (zorunlu olarak noktalı virgül değil). Ya da "beklenmeyen iletme bildirimi" gibi bir hata, bunu gördüğümde, .h dosyalarımın birinde yanlış büyük harfle yanlış yaptığım anlamına gelir, ancak sorunun kaynağı olarak .h dosyasına işaret etmez.

Arkadaşınızın stratejisi, bunu bir dizi hata ve çözümle eşleştirmek için olmamalıdır; Asıl sorunun ne olduğunu anlamak için C dilinin sözdizimini ve teknik özelliklerini iyi anlamak gerekir .

Bahsetmeye değer ilgili bir teknik ikinci bir derleyici kullanıyor. Clang, örneğin daha iyi hata mesajlarına yatırım yaptı, ancak hatayı ifade etmenin alternatif bir yolu aydınlatıcı olabilir.

Bu özellikle en karmaşık hatalar için geçerlidir. Örneğin, iki benzer yapıyı karıştırdığınızda (yeni başlayanlar için olağandışı değil), derleyiciler tipik olarak doğru hata mesajını oluştururken bir sorunla karşılaşır. Bu, derleyici B'yi gerçekten amaçladığınızda B yapısının yanlış kullanımı hakkında bir hata mesajı verdiğinde karışıklığa neden olabilir.

Bir süre önce Wikibook’larda bir GCC hata sözlüğü için bir girişimde bulunmuş , ancak hiçbir zaman tam olarak çalınmamış ve güncellenmemiş gibi görünüyor.

"Hatalar" bölümü, "Uyarılar" bölümünden çok daha ileridedir. Görünüşe göre G ++ 'ya hedeflenmiş, ancak arkadaşınızın orada kullanımına ilişkin bazı bilgiler olması muhtemel.

Yukarıdaki cevaplara ek olarak, çoğu derleyicinin kapsamlı hata sözlüğü olmadığına dikkat edin - bunlar mesajların kendileri sıklıkla değiştikçe sürdürülmesi gereken çok iş olacaktır ve bunlardan birçoğu vardır.

Bir sözlük için en iyi alternatif internete erişimdir. Derleyici anlamadığınız bir hata ürettiğinde, karşılaştığınız ve kafanız karışan ilk kişi olmanızın muhtemel olmadığından emin olun. Kesin mesajın hızlı bir Google'ı, genellikle, kendinize çok benzeyen örnek kodla, okunması kolay formatta bol miktarda bilgi vermek için yeterlidir.

Bunun ötesinde, zamana ve dile ve derleyiciye aşinalık yeter. Bu ve Karl Bielefeldt tarafından verilen iyi tavsiyeler .

C Standardı, "programlama" ve "nesne" gibi bir takım terimleri diğer programlama dillerinden farklı şekillerde kullanır ve derleyici mesajları genellikle bu terimlerle yazılır. Terminolojinin kullanımı Standardın bazı bölümlerinde tutarsız olmakla birlikte, C öğrenmek isteyen herkes C89, C99 ve / veya C11 standartlarının taslaklarına ve ayrıca kendilerine ilişkin mantık belgelerine bakmalıdır. Örneğin "C99 taslak" veya "C89 gerekçesi" aranıyor, ancak beklediğiniz belgeyi aldığınızdan emin olmanız gerekebilir. Her ne kadar çoğu derleyici C99 Standardını desteklese de, bunun C89 Standardından ne kadar farklı olduğunu bilmek faydalı olabilir ve C89 gerekçesi, daha sonraki sürümlerde bulunmayan bazı tarihsel geçmişlere sahip olabilir.

Kimsenin bariz cevap vermemesine şaşırdım ve pratikte en sık kullanılanlardan şüpheleniyorum: sadece hata mesajlarını okumayın.

Çoğu hata mesajının değerinin büyük çoğunluğu basitçe böyle bir hatta bir şeylerin yanlış olduğudur. Çoğu zaman sadece satır numarasına bakarım ve o satıra giderim. Bu noktada hata mesajını "okuduğumda" genellikle sadece gözümün geçerken yakaladığı şey değil, bir yağsız bile değil. Satır üzerinde veya yakınında neyin yanlış olduğu hemen belli değilse, o zaman mesajı okurum. Bu iş akışı, yerinde hataları vurgulayan bir IDE veya aletle daha da iyidir ve Karl Bielefeldt'in sadece küçük değişiklikleri düşünmek için önerisini otomatik olarak yerine getirir.

Kuşkusuz, hata mesajları her zaman uygun satırı göstermez, ancak daha sonra çoğu zaman uygun kök nedenini de göstermezler, bu nedenle hata mesajının tam olarak anlaşılması bile sınırlı bir yardımcı olacaktır. Doğru satırı bulma konusunda hangi hata mesajlarının daha güvenilir olduğu hakkında bir fikir edinmek uzun zaman almaz.

Bir yandan, bir aceminin yapması muhtemel olan hataların çoğunun , derleyiciden yardım gerekmeden deneyimli bir programcı için acı verici bir şekilde anlaşılması muhtemeldir . Diğer taraftan, acemiler için bu kadar açık olma ihtimalleri çok daha düşüktür (çoğu kişi açıkça görülse de, çoğu hata aptalcadır). Bu noktada Robert Harvey ile tamamen aynı fikirdeyim, aceminin diline daha aşina olması gerekiyor. Bundan kaçınmak yok. Bilmediğiniz kavramlara referans veren veya şaşırtıcı görünen derleyici hataları, dilin bilgisini derinleştirmek için bir ipucu olarak görülmelidir. Benzer şekilde, derleyicinin şikayet ettiği durumlar için de ancak kodun neden yanlış olduğunu göremiyorsunuz.

Yine, Robert Harvey ile derleyici hatalarını kullanmak için daha iyi bir stratejinin gerekli olduğu konusunda hemfikirim. Yukarıda bazı yönleri ana hatlarıyla belirttim ve Robert Harvey'in cevabı başka yönler de veriyor. Arkadaşınızın böyle bir "sözlük" ile ne yapmayı umduğu bile net değildir ve böyle bir "sözlük" in aslında arkadaşınız için çok faydası olmaz. Derleyici mesajları kesinlikle ^1. dil kavramlarına giriş için bir yer değildir ve bir “sözlük” bunun için daha iyi bir yer değildir. Hatta hata mesajı ne anlama geldiğini berrak bir bilgi ile, nasıl söyleyeceğim vermeyecek düzeltmek sorunu.

¹ Elm ve Dhall (ve muhtemelen Raket) gibi bir kaç dilde olduğu gibi, bazı "başlangıç ​​seviyesine yönelik" dil uygulamaları da bunu yapmaya çalışır. Bu bağlamda, MSalters'ın farklı bir uygulamayı kullanma tavsiyesi doğrudan ilgilidir. Şahsen böyle şeyleri çekici bulmuyorum ve doğru soruna yönelik değil. Bu, daha iyi hata mesajları yapmanın bir yolu olmadığını söylemek değildir, ancak bana göre derleyicinin inançlarını ve bu inançların temelini daha açık hale getirme eğilimindedir.

Peki acemi bir programcı, derleyici hata mesajlarını anlama zorluğuna nasıl yaklaşmalıdır? Spesifik olarak, C ve GCC kombinasyonu ile?

Arkadaşınıza bir hatayla karşılaştığında aşağıdakileri yapmalarını söyleyin.

• Son başarılı oluşturma işleminden bu yana eklenen kodu kaldırın / yorum yapın.
• Küçük parçalarını geri koyun ve derleyin
• Hata oluşana kadar tekrarlayın

Derleyici hataları, derleyicinin kodunuzla ilgili neyi anlamadığını söyler, yanlış olanı değil. Bu yaklaşım kabaca Googling ve bazı dokümanları veya bir StackOverflow gönderisini okumakla aynı miktarda zaman alır, ancak ne yaptığınızla ilgili daha iyi bir fikir verir.

Ayrıca çok fazla kod eklemeden önce hataların farkına varmak, birkaç dakika süren projeler üzerinde çalışmaya başlayana kadar sık ​​sık derlenmelerini sağlar.

Sonunda, bir kerede bir şey üzerinde çalışmalarını, aralarında derleme yapmadan birden fazla dosyada çalışmalarını, bir kerede birden fazla bağımlılık oluşturmalarını vb. Söyleyin.

Başka bir teknik ise arkadaşın zaman içinde farklı hata mesajları ile karşılaştığı zaman kendi sözlüğünü yazması olacaktır. Genellikle bir şeyi öğrenmenin en iyi yolu, onu öğretmektir. Tabii ki, sözlük yapıldığı zaman, muhtemelen artık ona ihtiyacı kalmayacak.

GCC ile ilgili kişisel deneyimim, her hata mesajının "olağan" bir hatalar dizisiyle ilgili olduğudur. Örneğin, GCC "&’ yi unuttun mu "dediğinde, genellikle parantezleri unuttuğum anlamına gelir. Elbette, hangi hataların hangi hata mesajlarının programlayıcıya bağlı olacağı, arkadaşın kendi sözlüğünü yazması için iyi bir sebep olacaktır.