Kötü javascript uygulamalarına güle güle deyin

Nov 29 2022

Harika programlama dünyasına ilk adımlarımızı attığımız zaman, bunun milyonlarca insan için neler yaptığını kendi gözlerimizle görmüş oluyoruz. Programlama sayesinde bu kadar çok kişinin hayatı, sadece cihazlarındaki birkaç tuşa basarak kolaylaştırılmıştır (Bu sihirdir).

Programlama başka tür bir süper güçtür, ancak Ben Amca'nın yeğeni Peter Parker'a dediği gibi, "Büyük güç, büyük sorumluluk getirir." Programlama dünyasında en büyük sorumluluğumuz, yazdığımız kodun hem kolayca test edilebilir hem de zaman içinde bakım yapılabilir durumda kalmasını sağlamaktır.

Programlamada, yazdığımız kod ve sonuç olarak oluşturduğumuz ürün üzerinde sürekli olarak olumsuz bir etkiye sahip olabilecek bazı küçük uygulamalar vardır. Bu sorunları birinci elden yaşadım. Ne olduklarını ve ne pahasına olursa olsun onlardan neden kaçınmanız gerektiğini paylaşmak önemlidir.

1. let ve const yerine var kullanmak

Var kullanmaya elveda deme zamanı.

Yalnızca şu nedenlerle let ve const kullanmalısınız:

● Kapsam daha nettir (parantezler arasında).

● Global nesneler oluşturmaz.

● Yeniden bildirirseniz hataları işaretler.

Sevgili IE11 gibi daha eski bir tarayıcı kullanmıyorsanız, var'ı bırakmak sizin yararınızadır. Let ve const ileriye dönük en iyi arkadaşlarınız olacak.

2. Kodu açıklamak için yorumları kullanmak

Yorumlar yazılım oluştururken temel bir parçadır, okuduğumuz kodu biraz daha iyi anlamamıza yardımcı olurlar ancak kodumuzun ne yaptığını adım adım açıklama hatasına da düşmemeliyiz, kolay anlaşılır kodlar oluşturmalıyız. okuma ve yorumlar yalnızca bağlam sağlamalıdır.

İşte bir profesyonel gibi kod yorumları yazmanıza yardımcı olacak birkaç ipucu ve hatırlatıcı:

● Yorumlarınızda fazlalıktan kaçının; ne yaptığınızı yazmayın, neden yaptığınızı yazın.

● Açıklayıcı değişken/işlev/sınıf adları, tanımlayıcı yorumlardan daha iyidir.

● Mümkün olduğunca özetleyin; Kesinlikle gerekli olmadıkça paragraf yazmayın.

● Her zaman aynı dil ve yorum tarzını kullanmaya çalışın.

● Zamanla, yorumlar genellikle korunmaz (değiştirilir) kodudur.

3. === yerine == kullanılması

Anlaşılması gereken ilk şey, görsel olarak çok benzer olmalarına rağmen farklı şeyler yaptıklarıdır: ilkine düzenli eşitlik operatörü (==) ve ikincisine katı eşitlik operatörü (===) denir.

Düzenli eşitlik operatörü (==) yalnızca işlenenlerin benzer olup olmadığını kontrol eder, bu da bazı hoş olmayan sürprizlere neden olabilir.

Kesin eşitlik operatörü (===) her zaman işlenenlerin farklı tip ve değerlerde olup olmadığını ve tam olarak aynı olduklarını kontrol eder.

4. İsteğe bağlı zincirleme kullanmayı unutmak

İsteğe bağlı zincirleme operatörü (?), zincirdeki her bir referansı kontrol etmek zorunda kalmadan bağlı nesneler zincirinin derinliklerinde bulunan bir özelliğin değerini okumanıza olanak tanır.

Bu, var olmayan bir mülke erişmeye çalışırken hatalardan kaçınmamıza yardımcı olur. Örnek olarak, o Pokémon'un bilgilerini içeren bir Pokémon nesnemiz olduğunu varsayalım.

Bu örnekte olduğu gibi tanımlanmamış bir özelliğe erişmek istediğimizde, 'saldırı' özelliğine erişmek Javascript bir hata üretecek ve uygulamamız bozulacaktır. İsteğe bağlı zincirleme (?) kullanıldığında, Javascript bize özelliğin tanımsız olduğunu söyleyecektir ancak herhangi bir hata üretmeyecektir. Bazen kontrolümüz dışında olan bu tür hataları düşünmek uzun vadede büyük fark yaratır.

5. Sihirli diziler ve sihirli sayılar kullanmamak

Sihirli bir sayı veya sihirli diziler, genellikle açık bir bağlamı olmayan ancak bir amacı olan doğrudan kodda kullanılan sayılar veya dizilerdir. Aksi takdirde anlaşılması ve hata ayıklaması zorlaşabileceğinden, bu değerleri sabitlere atamak en iyisidir.

6. API çağrı hatalarını yanlış işleme

Hataları her zaman async/await dosyamızda bir try/catch ile ele almalıyız.

Verdiğimiz sözlerdeki hataları işlemezsek uygulamamızın patlama ihtimali çok yüksek ve inanın böyle olmasını istemeyiz.

7. Bir nesneyi tek bir parametre olarak kullanma

Bir nesneden birden çok değerin beklendiği bir işlevi bildirirken, tek nesne girdileri yerine birden çok girdi parametresi kullanmak en iyisidir. Bu bize birkaç konuda yardımcı olur:

İlk olarak, fonksiyonumuzun hangi parametrelere ihtiyacı olduğunu en baştan bilerek kodumuzu okumayı kolaylaştırır.

İkincisi, işlevin test edilmesini kolaylaştırır ve bu iki şey birlikte ürünümüzün zaman içinde bakımının yapılabilir olmasına yardımcı olur. Ayrıca artı olarak çöp toplamayı veya gereksiz nesne parametreleri oluşturmayı engellediği için uygulamamızın performansını artırır.

Diğer bir artısı da, TypeScript kullanıyorsanız ve birden fazla parametreniz varsa, tip kontrolünden ve hatalardan kaçınmamızı sağlayan otomatik önerilerden yararlanmak için parametrelerin arayüzünü tanımlamanın daha kolay olmasıdır.

8. Kısaltmaların gücünü unutmak

Hepimiz bir değişkenin var olup olmadığını veya boş veya tanımsız dışında bir tür değer içerip içermediğini merak etme durumundayız. Bu nedenle, genellikle bu türden çok uzun doğrulamalar yaparız:

Kısaltmalar bu sorunu önlememize yardımcı olur. Daha basit ve zarif bir şekilde, yukarıdaki kod sadece aşağıdakine indirgenebilir:

Çözüm

Temiz kod yazmak her zaman bizim sorumluluğumuz olacaktır. Bir geliştirici olarak edindiğim deneyime göre, bakımı yapılabilir ve okunması kolay bir koda sahip olmanın size ve ekibinize saatler kazandıracağını öğrendim.

Kod yazmaktan çok okumaya zaman harcadığımızı unutmayın. Umarım bu küçük ipuçları, büyülü ve şaşırtıcı ürünler yaratma görevinizi kolaylaştırır.