Dosyalar ve klasörler için Node.js projesi adlandırma kuralları


118

Büyük bir Node.js projesindeki dosyalar ve klasörler için adlandırma kuralları nelerdir?

Büyük harf mi kullanmalıyım, camelCase mi yoksa alt puan mı almalıyım?

Yani. bu geçerli kabul edilir mi?

project-name
    app
        controllers
            someThings.js
            users.js
        models
                someThing.js
                user.js
        views
            some-things
                index.jade
            users
                logIn.jade
                signUp.jade
    ...

3
Oldukça özneldir, dizin yapınız size aittir. Ben şahsen camelCase'i seviyorum çünkü JS'de yaptığım budur
Çad

@Chad - Node.js'de require, dizin dizesini parametre olarak alır, bu yüzden tamamen size ait değildir . yani. require('../app/controllers/someThings');
Rudiger

3
Düğüm, geçerli dosya / dizin adları oldukları ve çekirdek modül adlarını geçersiz kılmaya çalışmadıkları sürece, modülleri adlandırmak için herhangi bir öneri veya standart belirtmez . Kendi modülleri için kısaltılmış ( fs), tek kelimeli ( events), altı çizili ( child_process) ve küçük harfli ( querystring) bir karışım kullanır .
Jonathan Lonowski

1
@Rudiger Yani? İstediğiniz dizeyi ve sahip olabileceğiniz dizin yapısını belirtebilirsiniz (adlarınızın elbette geçerli dosya adları olması koşuluyla).
Çad

Kaptan-awesome-file.js gibi mocha dosya adları gibi daha kilit taşı projelerinin etrafından dolaşmaktan anladığım kadarıyla yeterince yaygın görünüyor. En azından ben bunu kullanacağım!
Charles Ferentchak

Yanıtlar:


155

Düğümle birkaç yıl geçirdikten sonra , dizin / dosya yapısı için herhangi bir konvansiyonun olmadığını söyleyebilirim . Ancak çoğu (profesyonel) ekspres uygulama aşağıdaki gibi bir kurulum kullanır:

/
  /bin - scripts, helpers, binaries
  /lib - your application
  /config - your configuration
  /public - your public files
  /test - your tests

Bu kurulumu kullanan bir örnek nodejs-starter'dır .

Bu kurulumu kişisel olarak şu şekilde değiştirdim:

/
  /etc - contains configuration
  /app - front-end javascript files
    /config - loads config
    /models - loads models
  /bin - helper scripts
  /lib - back-end express files
    /config - loads config to app.settings
    /models - loads mongoose models
    /routes - sets up app.get('..')...
  /srv - contains public files
  /usr - contains templates
  /test - contains test files

Kanımca, ikincisi Unix tarzı dizin yapısıyla daha iyi eşleşiyor (oysa eski bunu biraz karıştırıyor).

Dosyaları ayırmak için bu kalıbı da seviyorum:

lib / index.js

var http = require('http');
var express = require('express');

var app = express();

app.server = http.createServer(app);

require('./config')(app);

require('./models')(app);

require('./routes')(app);

app.server.listen(app.settings.port);

module.exports = app;

lib / static / index.js

var express = require('express');

module.exports = function(app) {

  app.use(express.static(app.settings.static.path));

};

Bu, bağımlılıkları rahatsız etmeden tüm kaynak kodunun düzgün bir şekilde ayrıştırılmasına izin verir. Kötü Javascript ile savaşmak için gerçekten iyi bir çözüm. Yakında bu kurulumu kullanan gerçek dünya örneği var .

Güncelleme (dosya adları):

Dosya adlarıyla ilgili olarak en yaygın olanı kısa , küçük harfli dosya adlarıdır. Dosyanız yalnızca iki kelimeyle açıklanabiliyorsa, çoğu JavaScript projesi sınırlayıcı olarak bir alt çizgi kullanır.

Güncelleme (değişkenler):

Değişkenlerle ilgili olarak, dosya adlarıyla aynı "kurallar" geçerlidir. Ancak prototipler veya sınıflar camelCase kullanmalıdır .

Güncelleme (stil kılavuzları):


