EditorConfig Oluşturucu

.editorconfig ne işe yarar?

Bir projenin kök dizinindeki .editorconfig adlı dosya, biçimlendirme kurallarını bildirir. EditorConfig destekli editörler (her büyük IDE ve çoğu modern metin editörü) bir dosya açıldığında bu kuralları uygular. Arama, düzenlenen dosyadan başlayarak dizin ağacında yukarı doğru ilerler ve root = true yazan ilk dosyada durur.

Örnek çıktı

Varsayılan ayarlarla (boşluk, girinti boyutu 4, LF, utf-8) ve sizin için önceden işaretlenmiş iki bölümle oluşturucu şunu üretir:

root = true

[*]
indent_style = space
indent_size = 4
end_of_line = lf
charset = utf-8
trim_trailing_whitespace = true
insert_final_newline = true
max_line_length = 120

[*.{md,markdown}]
trim_trailing_whitespace = false

[{Makefile,makefile,GNUmakefile,*.mk}]
indent_style = tab

Python, Go veya YAML kutusunu işaretleyin; ilgili bölüm aşağıda belirir ve o ekosistemin biçimlendiricisinin dayattığı kuralı baştan taşır.

Temel direktifler

Stil kılavuzunu değil, derlemeyi bozan üç kural

Bir .editorconfig içindeki girdilerin çoğu tercihten ibarettir. Şu üçü değil ve dile özel bölüm tutmaya değmesinin nedeni de bunlar:

• YAML, girintide tab karakterine izin vermez. Bu bir ayrıştırma hatasıdır, lint uyarısı değil. Projeniz tab ile girinti yapıyorsa ve GitHub Actions iş akışlarınız, Docker Compose dosyalarınız ya da Kubernetes manifest dosyalarınız varsa, YAML bölümünün boşluğu geri zorlaması gerekir.
• make gerçek bir tab ister, hem de her kuralın komut satırının başında. Boşluk kullanırsanız missing separator. Stop. çıkar ve derleme durur. [{Makefile,makefile,GNUmakefile,*.mk}] bölümünün birkaç yazımı birden listelemesinin nedeni budur: EditorConfig dosya adlarını büyük/küçük harfe duyarlı eşleştirir ve depolarda hem Makefile hem makefile bulunur.
• CRLF ile kaydedilen bir kabuk betiği çalışmaz. Çekirdek, satır başı karakterini yorumlayıcı yolunun bir parçası olarak okur ve şuna benzer bir hata verir: /bin/bash^M: bad interpreter: No such file or directory. Windows toplu iş dosyalarında sorun tam tersidir: cmd.exe, goto ve call :label komutlarını bayt konumuna göre arar, bu yüzden yalnızca LF içeren bir .bat yanlış satıra atlayabilir veya hiç hata vermeden yarıda durabilir.

Bunlardan ikisini genel blok çözmek yerine kendisi yaratabilir; bu oluşturucunun onları kollamasının nedeni de budur. Tab seçip YAML bölümünü eklemezseniz ya da CRLF seçip kabuk betikleri bölümünü eklemezseniz, yazılan dosyada adları hiç geçmediği hâlde o dosyalar bozulur. Oluşturucu bunu çıktının üstünde söyler; böylece çöken bir pipeline size haber vermek zorunda kalmaz. Aynısı utf-16 karakter kümeleri için de geçerlidir: projedeki her dosya için geçerli olurlar ve make, kabuk yorumlayıcıları ile Python bu şekilde kaydedilmiş kaynak kodu okuyamaz.

Bu oluşturucunun yazdığı dil kuralları

Bu tabloda olmayana dikkat edin: satır uzunlukları. PEP 8 79 der, Black 88 der, PSR-12 esnek bir 120 der, rustfmt ise 100 der. Bunlardan herhangi birini dile özel bir bölüme yazmak, proje geneli için seçtiğiniz sınırı sessizce geçersiz kılardı. Bu yüzden oluşturucu max_line_length satırını yalnızca [*] bloğunda bırakır ve bu sayıları burada tutar; böylece onları bilerek uygulayabilirsiniz.

Editörünüz bunu destekliyor mu?

Yerleşik destek: VS Code, JetBrains IntelliJ ailesi, Visual Studio, Sublime Text, Xcode ve Notepad++. Vim, Emacs, Neovim ve birkaçı için küçük bir eklenti gerekir. Dosya düz INI biçiminde olduğundan linterlar ve biçimlendiriciler de okuyabilir; Prettier ile bazı dil sunucularının onunla uyumlu kalmasının yolu budur.