- Yabancı bir kod tabanını bakımını yaparken string aramak için çok zaman harcanır
- Kendi başınıza yazdığınız projelerde bile fonksiyon adları, hata mesajları, sınıf adları gibi birçok şeyi aramak gerekir
- Arama iyi çalışmıyorsa kod tabanında referanslar bulunamayabilir ve bu da bir şeyin gereksiz olduğu sanılmasına yol açabilir
- Bu durumda kod tabanının greppability’sini korumak için uygulanabilecek bazı kurallar çıkarılmış
Tanımlayıcıları parçalamayın
- Tanımlayıcıları parçalamak veya dinamik olarak oluşturmak iyi bir fikir değildir
shipping_addresses ve billing_addresses adında iki veritabanı tablosu olduğunu varsayalım; sipariş türüne göre tablo adını dinamik olarak oluşturmak iyi görünebilir
const getTableName = (addressType: 'shipping' | 'billing') => {
return `${addressType}_addresses`
}
- Bu DRY görünebilir ama bakım açısından iyi değildir. Birisi kod tabanında
shipping_addresses tablo adını ararken bu kısmı gözden kaçırabilir
- Tanımlayıcıları hardcode etmek daha iyi bir yöntemdir
- Aranabilirlik için refactor edilmiş kod:
const getTableName = (addressType: 'shipping' | 'billing') => {
if (addressType === 'shipping') {
return 'shipping_addresses'
}
if (addressType === 'billing') {
return 'billing_addresses'
}
throw new TypeError('addressType must be billing or shipping')
}
- Aynısı sütun adları, nesne alanları, metod/fonksiyon adları için de geçerlidir (JavaScript’te metod adlarını dinamik olarak oluşturmak kolaydır)
Tüm stack boyunca aynı adı kullanın
- Adlandırma şemasına uymak için uygulama sınırlarında alan adlarını değiştirmeyin
- Tipik bir örnek olarak, PostgreSQL tarzı snake_case tanımlayıcıları JavaScript’e getirip camelCase’e dönüştürmek iyi bir fikir değildir
- Bu aramayı zorlaştırır. Her şeyi bulmak için tek bir string yerine iki farklı string aramanız gerekir
const getAddress = async (id: string) => {
const address = await getAddressById(id)
return {
streetName: address.street_name,
zipCode: address.zip_code,
}
}
- Bunun yerine nesneyi doğrudan döndürmek daha iyidir
const getAddress = async (id: string) => {
return await getAddressById(id)
}
İç içeliktense düz yapı daha iyidir
- Python’un Zen’inden ilhamla, namespace’lerle çalışırken klasör/nesne yapısını iç içe kurmaktansa düz tutmak çoğu zaman daha iyidir
- Çeviri dosyası yapılandırması için iki seçenek varsa:
{
"auth": {
"login": {
"title": "Login",
"emailLabel": "Email",
"passwordLabel": "Password",
},
"register": {
"title": "Register",
"emailLabel": "Email",
"passwordLabel": "Password",
}
}
}
{
"auth.login.title": "Login",
"auth.login.emailLabel": "Email",
"auth.login.passwordLabel": "Password",
"auth.register.title": "Login",
"auth.register.emailLabel": "Email",
"auth.register.passwordLabel": "Password",
}
- İkinci seçeneği tercih etmek daha iyidir. Anahtarlar kolayca bulunabilir ve
t('auth.login.title') gibi referans verilebilir
- React component yapısını düşünürsek:
./components/AttributeFilterCombobox.tsx
./components/AttributeFilterDialog.tsx
./components/AttributeFilterRating.tsx
./components/AttributeFilterSelect.tsx
- Bu yapı, aşağıdaki gibi bir yapıya göre tercih edilir
./components/attribute/filter/Combobox.tsx
./components/attribute/filter/Dialog.tsx
./components/attribute/filter/Rating.tsx
./components/attribute/filter/Select.tsx
- Çünkü arama açısından bakıldığında,
Dialog gibi genel bir ad yerine AttributeFilterCombobox gibi namespace içeren tam component adını arayabilirsiniz
GN⁺ görüşü
- Bu blog yazısı, kod tabanını bakımını yaparken tanımlayıcı aramanın önemini iyi anlatıyor
- Tanımlayıcıları dinamik oluşturmak veya uygulama sınırlarında adları değiştirmek, kod bakımını zorlaştırır. Tanımlayıcılar tutarlı ve açık olmalıdır
- Bunun yerine tanımlayıcıları hardcode etmek ve namespace’leri düz tutmak, arama açısından daha iyidir
- Kod okunabilirliğini ve bakım kolaylığını artırmak için bu ilkeleri projelerde uygulamak faydalı olacaktır
- Yazarın önerdiği kuralların dışında da Self-Documenting Code yazmak, anlamlı yorumlar kullanmak gibi kod kalitesini artıran çeşitli yöntemler vardır
5 yorum
JSON'in full path'ine dönüştürüp grep yapılabilir hale getiren bir araç da bırakayım!
https://tr.news.hada.io/topic?id=3159
Güzelmiş... greppability ha...
Faydalı bilgileri mümkün olduğunca tek satıra yazmak da yararlı gibi görünüyor.
Güzelmiş
Hacker News görüşleri
Fonksiyon adları ve sınıf adları gibi sembolleri aramak, kodun sözdizimini anlayan araçları kullanmaya kıyasla zayıf kalıyor
grep aracında "süper büyük/küçük harf duyarsız" bir mod olması faydalı olurdu
grep yapılabilirliğini destekliyorum
Hamilton tasarlanırken amaç, fonksiyon tanımlarını ve bunların alt kullanımlarını grep ile kolayca bulunabilir kılmaktı
'greppable' kendi başına yaygın kullanılan bir kelime/kavram değil
Koşullu string interpolation kullanan karmaşık örnekler gördüm
Birçok kodlama stili ve araç, dize sabitlerini uzunluklarından bağımsız olarak tek satırda tutar
Rust, Javascript ve Lisp, fonksiyon tanımlarının önüne anahtar kelime koyarak aramayı kolaylaştırır
greppability'ye katılıyorum, ancak sınırları aşarken adların aynı kalmasına karşıyım
Kodun aranabilir olması iyi, ancak örnekler kasıtlı olarak hata olasılığını artırıyor