27
Cevabınız ne kadar ilginç ve iyi yapılmış, konu dışı, konuyu oluşturan kişi özellikle dizin yapıları için değil adlandırma kuralı istedi. Bu konuya geldiğimizde, dosyaların kısa çizgi, alt çizgi veya camelCase ile daha iyi adlandırılıp adlandırılmadığını öğrenmeyi umuyoruz. Bu cevaba eklenirse, oy vereceğim.
Tronix117

3
@ Tronix117 sorun nedir? Soru, "dosyalar ve klasörler için proje adlandırma kuralları mı?" ve adlandırma, tam yol adını da içerdiğinden dosya adıyla sınırlı değildir.
bodokaiser

24
elbette, ancak yazar özellikle "Büyük harf mi yazmalıyım, camelCase mi yoksa az puan mı almalıyım?" Örneğini yazarken, yalnızca geçerli olarak kabul edilip edilemeyeceğini bilmek için açıkça 'bazı şeyler' ve 'bazı şeyler' koydu. Bu konuya gittiğimde, bu özel sorunun cevabını ve genellikle dosya adlandırma olarak neyin kullanıldığını bilmeyi bekliyordum. Cevabınızın yanlış olduğunu söylemiyorum, amacı için mükemmel ama aklımda eksik çünkü asıl soruya gerçekten cevap vermiyor.
Tronix117

5
Sanırım beni yanlış anladın ;). Sadece kabul edilen cevapta bulamadığım bir şeyi arıyordum, ama özellikle soruldu, hiçbir şekilde nefret yaymak değil, bu konuda biraz ileri gidiyorsunuz. Sadece cevaba bununla ilgili bazı bilgiler eklemenizi istedim, böylece gelecekte bunu arayacak insanlar çıkmaza girmesinler.
Tronix117

