Kaynak koddaki yazım hatalarının ciddi bir sorun olup olmadığını nasıl öğrenebilirim? [kapalı]

Çok kısa ama temsili bir örnek üreteceğim kod tabanımızda her gün gördüğüm çok rahatsız edici miktarda yazım hatası buluyorum:

ArgumnetCount
Timeount
Gor message from queue 

Ne yazık ki bu hiçbir şekilde bir kişi ile sınırlı değildir. Ekibimizde buna katkıda bulunan çok sayıda anadili İngilizce olmayan bir grup var, ancak aynı zamanda Amerikalı, doğmuş ve büyümüş Yazılım Mimarımıza en kötü yazım hatalarından bazılarını tespit edebilirim.

Bunlar ayrıca, bir yazılım geliştirme şirketinde sahip olduğumuz herhangi bir yazılı bilgi e-postalarında, sunumlarda, belgelerde bile bulunur.

Bunun ciddi bir sorun olup olmadığını nasıl öğreneceğimi bilmek isterim?

_{Bu yazım hatalarını her zaman endişe ile karşıladım, ancak kendi, kişisel, resmi politikam, işleri doğru bir şekilde hecelemememiz, işleri halletmemiz için para almamız, bu yüzden şirket içinde hiç kimseyi gerçekten eleştirmedim. Ama bazı yakın arkadaşlarımla bu konuyu gündeme getirdim ve hiçbir zaman iyilik için çözmedim.}

Yazım hataları iki şeyden biri anlamına gelebilir:

• Onları yapan kişi İngilizce yeterli değildir ve uygun araçları (sözlükler, yazım denetleyicileri, vb.) Kullanarak telafi etmek için zaman ayırmaz.
• Onları yapan kişi İngilizce bilmektedir, fakat hecelemeyi hiç umursamamaktadır.

Her ikisi de oldukça kötü bir işarettir, çünkü söz konusu kişinin öncelik listesinde okunabilirlik, sürdürülebilirlik ve şıklığa sahip olmadığı anlamına gelir; Sebep İngilizce dil yeterliliğinin eksikliği ise, aynı zamanda kişinin iki temel beceriden yoksun olduğu anlamına gelir - yazılı İngilizce iletişim ve diller için genel bir his (düşüncelerinizi İngilizce olarak net bir şekilde ifade edemezseniz, t Bunları bir programlama dilinde iyi ifade etme).

Fakat yazım hataları neden kötüdür, diğer her şey eşittir? Sonuçta, kod çalışır ve derleyici, sözdizimi kurallarını ihlal etmedikleri sürece tanımlayıcılarınızı nasıl adlandırdığınızla ilgilenmez. Bunun nedeni, sadece bilgisayarlar için değil, aynı zamanda ve en önemlisi insanlar için kod yazmamızdır. Eğer durum böyle olmasaydı, yine de meclis kullanıyorduk. Kaynak kodu bir kez yazılır, ancak kullanım ömrü boyunca yüzlerce kez okunur. Yazım hataları, kaynak kodunun okunmasını ve anlaşılmasını zorlaştırır - hafif hatalar, okuyucunun saniyenin bir kısmında tökezlemesine neden olur, çoğu önemli gecikmelere neden olabilir; gerçekten kötü hatalar kaynak kodunu tamamen okunamaz hale getirebilir. Başka bir sorun var, yazdığınız kodun çoğuna başka bir kod tarafından atıfta bulunuluyor ve bu kod daha sık başkası tarafından yazılıyor. Tanımlayıcılarınızı yanlış yazarsanız, başka birinin yalnızca adın ne olduğunu değil, tam olarak nasıl yanlış yazıldığını da hatırlaması (veya araması) gerekir. Bu zaman alır ve programlama akışını keser; ve çoğu koda bakımda birden fazla kez dokunulduğu için, her yazım hatası çok fazla kesintiye neden olur.

Geliştirici süresinin maaşa nasıl eşit olduğunu düşünün, bunun bir örneğini yapmak için yeterince kolay olması gerektiğini düşünüyorum; sonuçta, akışı kırıp tekrar içine girmek 15 dakika kadar sürebilir. Bu şekilde, ciddi bir yazım hatası daha fazla geliştirme ve bakımda kolayca birkaç yüz dolara mal olabilir (ancak dolaylı maliyetlerdir, tahminlerde ve değerlendirmelerde doğrudan görünmezler, bu nedenle genellikle yönetim tarafından göz ardı edilirler).

Aslında "Timeount" un ana dili konuşmacı olmama meselesi olup olmadığından şüphe ediyorum. İnsanlar ilk dillerinde tonlarca yazım hatası yaparlar. Bu özel örnekleri "Engrish" olarak nitelendirmem.

Bunu söyledikten sonra, bunun bu belirli örneklerle ilgili olmadığını anlıyorum. İlke olarak sana katılıyorum. Ben bu tür şeyler ("ekleri adında bir sütun yoksa, ekleri oluşturmak") neden olduğu gerçek sorunlara rastladım.

Bir programcı olmak, çoğu zaman insan dili agnostik olan yazım hataları, virgül, noktalı virgül, nokta ile kesin ve dikkatli olmakla ilgilidir.

