art’ı daha etkin bir şekilde kullanmanın temel prensipleri arasında tutarlılık, özlük, ve anlaşılabilirlik bulunmaktadır. Bu prensipleri göz önünde bulundurarak, aşağıda Dart dilinde örneklerle bu ilkelere nasıl uygun kod yazılacağını anlatacağım.
1. Tutarlılık: Dart’ta değişken isimlendirmesi ve kod bloklarının yapısı gibi unsurlarda tutarlılık sağlamak, kodunuzun anlaşılabilirliğini artırır. Örneğin, bir sınıf içindeki özel bir değişkeni ifade ederken “_privateVariable” yerine “privateVariable” gibi bir isimlendirme tercih edilmelidir. Aynı zamanda, kod bloklarını açık bir biçimde düzenlemek de önemlidir.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 | // Tutarlı değişken isimlendirmesi String kullaniciAdi = "JohnDoe"; int yas = 25; // Tutarsız isimlendirme String kAdi = "JohnDoe"; int age = 25; // Tutarlı kod bloğu düzeni void fonksiyonOrnegi() { // Kod } // Tutarsız kod bloğu düzeni void exampleFunction() { // Kod } |
2. Özlük ve Anlaşılabilirlik: Dart dilinde kısa ve açık ifadelerle niyetinizi ifade etmek önemlidir. Unutmayın, kodunuzun okunabilir olması, sadece sizinle değil, aynı zamanda başkalarıyla da iletişim kurabilmeniz açısından önemlidir.
1 2 3 4 5 6 7 | // Özlü ve anlaşılabilir kod List<String> meyveler = ["elma", "armut", "üzüm"]; // Karmaşık ve anlaşılmaz kod List<String> f = ["elma", "armut", "üzüm"]; |
Dart dilini etkin bir şekilde kullanmak, bu temel prensipleri gözeterek kod yazmakla başlar. Tutarlılık, özlük ve anlaşılabilirlik prensiplerine uygun olarak kod yazmak, hem kendi geliştirme sürecinizi iyileştirir hem de projenizde çalışan diğer geliştiricilerle daha iyi bir iletişim sağlar.
Türleri UpperCamelCase ile İsimlendirin
Sınıflar, enum tipleri, typedef’ler ve tip parametreleri, her kelimenin ilk harfini büyük harf yapmalıdır (ilk kelime dahil), ve ayırıcı kullanmamalıdır.
1 2 3 4 5 6 7 | class SliderMenu { ... } class HttpRequest { ... } typedef Predicate<T> = bool Function(T value); |
Bu örnekte görüldüğü gibi, Dart dilindeki sınıflar, enum tipleri, typedef’ler ve tip parametreleri isimlendirilirken UpperCamelCase kullanılmalıdır. Bu kural, kodunuzun tutarlı ve okunabilir olmasına katkı sağlar. Örneğin, SliderMenu ve HttpRequest gibi isimler, bu kurala uygun olarak adlandırılmalıdır. Aynı zamanda, Predicate tipini tanımlayan typedef kullanımı da bu kurala uygun bir örnektir. Bu, kodunuzu daha anlaşılır ve standart hale getirerek geliştirme sürecinizi iyileştirir.
Uzantıları UpperCamelCase ile İsimlendirin
Uzantılar da, tıpkı tipler gibi, her kelimenin ilk harfini büyük yapmalıdır (ilk kelime dahil), ve ayırıcı kullanmamalıdır.
1 2 3 4 5 | extension MyFancyList on List { … } extension SmartIterable on Iterable { … } |
Yukarıdaki örneklerde görüldüğü gibi, Dart dilindeki uzantılar da UpperCamelCase kullanılarak isimlendirilmelidir. Bu kural, uzantıların ve tip tanımlarının benzer bir şekilde adlandırılmasını sağlayarak kodunuzun tutarlılığını artırır. MyFancyList ve SmartIterable gibi örnekler, bu kurala uygun olarak isimlendirilmiştir. Bu uygulama, kodunuzu anlaşılır kılar ve projenizdeki diğer geliştiricilerle daha iyi bir iletişim kurmanıza yardımcı olur.
Paketleri, Dizinleri ve Kaynak Dosyalarını lowercase_with_underscores İle İsimlendirin
Bazı dosya sistemleri büyük-küçük harfe duyarsız olduğundan, birçok proje dosya adlarının tamamının küçük harf olmasını gerektirebilir. Ayırmak için bir karakter kullanmak, isimlerin bu biçimde hala okunabilir olmasını sağlar. Alt çizgileri ayırıcı olarak kullanmak, ismin hala geçerli bir Dart tanımlayıcısı olmasını sağlar; bu, dil daha sonra sembolik ithalatları desteklerse faydalı olabilir.
1 2 3 4 5 6 | my_package └─ lib └─ file_system.dart └─ slider_menu.dart |
İçe Aktarma Öneki İsimlendirmesini lowercase_with_underscores İle Yapın
1 2 3 4 5 6 | // İçe aktarma önekleri import 'dart:math' as math; import 'package:angular_components/angular_components.dart' as angular_components; import 'package:js/js.dart' as js; |
Yukarıdaki örnekte görüldüğü gibi, Dart dilindeki içe aktarma önekleri lowercase_with_underscores biçiminde isimlendirilmelidir. Bu kural, içe aktarma öneklerini okunabilir ve tutarlı bir biçimde adlandırarak projenizin anlaşılırlığını artırır. Örneğin, math, angular_components, ve js gibi içe aktarma önekleri bu kurala uygun olarak isimlendirilmiştir. Bu uygulama, kodunuzu daha düzenli ve bakımı daha kolay hale getirir.
Diğer Tanımlayıcıları lowerCamelCase İle İsimlendirin
1 2 3 4 5 6 7 8 9 10 | // Diğer tanımlayıcılar var count = 3; HttpRequest httpRequest; void align(bool clearItems) { // ... } |
Yukarıdaki örnekte görüldüğü gibi, Dart dilindeki sınıf üyeleri, üst düzey tanımlamalar, değişkenler, parametreler ve isimli parametreler lowerCamelCase biçiminde isimlendirilmelidir. Bu kural, tanımlayıcıları okunabilir ve tutarlı bir biçimde adlandırarak kodunuzun anlaşılırlığını artırır. Örneğin, count, httpRequest ve align gibi tanımlayıcılar bu kurala uygun olarak isimlendirilmiştir. Bu uygulama, projenizdeki tüm tanımlayıcıları tutarlı bir biçimde adlandırmanıza yardımcı olur ve kodunuzun bakımını kolaylaştırır.
Sabit İsimler İçin lowerCamelCase Kullanın
1 2 3 4 5 6 7 8 9 10 | // Sabit isimler için lowerCamelCase kullanımı const pi = 3.14; const defaultTimeout = 1000; final urlScheme = RegExp('^([a-z]+):'); class Dice { static final numberGenerator = Random(); } |
Yukarıdaki örnekte görüldüğü gibi, Dart dilindeki sabit değişkenler, enum değerleri dahil olmak üzere lowerCamelCase biçiminde isimlendirilmelidir. Bu kural, sabit isimlerini diğer tanımlayıcılardan ayırt etmek ve tutarlı bir biçimde adlandırmak için kullanılır. Örneğin, pi, defaultTimeout ve urlScheme gibi sabit değişkenler bu kurala uygun olarak isimlendirilmiştir. Bu uygulama, sabitlerinizi diğer değişkenlerden kolayca ayırt etmenize yardımcı olur ve kodunuzun anlaşılırlığını artırır.
İki Harften Uzun Akronim ve Kısaltmaları Kelimeler Gibi Büyük Harfle Başlatın
Büyük harfle başlayan akronimlerin okunması zor olabilir ve yan yana gelen birden fazla akronim, belirsiz isimlere yol açabilir. Örneğin, HTTPSFTP ile başlayan bir ismin HTTPS FTP’yi mi yoksa HTTP SFTP’yi mi ifade ettiğini anlamak mümkün değildir.
Bu durumu önlemek için, akronimler ve kısaltmalar, düzenli kelimeler gibi büyük harfle başlatılmalıdır.
İstisna: Giriş/Çıkış (IO) gibi iki harfli akronimler tamamen büyük harfle yazılırken; Tanımlama (ID) gibi iki harfli kısaltmalar hala düzenli kelimeler gibi büyük harfle yazılır.
1 2 3 4 5 6 7 8 9 10 11 12 13 | // Örnek sınıflar class HttpConnection {} class DBIOPort {} class TVVcr {} class MrRogers {} // Örnek değişkenler var httpRequest = ...; var uiHandler = ...; var userId = ...; Id id; |
Kullanılmayan Geri Çağrı Parametreleri İçin _ ve __ Gibi Karakterleri Kullanın
Bazen bir geri çağrı fonksiyonunun tür imzası bir parametre gerektirir, ancak geri çağrı uygulaması bu parametreyi kullanmaz. Bu durumda, kullanılmayan parametreye _ ismi vermek idiyomatiktir. Fonksiyonun birden fazla kullanılmayan parametresi varsa, isim çakışmalarını önlemek için ek alt çizgiler kullanılabilir: __, ___, vb.
1 2 3 4 5 | futureOfVoid.then((_) { print('Operasyon tamamlandı.'); }); |
Bu kılavuz, yalnızca hem anonim hem de yerel olan fonksiyonlar için geçerlidir. Bu fonksiyonlar genellikle, kullanılmayan parametrenin temsil ettiği şeyin ne olduğunun açık olduğu bir bağlamda hemen kullanılır. Bununla karşılaştırıldığında, üst düzey fonksiyonlar ve metod bildirimleri bu bağlama sahip olmadığından, parametrelerinin her birinin ne işe yaradığının açık olduğu bir isimlendirme kullanmalıdır, hatta kullanılmasa bile.
Tanımlanmamış Özel Olmayan İsimler İçin Önde Gelen Altbilgi Kullanmayın
Dart, bir tanımlayıcıda önde gelen altbilgi kullanarak üyeleri ve üst düzey bildirimleri özel olarak işaretlemek için bir altbilgi kullanır. Bu, kullanıcıları önde gelen bir altbilginin bu tür tanımlayıcılarla ilişkilendirildiği bir işaret olarak görmelerine neden olur. ” _ ” karakterini görünce “özel” düşüncesini akıllarına getirirler.
Ancak, yerel değişkenler, parametreler, yerel fonksiyonlar veya kütüphane öneki için “özel” bir kavram yoktur. Bu tür bir isimlendirme, okuyucuya karışık bir sinyal gönderir. Bu durumu önlemek için, bu tür isimlerde önde gelen altbilgi kullanmayın.
Ön Ek Harfleri Kullanmayın
Macar notasyonu ve benzeri düzenler, derleyicinin kodunuzu anlamanıza çok fazla yardımcı olmadığı BCPL döneminde ortaya çıkmıştır. Dart, deklarasyonlarınızın türü, kapsamı, değiştirilebilirlik ve diğer özellikleri hakkında size bilgi verebilen bir dil olduğu için, bu özellikleri tanımlayıcı isimlerine kodlamak için bir neden bulunmamaktadır.
Örnek olarak:
1 2 3 4 5 6 7 | // YANLIŞ KULLANIM int iDefaultTimeout = 1000; // DOĞRU KULLANIM const defaultTimeout = 1000; |
Yukarıdaki örnekte görüldüğü gibi, Dart dilinde deklarasyonların türünü belirtmek için önek harfleri kullanmak gereksizdir. Dart zaten deklarasyonların özelliklerini anlama yeteneğine sahip olduğu için, defaultTimeout gibi açık ve anlaşılır bir isim kullanmak daha uygundur.
Kütüphaneleri Açıkça İsimlendirmeyin
Kütüphane yönergesine bir isim eklemek teknik olarak mümkündür, ancak bu eski bir özelliktir ve önerilmez.
Dart, her kütüphane için yol ve dosya adına dayalı benzersiz bir etiket oluşturur. Kütüphanelere isim eklemek, bu oluşturulan URI’yi geçersiz kılar. URI olmadan, araçların ilgili ana kütüphane dosyasını bulması daha zor olabilir.
1 2 3 4 5 6 7 8 | // YANLIŞ KULLANIM library my_library; /// Gerçekten harika bir test kütüphanesi. @TestOn('browser') library; |
Yukarıdaki örnekte görüldüğü gibi, Dart dilinde kütüphanelere isim eklemek teknik bir özelliktir ve eski bir uygulamadır. Bu kullanım, oluşturulan URI’yi geçersiz kılabilir ve araçların ana kütüphane dosyasını bulmasını zorlaştırabilir. Bu nedenle, kütüphaneleri açıkça isimlendirmekten kaçınılmalıdır.
Sıralama
Dosyanızın ön kısmını düzenli tutmak için, direktiflerin görünmesi gereken önceden belirlenmiş bir sıralama düzenine sahibiz. Her “bölüm” arasında bir boş satır olmalıdır.
dart: İçe Aktarmalarını Diğer İçe Aktarmalardan Önce Yerleştirin
1 2 3 4 5 6 7 8 | // Dart içe aktarmalarını diğer içe aktarmalardan önce yerleştirme import 'dart:async'; import 'dart:html'; import 'package:bar/bar.dart'; import 'package:foo/foo.dart'; |
package: İçe Aktarmalarını Relatif İçe Aktarmalardan Önce Yerleştirin
1 2 3 4 5 6 7 | // package: İçe aktarmalarını relatif içe aktarmalardan önce yerleştirme import 'package:bar/bar.dart'; import 'package:foo/foo.dart'; import 'util.dart'; |
Import İçe Aktarmalardan ve package: İçe Aktarmalarından Sonra Belirtin
1 2 3 4 5 6 7 | // Import içe aktarmalardan ve package: içe aktarmalardan sonra belirtme import 'src/error.dart'; import 'src/foo_bar.dart'; export 'src/error.dart'; |
Yukarıdaki örneklerde görüldüğü gibi, Dart dilindeki direktifleri belirli bir sıraya göre düzenlemek, kodunuzu daha düzenli ve anlaşılır hale getirir. Bu sıralama kurallarına uymak, projelerde tutarlı bir yapı oluşturmanıza yardımcı olur.
Tüm Akış Kontrol İfadeleri İçin Ayraç Kullanın
Bu, sarkık else sorununu önler.
1 2 3 4 5 6 | if (isWeekDay) { print('İşe bisikletle gidin!'); } else { print('Dans edin veya kitap okuyun!'); |
İstisna: Eğer bir else bloğu olmayan bir if ifadesine sahipseniz ve tüm if ifadesi tek bir satıra sığarsa, süslü parantezleri isteğe bağlı olarak atlayabilirsiniz:
1 2 3 | if (arg == null) return defaultValue; |
Ancak, gövde bir sonraki satıra geçiyorsa, süslü parantezleri kullanın:
1 2 3 4 5 | if (overflowChars != other.overflowChars) { return overflowChars < other.overflowChars; } |
Yukarıdaki örnekte görüldüğü gibi, Dart dilindeki tüm akış kontrol ifadeleri için süslü parantez kullanmak, kodunuzu daha tutarlı ve okunabilir hale getirir. Bu kurala uymak, özellikle karışık else durumlarını önlemek için önemlidir.
Cümle Gibi Yorumları Biçimlendirin
Oluşturulan belgelerde yer almasını istemediğiniz yorumlar için aşağıdaki ipuçları geçerlidir.
1 2 3 4 | // Bir şey önce gelmiyorsa değil. if (_chunks.isNotEmpty) return false; |
İlk kelimeye büyük harf kullanın, özel bir durum belirleyen bir tanımlayıcı değilse. Nokta (veya “!” veya “?”, sanırım) ile bitirin. Bu, tüm yorumlar için geçerlidir: doküman yorumları, satır içi açıklamalar, hatta TODO’lar. Cümle parçacığı olsa bile bu kural geçerlidir.
Belgeler İçin Blok Yorumları Kullanmayın
1 2 3 4 5 | void greet(String name) { // Geçerli bir isim olduğunu varsayalım. print('Merhaba, $name!'); |
Yukarıdaki örnekte görüldüğü gibi, dokümantasyon için blok yorumları kullanmak yerine satır içi yorumlar kullanılmalıdır. Bu, kodunuzun daha temiz ve anlaşılır olmasına yardımcı olur.
Üyeleri ve Türleri Belgelemek İçin /// Doc Yorumları Kullanın
dart doc tarafından bulunup belge oluşturabilmesi için düzenli bir yorum yerine bir doc yorumu kullanmak önemlidir.
1 2 3 4 | /// Bu parçanın bölünmemiş haliyle karakter sayısı. int get length => ... |
Yukarıdaki örnekte görüldüğü gibi, üyeleri ve türleri belgelemek için /// doc yorumlarını kullanmak, kodunuzu daha belirgin ve anlaşılır kılar. Bu aynı zamanda dart doc aracının bu yorumları bulup belge oluşturabilmesini sağlar.
Özel API’lar İçin Doc Yorumları Yazın
Doc yorumları sadece kütüphanenizin genel API’sini kullananlar için değil, aynı zamanda kütüphanenizin diğer kısımlarından çağrılan özel üyeleri anlamak için de faydalı olabilir.
DO: Doc Yorumlarına Tek Cümlelik Özetle Başlayın
1 2 3 4 5 6 | /// [path] konumundaki dosyayı sistemden siler. void delete(String path) { ... } |
Yukarıdaki örnekte görüldüğü gibi, doc yorumlarına tek bir cümlelik bir özetle başlamak, okuyucunun kendini oryante etmesi ve devam edip etmemeye ya da sorunlarının çözümünü başka bir yere bakmaya karar vermesi için yeterli bağlamı sağlar. Bu aynı zamanda dart doc gibi araçların bu yorumları bulup kısa özetler oluşturmasına yardımcı olur.
Bir Doc Yorumunun İlk Cümlesini Kendi Paragrafına Ayırın
İlk cümleden sonra bir boş satır ekleyerek onu kendi paragrafına bölebilirsiniz. Eğer kullanışlıysa açıklamanın bir cümleden fazlasını kullanın.
Bu, belgelemenin özetini içeren sıkı bir ilk cümle yazmanıza yardımcı olur. Ayrıca, dart doc gibi araçlar, sınıf ve üyelerin listeleri gibi yerlerde ilk paragrafı kısa bir özet olarak kullanır.
1 2 3 4 5 6 7 8 9 | /// [path] konumundaki dosyayı siler. /// /// Eğer dosya bulunamazsa [IOError] fırlatır. Dosya bulunsa da silinemiyorsa /// [PermissionError] fırlatır. void delete(String path) { ... } |
Yukarıdaki örnekte görüldüğü gibi, doc yorumlarının ilk cümlesini kendi paragrafına ayırmak, kodunuzu daha düzenli ve okunabilir hale getirir. Bu aynı zamanda belgeleme araçlarının daha etkili bir şekilde özet oluşturmasına yardımcı olur.
Fonksiyon veya Metod Yorumlarına Üçüncü Tekil Şahıs Fiilleri İle Başlamayı Tercih Edin
Belgeleme yorumu, kodun ne yaptığına odaklanmalıdır.
1 2 3 4 5 6 7 8 9 | /// [predicate] koşulu her öğeyi karşılıyorsa `true` döner. bool all(bool predicate(T element)) => ... /// Daha önce başlatılmadıysa kronometreyi başlatır. void start() { ... } |
Boolean Olmayan Bir Değişken veya Özellik Yorumuna İsim Tamlaması İle Başlamayı Tercih Edin
Belgeleme yorumu, özelliğin ne olduğuna odaklanmalıdır. Bu, hesaplama veya başka bir iş yapabilen getter’lar için bile geçerlidir. Çağıranın ilgilendiği şey, bu işin kendisi değil, işin sonucudur.
1 2 3 4 5 6 7 | /// Günün günü, `0` Pazar'dır. int weekday; /// Sayfadaki kontrol edilen düğmelerin sayısı. int get checkedCount => ... |
Boolean Değişken veya Özellik Yorumuna “Whether” İle Başlayan İsim veya Gerund İfadeyi Tercih Edin
Belgeleme yorumu, bu değişkenin temsil ettiği durumları açıklamalıdır. Bu, hesaplama veya başka bir iş yapabilen getter’lar için bile geçerlidir. Çağıranın ilgilendiği şey, bu işin kendisi değil, işin sonucudur.
1 2 3 4 5 6 7 8 9 10 11 | /// Modal şu anda kullanıcıya gösteriliyorsa `true` döner. bool isVisible; /// Modal'in kullanıcının gezinme niyetini onaylaması gerekip gerekmediği. bool get shouldConfirm => ... /// Mevcut tarayıcı penceresini yeniden boyutlandırmanın modal'i de /// yeniden boyutlandırıp boyutlandıramayacağı. bool get canResize => ... |
Yukarıdaki örneklerde görüldüğü gibi, Dart dilindeki belgeleme yorumlarını daha açık ve anlaşılır hale getirmek için belirli bir dil kullanmak önemlidir. Bu kılavuzlara uyarak, kodunuzu daha anlaşılır ve bakımı daha kolay hale getirebilirsiniz.
Terimleri Tutarsızlıkla Kullanmayın
Kodunuzu okunabilir ve bakımı yapılabilir hale getirmenin önemli bir parçası, terimleri tutarlı bir şekilde kullanmaktır. Kodunuz boyunca aynı şey için aynı adı kullanın. Kullanıcıların muhtemelen bildiği bir önceden örnek zaten varsa, o önceden örneği takip edin.
1 2 3 4 5 6 7 | pageCount // Bir alan. updatePageCount() // pageCount ile tutarlı. toSomething() // Iterable'ın toList() ile tutarlı. asSomething() // List'in asMap() ile tutarlı. Point // Tanıdık bir kavram. |
Kısaltmalardan Kaçının
Eğer kısaltma, kısaltılmamış terimden daha yaygın değilse, kısaltma kullanmaktan kaçının. Eğer kısaltma kullanıyorsanız, doğru bir şekilde büyük harf kullanın.
1 2 3 4 5 6 | pageCount // Önerilen buildRectangles // Önerilen IOStream // Önerilen HttpRequest // Önerilen |
Yukarıdaki örnekte görüldüğü gibi, kısaltmalar yerine kelimelerin tamamını kullanmak, kodunuzu daha anlaşılır ve okunabilir hale getirir. Eğer bir kısaltma yaygın kullanılan bir terimden daha bilinmiyorsa veya daha az anlaşılıyorsa, tam terimi kullanmak daha iyidir.
Açıklayıcı İsimi En Sona Koyun
Son kelime, şeyin ne olduğunu en iyi açıklayan kelime olmalıdır. Şeyi daha fazla açıklamak için sıfatlar gibi diğer kelimelerle öne ekleyebilirsiniz.
1 2 3 4 5 6 | pageCount // Sayfa sayısı. ConversionSink // Dönüşümler için bir giriş. ChunkedConversionSink // Parçalanmış bir ConversionSink. CssFontFaceRule // CSS'teki font yüzleri için bir kural. |
Yukarıdaki örnekte görüldüğü gibi, Dart dilinde, bir şeyin ne olduğunu en iyi açıklayan kelimenin en sonda olması önemlidir. Bu, kodunuzu daha anlaşılır ve açıklamalı hale getirir.
Kodun Bir Cümle Gibi Okunmasını Sağlayın
İsimlendirme konusunda şüpheniz varsa, API’nizi kullanan bir kod yazın ve bunu bir cümle gibi okumaya çalışın.
1 2 3 4 5 6 7 8 9 10 | // "Eğer hatalar boşsa..." if (errors.isEmpty) ... // "Hey, abonelik, iptal et!" subscription.cancel(); // "Canavarın pençelere sahip olduğu canavarları al." monsters.where((monster) => monster.hasClaws); |
Yukarıdaki örnekte görüldüğü gibi, Dart dilinde kodunuzu bir cümle gibi okunabilir hale getirmek, kodunuzu daha anlaşılır ve okunabilir kılar. Bu, kodunuzu başkalarının daha kolay anlamasına yardımcı olabilir ve dilin doğal akışına daha uygun bir isimlendirme sağlayabilir.
Boolean Olmayan Bir Özellik veya Değişken İçin İsim Tamlamasını Tercih Edin
Okuyucunun odak noktası, özelliğin ne olduğudur. Eğer kullanıcı bir özelliğin nasıl belirlendiği konusunda daha çok ilgileniyorsa, muhtemelen bu bir yöntem olmalı ve ismi bir fiil tamlaması olmalıdır.
1 2 3 4 5 | list.length // Önerilen context.lineWidth // Önerilen quest.rampagingSwampBeast // Önerilen |
Yukarıdaki örnekte görüldüğü gibi, Dart dilinde boolean olmayan bir özellik veya değişken için isim tamlaması kullanmak, kodunuzu daha açıklayıcı ve anlaşılır hale getirir. Bu, kullanıcıların odaklanması gerekenin ne olduğunu netleştirir ve kodunuzu daha okunabilir hale getirir.
Adlandırılmış Boolean Parametre İçin Fiilin Atlanması
Bu kuralı rafine eder. Boolean olan adlandırılmış parametreler için, fiil olmadan ismin kullanılması genellikle aynı kadar açıklayıcıdır ve çağrı yerinde kod daha iyi okunur.
1 2 3 4 5 | Isolate.spawn(entryPoint, message, paused: false); var copy = List.from(elements, growable: true); var regExp = RegExp(pattern, caseSensitive: false); |
Boolean Özelliği veya Değişkeni İçin “Olumlu” İsmi Tercih Edin
Çoğu boolean ismi, kavramsal olarak “olumlu” ve “olumsuz” formlara sahiptir, ilk olan genellikle temel kavram gibi hisseder ve ikincisi bunun tersidir – “açık” ve “kapalı”, “etkin” ve “devre dışı” vb. Genellikle ikinci isim, kelimesel olarak öncekini tersine çeviren bir öneki vardır: “görünür” ve “görünmez”, “bağlı” ve “bağlı değil”, “sıfır” ve “sıfır değil”.
Eğer true‘nin temsil ettiği iki durumdan birini seçme – ve bu durum özelliğin adlandırıldığı durum – gerekiyorsa, olumlu veya daha temel olanı tercih edin. Boolean üyeler genellikle mantıksal ifadeler içinde iç içe geçer, bu ifadeler içinde negasyon operatörleri dahil. Özelliğiniz kendisi bir negasyon gibi okunuyorsa, okuyucunun zihinsel olarak çift negasyon yapmasını ve kodun ne anlama geldiğini anlamasını daha zor hale getirir.
1 2 3 4 5 6 7 8 | if (socket.isConnected && database.hasData) { socket.write(database.read()); } if (!socket.isDisconnected && !database.isEmpty) { socket.write(database.read()); } |
Bazı özellikler için olumlu bir form açıkça belirgin değildir. Disk’e yazılan bir belge “kaydedilmiş” veya “değiştirilmemiş” midir? Söz konusu özelliklerde, kullanıcıların genellikle olumsuz formu kullanmaları zorunludur. Olumsuz ifade, kullanıcıların özelliği her yerde ! ile geçmesini zorlamak yerine, o özelliği kullanmak için daha iyi olabilir.
Yan Etkisi Olan Bir Fonksiyon veya Metod İçin İsimlendirilmiş Fiil Tamlamasını Tercih Edin
Çağrılabilir üyeler, çağrıyı yapana bir sonuç döndürebilir ve diğer işleri veya yan etkileri gerçekleştirebilir. Dart gibi emir kipinde olan bir dilde, üyeler genellikle yan etkileri için çağrılır: bir nesnenin iç durumunu değiştirebilir, bazı çıktı üretebilir veya dış dünya ile iletişim kurabilir.
Bu tür üyeler, üyenin gerçekleştirdiği işi açıklayan bir emir kipi fiil tamlaması kullanılarak adlandırılmalıdır.
1 2 3 4 5 | list.add('element'); queue.removeFirst(); window.refresh(); |
Bu şekilde, bir çağrı, bu işi yapmak için bir komut gibi okunur.
Yukarıdaki örneklerde, Dart dilinde etkili
kullanım için temel adlandırma ilkeleri, fonksiyon ve metotların adlandırılması, boolean özelliklerin isimlendirilmesi ve dökümantasyon konularında bazı temel prensipler özetlenmiştir. Ancak, tamamlayıcı bilgiler, örnekler ve ayrıntılar için Dart Etkili Dart bağlantısına başvurmanızı öneririm. Bu kaynak, Dart dilinde etkili kod yazımı için kapsamlı bir kılavuz sunmaktadır.
Yorum Yap