3
@ Tronix117 Aslında bu yüzden kendimi bu sayfada bu cevabı okurken buldum. Sadece dizin yapısını değil, daha da önemlisi isim kurallarını (kısa çizgiler, alt çizgiler, camelCase, TitleCase, vb.) Umuyordum. Ne yazık ki, cevap hala onu içermiyor ve bodokaiserbenim için çok kişisel bir şeyler alıyor gibi görünüyor ve bu konudaki fikrinin cevabına eklenmesini istemem (OP'nin başlangıçta sorduğu gibi) ( öksürük öksürüğü ).
döner

99

kebab-caseTüm paket, klasör ve dosya adları için kullanın .

Neden?

Herhangi bir klasör veya dosyanın bir gün kendi paketine çıkarılabileceğini hayal etmelisiniz. Paketler büyük harf içeremez.

Yeni paketlerin adında büyük harf olmamalıdır. https://docs.npmjs.com/files/package.json#name

Bu nedenle camelCaseasla kullanılmamalıdır. Bu bırakır snake_caseve kebab-case.

kebab-casebugün açık farkla en yaygın sözleşmedir. Alt çizgilerin tek kullanımı dahili düğüm paketleri içindir ve bu sadece ilk günlerden kalma bir kuraldır.


2
noktayı unuttun mu? like socket.io
Roee

1
.2c, regex kullanarak herhangi bir dilde herhangi bir komut dosyası veya uygulamada kebab-case'den kebabCase'e kadar basit bir otomasyon yapabilir - bunu her zaman yapın 🙃
rob2d

63

Konvansiyon yok. Bazı mantıksal yapılar var.

Söyleyebileceğim tek şey: CamelCase dosya ve dizin adlarını asla kullanmayın. Neden? Çalışır, ancak Mac ve Windows'ta bazıAction ve bazı eylemler arasında fark yoktur. Bu problemle bir kez karşılaşmadım. Bunun gibi bir dosyaya ihtiyacım var:

var isHidden = require('./lib/isHidden');

Ama ne yazık ki ben küçük harf dolu olan bir dosya oluşturuldu: lib/ishidden.js. Mac'te benim için çalıştı. İş arkadaşımın Mac'inde iyi çalıştı. Testler hatasız çalışır. Dağıtımdan sonra büyük bir hata aldık:

Error: Cannot find module './lib/isHidden'

Ah evet. Bu bir linux kutusu. Bu nedenle camelCase dizin yapısı tehlikeli olabilir. Windows veya Mac'te geliştirme yapan bir meslektaş için yeterli.

Bu nedenle, gerekirse alt çizgi (_) veya kısa çizgi (-) ayırıcı kullanın.


4
+1, cs olmayan bir sistemde git içindeki büyük / küçük harfe duyarlı klasörleri yeniden adlandırmanın gerçek bir güçlük olduğu gerçeğini ekleyin.
en fazla

4
Burada camelCase ile ilgili sorunu gerçekten anlamıyorum. Dosyayı ilk etapta doğru şekilde adlandırarak (lib / isHidden.js) sorun çözülmez mi?
Mike

Hey Mike, önemli olan şu ki, camelCase bazı sistemlerde konuşlandırmaya ara verecek. Mac'ten "groupPages" adlı bir pakete sahip bir Linux kutusuna konuşlandırdığımda dizinlerimin neden 404'leri aldığı konusunda kafam karışmıştı. Bir şeyleri düzeltmek için grup sayfalarına geçmek zorunda kaldım.
tempranova

3
Daha da kötüsü: bir dosya adının deve harfli bir sürümünü oluşturun ve dikkatsiz bir meslektaşınızın aynı dizinde küçük harfli bir sürüm oluşturmasını sağlayın. Şimdi büyük / küçük harfe duyarlı olmayan bir işletim sisteminde bir kontrol yapın ve uygulamanızın neden çalışmadığını anlamaya çalışın. Ve evet, bu oldu.
L0LN1NJ4

Bu cevabı beğendim, ancak bu tire (-) 'nin de bazı sorunları olabileceğini belirtmek istiyorum. Örneğin, Nighwatch test çerçevesini kullanarak admin-login.js adında bir sayfa nesnesi oluşturdum. Daha sonra kullanarak test komut dosyasından erişmeye çalıştım const loginPage = browser.page.admin-login(). Hata aldım ReferenceError: login is not defined. Dosya adı için alt çizgi (_) kullanmak sorunu çözdü. Komut satırında tire karakteriyle dosya adları kullanmanın da bazı sorunlara yol açabileceğini hayal edebiliyorum. Bu nedenle, alt çizginin genel olarak dosya adları için en güvenli ayırıcı olduğunu söyleyebilirim.
Dragan Nikolic

15

" Google JavaScript Stil Kılavuzu " na göre

Dosya adlarının tümü küçük harf olmalıdır ve alt çizgi (_) veya kısa çizgi (-) içerebilir, ancak ek noktalama işareti içeremez. Projenizin kullandığı kuralı izleyin. Dosya adlarının uzantısı .js olmalıdır.


3

Çoğu insan camelCaseJS'de kullanır . Herhangi bir şeyi açık kaynak yapmak istiyorsanız, bunu kullanmanızı öneririm :-)


Locomotive.js gibi bazı projeler camelCasedenetleyici dosyaları için kullanıyor . :-) Sadece bağlıdır. PascalCaseSınıf benzeri dosyalar için kullanma eğilimindeyim .
Mathieu Amiot

@yitsushi, deve (ve pascal) vaka adlandırma ile ilgili oldukça endişe uyandırıyor gibi görünüyor, eğer taşınabilir modüller oluşturmak istiyorsanız deve kasası kesinlikle kötü bir fikir görünüyor?
gumaflux

0

Node.js herhangi bir dosya adlandırma kuralını (hariç index.js) zorlamaz . Ve genel olarak Javascript dili de değil. Burada camelCase, tire ve alt çizgi öneren düzinelerce ileti dizisi bulabilirsiniz ve bunlardan herhangi biri mükemmel şekilde işe yarar. Bu size kalmış. Birini seçin ve ona bağlı kalın.


1
Aslında düğümün 'uyguladığı' bu değil, lütfen şunu okuyun: nodejs.org/api/modules.html#modules_folders_as_modules
moka

0

Bana göre: Eğer module.exports bir nesne ise, dosyalar için daha düşük deve durumunu kullanın, yani singleton modülü kastediyorum. Bu aynı zamanda JSON dosyaları için de geçerlidir, çünkü bunlar da tek tondur. Module.exports bir sınıf gibi davrandığı bir yapıcı işlevi döndürürse, üst deve durumunu kullanın.

Klasörler için kısa isimler kullanın. Birden fazla kelimeye ihtiyaç varsa, tüm platformlarda tutarlı bir şekilde çalışması için "-" ile birbirinden tamamen küçük harflerle ayrılmış olmasına izin verin.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.