TimeoutDeğişkeni aramak için ilk kez yazdığınızı öğrenmek için zaman harcadığınızda Timeount, yazımın önemli olmasının başka bir nedenini bilirsiniz.

Bu sorun sizi rahatsız ediyorsa, çoğu IDE yorumlarda yazım denetimine izin veriyor, böylece disleksikler en azından nasıl yazıldığını biliyor gibi görünebilir. Kesinlikle bana yardımcı oluyor! Bu nedenle iyi bir yazım denetimi yapmak önemsiz bir "düzeltme" dir.

Genel sınıf adları ve yöntemlerindeki yazım hataları yalnızca profesyonelce değildir. Zaman ve paraya mal olurlar. IDE'nin bir sınıf ve yöntem adları menüsü üretebileceği Java gibi statik olarak yazılan dillerde acı vericidirler. Dinamik olarak yazılan dillerde tahammül edilemez.

Daha da kötüsü, veritabanı tablosu adlarında ve sütun adlarında yazım hatalarıdır.

Deneyimlerime göre, doğru yazım kodlayıcının İngilizce yeterliliği ile biraz ilgilidir. Anadili İngilizce olanların esasen rasgele yazım ve sözcük sonları içeren kod ürettiğini gördüm ve doğru yazımları yapmaya özen gösteren anadili İngilizce olmayan konuşmacılar gördüm. Ancak doğru yazım, genel kod kalitesiyle büyük ölçüde ilişkilidir. Yetenekli programcılar, İngilizce yeterlilikleri ne olursa olsun, çalışmalarının kalitesini önemsiyor ve isimlendirmeye dikkat ediyorlar.

Kaynak kodunda, dahili sunumlarda ve belgelerde, anlamını değiştirmeyen ya da anlamayı engelleyen küçük yazım hataları bir sorun değildir. Tahriş edici bulursanız onları kaynağa sabitleyin.

Ayrıca, özellikle yorumlarda, madde formdan daha önemlidir. Burada İngilizce yok:

Dize s = "Wikipedia"; / * S değişkenine "Wikipedia" değerini atar. * /

Gerçek şu ki, bazı insanlar doğal olarak diğerlerinden daha dikkatli yazarlar (bu eğitimden mi yoksa tutumdan mı, yoksa istihbarattan mı yoksa her şeyden mi kaynaklanıyorsa). Bunu düzeltmek için ne kadar çaba harcayacağınız bir iş değeri sorusudur: Yazım hatalarını düzeltmekten, onları düzeltmek için harcadığınızdan daha fazla değer elde ediyor musunuz? İç meselelerde cevap genellikle hayırdır. Müşterileriniz kaynak kodu yorumlarınızdaki yazım hataları hakkında şikayette bulunmayacaklardır (açık kaynak yapmadığınız sürece).

Kasıtlı yanlış yazma ve uygunsuz yorumlar profesyonel değildir ve kaçınılmalıdır, ancak odak noktası önemli olan şeylerde olmalıdır (yani, iş için çalışıyorsanız, iş değeri üretin).

Herkesin görebileceği şeyler elbette dikkatle okunmalıdır.

Buradaki problem, İngilizcenin kendisi değil, yorum netliğinin olmamasıdır. Mükemmel ingilizce gerekli değil, net ingilizce. Bu bariz hataları almak için google üzerinden bir şey çalıştırmak için önemsiz.

Örneğin, Gor message from queue"kuyruktan bir mesaj aldı" veya "kuyruktan GOR mesajı" anlamına gelirse ilk bakışta net değildir . Yorumun anlamını anlamak için kodu okumanız gerekir (böylece yorumun nesnesini yenmek).

Kod incelemelerini şirketinize uygulamayı istemelisiniz. Daha sonra insanları sizin için aynısını yaparken yapıcı bir şekilde "eleştirebilirsiniz".

Aynı yazım kullandığınız sürece, örneğin bir değişkene başvururken, derleyicinin yazım hatalarını umursamadığı açık olmalıdır. Daha sonra soru, yazım hatalarının ekip üyelerinin kodu sürdürme yeteneği üzerinde olumsuz bir etkisi olup olmadığı olur.

Bunu yapabilmemin tek yolu, bakım yapan insanlarla konuşmak olacaktır ve kimsenin yazım hatalarını içeren kodu takip ederek daha zor zamanlar geçirip geçirmediğini sorarak başlayabilirsiniz.

Öznellik bu sorundan tamamen kaldırmak için herhangi bir yolu olduğunu sanmıyorum, ama azaltmak için, (manuel veya bir komut dosyası aracılığıyla) belirli bir kod modülü için yanlış yazımların tahmini sayısını almak için kaynağı tarayabilir ve bakım olup olmadığını görmek için daha fazla sayıda yazım hatası olan modüllerde ortalama olarak daha az yazım hatası olan modüllerden daha fazla zaman aldı.

Tüm modüller elbette eşit değildir, bu nedenle sonuçlarınızı modülün siklomatik karmaşıklığı gibi çeşitli metriklerle ağırlıklandırmayı düşünebilirsiniz.

