JavaScript ile programlama yaparken, özellikle ekip ortamında çalışırken uygulamanız gereken belirli kurallar vardır. Aslında, uyulması gereken standartları tartışmak için toplantılar yapılır ve bu yaygındır. Bunun nedeni, belirli standartlar izlendiğinde kodun çok daha okunabilir olmasıdır. Kaçınılması gereken bazı şeyleri açıklayan en kötü JavaScript uygulamalarından bazılarını başka bir makalelerde zaten görmüş oluyoruz. Ancak iyi uygulamalardan bahsettiğimizde sadece daha iyi performansa sahip olanları değil, aynı zamanda programlama şeklinizi de kastediyoruz. Kodun sözdizimsel olarak doğru olduğundan emin olmanın yanı sıra, stiller hakkında da endişelenmelisiniz; yani, açma ve kapama parantezlerini nereye yerleştirdiğiniz veya kodda girinti veya girinti olarak kullandığınız boşluklar ve benzeri gibi şeyler.
Programlama Stilleri Nelerdir?
Programlama stilleri, bir projede izleyeceğiniz stiller ve standartlar hakkında ekibinizle ve kendinizle yaptığınız bir anlaşmadan başka bir şey değildir. Bir stili takip etmenin amacı, anlaşılması ve bakımı kolay bir kodla tutarlı bir sonuç elde etmektir. Kişisel bir proje üzerinde tek başınıza çalışıyor olsanız bile belirli standartları izlemeniz gerekir . Nedeni ise ilk sürümü sırasında görmeyebilirsiniz, ancak kodu birkaç ay içinde değiştirmek istediğinizde veya başka bir programcı proje üzerinde çalışmaya başladığında anlayacaksınız.
Stillerin Önemi
Programlama, yaratıcılık, azim ve uzmanlık gibi faktörlerin devreye girdiği zanaatkarlığa benzemektedir. Örneğin, bir duvarı boyayabilir ve etrafınızdaki her şey mükemmel temiz olacak şekilde pürüzsüz bırakabilirsiniz ya da düzensizlikler veya el işaretleri ile duvarı boyayabilir, zemini boya ile doldurabilir ve her şeyi bırakabilirsiniz. Aynı şey programlamada da olur, daha da önemli hale gelir, çünkü birçok programcı aynı kodu tekrar tekrar değiştirdiğinde, her biri kendi kurallarını uygularsa, sonuç daha çok ikinci duruma benzeyebilir.
Yöntem, işlev ve değişken gösterimi
Fonksiyonların ve değişkenlerin adlarını tanımlarken izleyebileceğiniz farklı notasyon türleri vardır. En ünlü olanları şunlardır:
Camel Case : Bu stil, tanımladığınız isimlerin kelimelerini birleştirir, her kelimenin ilk harfini ilk kelime hariç büyük, geri kalan harfleri küçük olacak şekilde ayarlar. Camel Case'i kullanarak bir hesap yönetimi işlevi tanımlamak isterseniz, adı hesap yönetimi olacaktır.
Pascal Case : Bu stil, tanımladığınız isimlerin kelimelerini birleştirerek, her kelimenin ilk harfinin ilk kelime dahil büyük harf, geri kalan harflerin küçük harf olmasını sağlar. Pascal Case kullanarak bir hesap yönetimi fonksiyonu tanımlamak isterseniz, adı GestionDeCuentas olacaktır.
Snake Case : Bu stil, tanımladığınız isimlerin kelimelerini birleştirir, tüm harfleri küçük harfe ve tüm kelimeleri bir alt çizgi ile ayıracak şekilde ayarlar. Snake Case'i kullanarak bir hesap yönetimi işlevi tanımlamak isteseydiniz, adı account_management olurdu.
Kebab Case : Bu stil, tanımladığınız isimlerin kelimelerini birleştirerek tüm harfleri küçük harf ve tüm kelimeleri tire ile ayıracak şekilde ayarlar. Snake Case'i kullanarak bir hesap yönetimi işlevi tanımlamak isteseydiniz, adı hesap yönetimi olurdu.
Daha iyi bir yöntem yoktur, ancak gerçek şu ki JavaScript'te Kebab Case pratik olarak atılır. Snake Case ile değişken isimleri tanımlamayı tercih eden birçok geliştirici olmasına rağmen, sınıf isimleri için Pascal Case ve hemen hemen her şey için Pascal Case kullanmak olağandır.
Kullanılacak Kurallar
Noktalı virgül: Pek çok geliştirici onları her satırın sonuna koymamayı tercih ediyor, ancak benim durumumda bazı durumlarda oluşabilecek olası sorunlardan kaçınmak için onları her satırın sonunda dini olarak kullanıyorum
Boşluklar: Her zaman daha az boşluk yerine daha fazla boşluk kullanmayı tercih ederim. Bunları genellikle bir satırın sonu olmadıkça parantez kapattığımda ve ayrıca +, -, / veya *, kontroller veya koşullar gibi aritmetik işlemlerin sembollerinden önce ve sonra kullanırım.
Boş satırlar: Farklı mantıksal işlemlerle ilgilenen kod bloklarını ayırmak için satır sonu kullanıyorum. Bu şekilde kodu okumanın daha kolay olduğunu düşünüyorum.
Girinti: Sekme tuşuna basmak yerine 4 boşluk kullanıyorum. İki boşluk kullanmak da yaygındır.
Satır uzunluğu: Satırlarımın uzunluğu 120 karakteri geçmiyor. Birçok geliştirici 80 karakter seçer, ancak ben bunu çok kısa buluyorum. Çok uzun satırlar kullanmak gibi kötü bir alışkanlığım var.
Yorumlar: Kodu belgelemek için genellikle yorum bloklarını kullanır ve bir şeye yorum yapma durumunda, yorumu satırın sonuna yazmak yerine, yorum yapmak istediğim satırın üstündeki satıra yazarım. Aynı şekilde sadece gerekli yorumları yazıyorum. Yani, JSDoc standardını takip eden kod blokları yeterli olduğunda veya değişken isimleri ne yapmak istediğimi anlamayı çok kolaylaştırdığında yorum kullanmıyorum.
Değişken bildirimleri: Değişkenleri asla var ile bildirmem. Bir değer veya referans değişmeyeceği zaman const kullanırım ve bir değişken bildirmek istediğimde izin veririm. Ben her zaman önce sabitleri sonra değişkenleri bildiririm, hem global değişkenler söz konusu olduğunda belgenin başında hem de yerel değişkenler söz konusu olduğunda işlevlerin başında bulunur. Bu şekilde JavaScript kaldırmanın istenmeyen etkilerinden kaçınırız.
İşlev yapısı: Bunun tedavisi nedeniyle mümkün olduğunda ok işlevlerini kullanıyorum. Bazen, kurucularda olduğu gibi, öyle değildir. Yapabildiğim zaman, şöyle işlevleri tanımlarım:
const miFuncion = (a, b) => a * b;
Değişken isimleri : Çok yakın zamana kadar Snake Case kullanmama rağmen, her zaman Camel Case kullanırım. Bu bir örnekcamelCase
Sınıf adları: Bu durumda hem sınıf adında hem de onu içeren dosyanın adında Pascal Case kullanıyorum. Bu bir örnektir PascalCase.
Tek veya çift tırnak: Mümkün olduğunda çift tırnak yerine tek tırnak kullanırım. Genellikle HTML öznitelik etiketleri için çift tırnak ayırırım, böylece içine JavaScript eklemem gerekirse, bunu çift tırnak ile yapabilirim. Bu kriteri PHP gibi diğer programlama dillerinde de uyguluyorum.
Şablon Değişmezleri: Bunlar, dizeleri tanımlamak için ters çevrilmiş tırnak işaretleri ` kullanan ifadelerdir. Metin dizelerine değişken eklemem gerektiğinde, değişkeni ortasına ekleyerek bu tırnak işaretlerini kullanırım. Aşağıdaki öğreticide şablon değişmezleri hakkında daha fazla bilgi bulabilirsiniz. Örnek: ` Burada bir ${variable} ` ekliyorum.
İşlev ve yöntem adları: Değişkenlerde olduğu gibi, sınıfların hem işlevleri hem de yöntemleri için Camel Case kullanıyorum. Örnek: CamelCase.
If ifadeleri: Bu durumda genellikle iki çeşit kullanırım, çünkü ifadeleri ne kadar uzun olduklarına bağlı olarak bir veya birkaç satıra yerleştirebilirim:
// Normal ise eğer (koşul) { // kod } // Eğer con un else eğer (koşul) { // kod } başka { // kod } // Eğer birkaç tane daha varsa eğer (koşul) { // kod } else if (koşul) { // kod } Başka { // kod }
Çok kısa ifadelerde tek satır kullanırım. Bu, bazı geliştiriciler tarafından oldukça eleştirilen bir şeydir, ancak ifadeler çok kısa olduğu sürece, bir değişkene atama yaptığınızda olduğu gibi çok okunabilir buluyorum. Başka bir durumda birkaç satır kullanırım:
// Normal ise if (ifade) değişkeni = true; // Başka biriyle ise if (ifade) değişkeni = true; başka değişken = yanlış;
Switch deyimleri: Bu durumda her zaman varsayılan bir koşul tanımlarım ve ayrıca birkaç satır kullanırım:
geçiş (ifade) { durum ifadesi: // kod varsayılan: // kod }
Döngüler için: Her zaman birkaç satır kullanırım. Bu durumda, döngü yinelemelerini tanımlayan öğeyi her zaman kendi tanımında başlatırım. Bunu, duruma sokmaktan daha iyi buluyorum. Döngü tanımının farklı öğelerini a ile ayırıyorum ;:
for (başlatma; koşul; güncelleme) { // kod }
Döngüler : Her zaman birkaç satır kullanırım:
while (koşul) { // kod }
Döngüler yapın: Genellikle bu döngüyü çok fazla kullanmam. Birkaç satırda:
yapmak { // kod } while (şart);
Try/catch/finally ifadeleri: Bunları şu şekilde tanımlıyorum:
// yakalamayı dene denemek { // kod } yakalama (hata) { // kod } // sonunda yakalamayı dene denemek { // kod } yakalama (hata) { // kod } nihayet { // kod }
Hangi stili seçerseniz seçin, önemli olanın tutarlı olmak ve projeniz boyunca bunu sürdürmek olduğunu unutmayın.