Deneyimlerime göre, bu tür temel yazım hataları rahatsız edici ve daha derin sorunların belirtileri olabilir. Ben böyle "önemsiz" hataları ile ilgili çalıştık her proje nasılsa sadece olan gelişimi sırasında çıkabilirler inceleme sürecinin geçmeyi başardı o tasarımda gerçek sorunları vardı değil öğrenmek istediğinizde kritik işlevselliği gerçekten ihtiyaç orada değil.

Sistem teknik özelliklerini (varsa) tekrar kontrol eder ve genel tasarımı incelerim; Bazı delikler bulursanız şaşırmam.

Bu aslında iki ayrı fakat ilgili meseledir. Yanlış yazımların nerede olduğuna bağlıdır:

1) Kaynak kodunda. Gibi bir tanımlayıcı varsa ArgumnetCount, birisi geldiğinde ve doğru yazım kullandığında gerçek sorunlar yaratabilir . Bu yüzden bu hataları mümkün olduğunca düzeltmelisiniz. Geriye dönük API uyumluluğunu korumanız gerekiyorsa, aşağıdakileri yapabilirsiniz:

/**
 * @deprecated - use setArgumentCount()
 */
public void setArgumnetCount(int c) {
    setArgumentCount(c);
}

2) İnsan tarafından okunabilir metinde (e-postalar, belgeler, kod yorumları). Bunları doğru yazmak önemlidir, ancak kafanızın içindeki ayrıştırma yazılımı çok daha bağışlayıcı olduğundan daha düşük bir öncelik olduğunu söyleyebilirim. Birkaç hata içeren bir metin görürseniz, bu hala okunabilir, o zaman endişelenmeyin - bu sizin probleminiz değil. Ama eğer birisi size özgür çağrışımlı bir saçmalık gönderir ve bu saçmalığı çok kullanıcılı bir web uygulaması için bir plan olarak kullanmanızı beklerse, yazara açıklama isteyen bir nazik not göndermelisiniz (şunun gibi: bu boku anlamamı mı bekliyorsun? ")

Doğru yazım ingilizce kod şarttır. Ayrıca içinde anlamsız dolu büyük bir kod temeli var ve bu korumak için bir kabus.

Bunun kontrolden çıkmasına izin verme. Herkesi kod sahiplerinin zihin okuyucusu olmadığı konusunda eğitmeye çalışın.

Bu çok yönlü bir kültürel problem.

Almanca bir bakış açısıyla konuşmak gerekirse, kendi dilimizin ingilizce terimlerden nasıl daha fazla etkilendiğini fark ediyoruz. Bu, ulusal sloganlara sahip olan veya İngiliz sloganları olan şirketler kadar ileri gider. Bazı insanlar, özellikle yönetim pozisyonlarında, bu arada görünüşe göre söyleyememekle birlikte, düz Almanca bir cümle. Konuşmaları vızıltı kelimeler ve anlaşılmaz yönetim argo ile doludur. Bu tür insanların "denglish" dediklerini söylüyoruz.

Bu durumun ve İngilizce'nin özellikle yazılım işinde "lingua franca" olduğu düşünüldüğünde, İngilizce'nin kendisinin çok sayıda ana dili olmayan konuşmacılardan etkilenmesi kaçınılmazdır. Ancak İngilizce anadili İngilizce olanlar için bu, SW endüstrisinde yer almak için Çinlileri aramaktan daha iyidir.

Renk mi renk mi? İngilizce kimin versiyonu yapmak size doğru olduğunu düşünüyorum? Birinin doğru yazımı, başka bir adamın kazanılabilir bir savaşa başlaması için bahanedir.

Bir savaşa başlamak istiyorsanız, savaşlarınızı dikkatlice seçin ve kazanın. Sizin durumunuzda, yorumlar hakkında endişelenmeyin, dahili öğeler hakkında daha az endişe etmeyin ve (neredeyse) yalnızca API'lara odaklanın

Ben bir maxim var: Düzenli kod mutlaka derli toplu bir zihin anlamına gelmez, ancak ön yüzde kesinlikle doğrudur: düzensiz kod, düzensiz zihin.

Değişkenleri doğru bir şekilde adlandırmak ve yorumları doğru şekilde hecelemek için zaman ayırmayan bir programcı, kesinlikle başka bir şeyi doğru bir şekilde yapmak için zaman ayırmıyor. Programcının anadili İngilizce olan bir konuşmacı olup olmadığı gerçek bir sorun değildir, çünkü İngilizcesi ile ilgili sorunlar akran değerlendirmesi sırasında ele alınabilir (ve yapılmalıdır).

Evet, ürün, ekip ve bireyler için ciddi bir konudur.

• Ürün için: düzeltme, yalnızca müşteriler tarafından yakalanan kusurları ortaya çıkarabilir
• Ekip için: ekip değer yaratmak yerine özensiz kodlamayı düzeltmek için zaman harcıyor
• Bireyler için: Kötü yazım aptalca görünmenizi sağlar ve meslektaşlarınız arasındaki profesyonel duruşunuzu azaltır.