Varlıklar için adlandırma kuralı (resimler, css, js)?

Hala web projelerimde kullanılan resimler, js ve css dosyaları gibi varlıklar için iyi bir adlandırma kuralı bulmakta zorlanıyorum.

Yani benim akımım:

CSS: style-{name}.css
örnekler: style-main.css, style-no_flash.css, style-print.cssvb

JS: script-{name}.js
Örnekler: script-main.js, script-nav.jsvs.

Görseller: {imageType}-{name}.{imageExtension}
{imageType} bunlardan herhangi biri

• simge (ör. yardım içeriği için soru işareti simgesi)
• img (ör. <img />öğe aracılığıyla eklenen bir başlık resmi )
• düğmesi (ör. grafiksel gönder düğmesi)
• bg (resim css'de arka plan resmi olarak kullanılır)
• hareketli grafik (resim, css'de arka plan resmi olarak kullanılır ve birden çok "sürüm" içerir)

Örnek-isimler olacaktır: icon-help.gif, img-logo.gif, sprite-main_headlines.jpg, bg-gradient.gifvb

Peki, ne düşünüyorsunuz ve adlandırma kuralınız nedir?

CSS dosyalarını bir klasöre yerleştiriyorum css, Javascript içine js, görüntüleri içine images, ... Uygun gördüğünüz şekilde alt klasörler ekleyin. Ayrı dosyalar düzeyinde herhangi bir adlandırma kuralına gerek yoktur.

Ben ön uç geliştiriciler bir çok uzaklaştığını fark ettik cssve jslehine stylesve scriptsdiğer gibi orada şeyler, genellikle olduğundan .less, .stylve .sassbazıları için, hem de, .coffee. Gerçek şu ki, klasör organizasyonu seçiminizde belirli teknoloji seçimlerini kullanmak, herkes yapsa bile kötü bir fikirdir. Bu saygın geliştiricilerden gördüğüm standardı kullanmaya devam edeceğim:

• src/html
• src/images
• src/styles
• src/styles/fonts
• src/scripts

Ve varış noktaları, inşa destettikleri şeye bağlı olarak bazen ön ekli eşdeğerler oluşturur:

• ./
• images
• styles
• styles/fonts
• scripts

Bu, tüm dosyaları bir araya getirmek isteyenlerin (bir srcdizini bölmek yerine ) bunu korumasına ve patlak verenler için her şeyi net bir şekilde ilişkilendirmesine izin verir.

Aslında biraz daha ileri gidiyorum ve

• scripts/before
• scripts/after

Hangileri ikiye bölünür main-before.min.jsve main-after.min.jskomut dosyaları, biri başlık için (örneğin, temel unsurları olan normalizeve modernizrerken çalışması gereken) ve aftervücuttaki son şey için javascript bekleyebilir. Bunlar, Google'ın ana sayfası gibi okumak için tasarlanmamıştır.

Derleme kurallarında dikkate alınan belirli bir önbellek yönetimi yaklaşımı nedeniyle küçültülmesi ve tek başına bağlı bırakılması mantıklı olan komut dosyaları ve stil sayfaları varsa.

Bu günlerde, yutkunma veya homurtu gibi bir tür inşa süreci kullanmıyorsanız , muhtemelen düşünmeniz gereken mobil merkezli performans hedeflerinin çoğuna ulaşmıyorsunuzdur.

/Varlıklar/
  / Css
  /Görüntüler
  / Javascript (veya Script)
    / Küçültülmüş
    /Kaynak

Gördüğüm en iyi yapı ve tercih ettiğim yapı. Klasörlerle, CSS vb. Nizin önüne açıklayıcı adlar koymanıza gerek yoktur.

Css'in çok sayıda arka plan görüntüsü tanımlayabileceği büyük siteler için, bu varlıklar için bir dosya adlandırma kuralı, daha sonra değişiklik yapmak için gerçekten kullanışlıdır.

Örneğin:

[component].[function-description].[filetype]

footer.bkg-image.png
footer.copyright-gradient.png

Öğe türünü eklemeyi de tartıştık, ancak bunun ne kadar yararlı olduğundan ve gelecekteki gerekli değişiklikler için yanıltıcı olabileceğinden emin değilim:

[component].[element]-[function-description].[filetype]
footer.div-bkg-image.png
footer.p-copyright-gradient.png

Şöyle adlandırabilirsiniz:

/ assets / css / - CSS dosyaları için

/ assets / font / - Yazı tipi dosyaları için. (Çoğunlukla kullanılabilir yazı tiplerini aramak için google yazı tiplerine gidebilirsiniz.)

/ assets / images / - Görüntüler dosyaları için.

/ assets / scripts / veya / assets / js / - JavaScript dosyaları için.

/ assets / media / - Video ve diğerleri için. Dosyalar.

Ayrıca "varlıklar" ı "kaynak" veya "dosyalar" klasör adıyla değiştirebilir ve alt klasörlerinin adını koruyabilirsiniz. Bunun gibi bir sipariş klasörü yapısına sahip olmak çok önemli değil, tek önemli olan, dosyalarınızı formatına göre düzenlemeniz gerektiğidir. CSS dosyaları için "/ css /" veya Resim dosyaları için "/ images /" klasörü oluşturmak gibi.

Birincisi, klasörler halinde bölmek: css, js, img.

Siteniz bileşen olan js ve css dosyalarını içerebileceğinden, css ve js içinde dosyaların önüne proje adı ekliyorum, bu da dosyaların sitenize özel nerede olduğunu veya eklentilerle ilgili olduğunu netleştirir.

css/mysite.main.css css/mysite.main.js

Diğer dosyalar şöyle olabilir

js/jquery-1.6.1.js js/jquery.validate.js

Son olarak görüntüler kullanımlarına göre bölünmüştür.

• img/btn/submit.png düğme
• img/lgo/mysite-logo.png bir logo
• img/bkg/header.gif arka plan
• img/dcl/top-left-widget.jpg bir çıkartma öğesi
• img/con/portait-of-something.jpg bir içerik resmi

100'den fazla olabileceği ve kolayca tamamen karıştırılıp kafa karıştırıcı şekilde adlandırılabileceği için görüntüleri düzenli tutmak önemlidir.

Smdrager'ın önerdiği gibi genel herhangi bir şeyden kaçınma eğilimindeyim. "mysite.main.css" hiçbir şey ifade etmiyor.

"Mysite" nedir ?? Üzerinde çalıştığım bu mu? Eğer öyleyse, o zaman gerçekten apaçık, ama şimdiden ne olabileceğini ve bu kadar açıksa beni düşündürüyor!

"Ana" nedir? "Ana" kelimesinin, kodlayıcıların o css dosyasında ne olduğuna dair bilgisi dışında bir tanımı yoktur.

Bazı senaryolarda sorun olmasa da, "top" veya "left" gibi adlardan da kaçının: "top-nav.css" veya "top-main-logo.png".
Sonunda aynı şeyi başka bir yerde kullanmak isteyebilirsiniz ve altbilgiye veya "top-banner.png" adlı ana sayfa içeriğine bir resim koymak çok kafa karıştırıcıdır!

Verilen dosyada css'nin ne olduğunu tasvir etmek için iyi bir adlandırma kuralına izin vermek için çok sayıda stil sayfasına sahip olmakla ilgili herhangi bir sorun görmüyorum.
Kaçı tamamen sitenin boyutuna ve işlevlerinin ne olduğuna ve sitede kaç farklı blok olduğuna bağlıdır.

Css dosya adlarında "CSS" veya "STYLE" belirtmeniz gerektiğini sanmıyorum, çünkü aslında "css" veya "styles" klasöründe ve bir uzantısı var .cssve bu dosyalar sadece her zaman çağrıldığı için içinde <head>bölgede, oldukça net bir şekilde ne olduklarını biliyoruz.

Bununla birlikte, bunu kütüphane, JS ve yapılandırma (vb.) Dosyalarıyla yapıyorum. örneğin libSomeLibrary.php veya JSSomeScript.php. PHP ve JS dosyaları diğer dosyalar içinde çeşitli alanlarda yer aldığından veya kullanıldığından ve dosyanın adında asıl amacının ne olduğu hakkında bilgi sahibi olmak yararlıdır.

Örneğin: Dosya adını görmek require('libContactFormValidation.php');faydalıdır. Bunun bir kitaplık dosyası (lib) olduğunu ve adından ne yaptığını biliyorum.

Görüntü klasörleri için genellikle images/content-images/ve var images/style-images/. Daha fazla ayrılık olması gerektiğini düşünmüyorum ama yine projeye bağlı.

Daha sonra her bir görsel ne olduğuna göre isimlendirilecek ve yine dosya adı içinde bir görsel olarak dosyanın tanımlanmasına gerek olmadığını düşünüyorum. Boyutlar, özellikle resimlerin farklı boyutları olduğunda yararlı olabilir.

site-logo-150x150.png
site-logo-35x35.png
shop-checkout-button-40x40.png
shop-remove-item-20x20.png
vb.

İzlenmesi gereken iyi bir kural şudur: Dosyalara yeni bir geliştirici gelirse, saatlerce kafalarını kaşıyarak otururlar mı, yoksa şeylerin ne yaptığını anlayıp biraz araştırma yapmaya mı ihtiyaç duyarlar (ki bu kaçınılmaz)?

Bununla birlikte, bunun gibi herhangi bir şey olduğu gibi, uyulması gereken en önemli kurallardan biri de sürekliliktir !
Tüm adlandırma kurallarınızda aynı mantığı ve kalıpları izlediğinizden emin olun!
Basit css dosya adlarından PHP kitaplık dosyalarına, veritabanı tablosu ve sütun adlarına.

Bu eski bir sorudur, ancak yine de geçerlidir.

Şu anki tavsiyem şu satırlardaki bir şeyle gitmek:

• varlıklar (veya varlıklar-web veya varlıklar-www); bu, istemci (tarayıcı) tarafından kullanılan statik içerik için tasarlanmıştır
  • veri; bazı xml dosyaları ve diğer şeyler
  • yazı tipleri
  • Görüntüler
  • medya
  • stilleri
  • Kodlar
  • lib (veya 3. taraf); bu, sizin yapmadığınız veya değiştirmediğiniz kodlar için tasarlanmıştır, kitaplıkları aldığınız anda
  • lib modlu (veya üçüncü taraf tarafından değiştirilmiş); bu, değiştirmeniz beklenmeyen ancak kitaplık sağlayıcı tarafından yayınlanırken bir geçici çözüm / düzeltme uygulamak gibi yapmanız gereken kod için tasarlanmıştır
• inc (veya varlıklar-sunucu veya varlıklar-yerel); bu, PHP gibi dillerdeki kitaplıklar veya bash dosyaları gibi sunucu betikleri gibi istemci tarafından kullanılmayan, sunucu tarafında kullanılan içerik için tasarlanmıştır.
  • yazı tipleri
  • lib
  • lib modlu

Her zamanki gibi kalın harflerle işaretledim, diğerleri olağan içerik değil.

Ana bölümün nedeni, gelecekte güvenlik nedenleriyle web varlıklarını bir CDN'den sunucuya sunmaya veya sunucu varlıklarına istemci erişimini kısıtlamaya karar verebilmenizdir.

Kitaplık dizinlerinin içinde, örneğin kitaplıklar hakkında açıklayıcı olmak için kullanıyorum.

• lib
  • jquery.com
    • jQuery
      • vX.YZ
  • github
    • [yol]
      • [kitaplık / proje adı]
        • vX.YZ (sürüm)

böylece, kodu bozmadan kitaplığı yenisiyle değiştirebilir, ayrıca siz de dahil olmak üzere gelecekteki kod bakıcılarının kitaplığı bulmasına ve güncellemesine veya destek almasına izin verebilirsiniz.

Ayrıca, içindeki içeriği kullanımına göre düzenlemekten çekinmeyin, bu nedenle bazı projelerde resimler / logolar ve resimler / simgeler beklenen dizinlerdir.

Bir yan not olarak, varlıkların adı anlamlıdır, sadece orada kaynaklarımız olduğu anlamına gelmez, aynı zamanda oradaki kaynaklar proje için değerli olmalı ve ölü ağırlık olmamalıdır.

BBC'nin web geliştirme ile ilgili tonlarca standardı vardır.

Standartları CSS dosyaları için oldukça basittir:

http://www.bbc.co.uk/guidelines/futuremedia/technical/css.shtml

Ana sitelerinde yararlı bir şeyler bulabilirsin:

http://www.bbc.co.uk/guidelines/futuremedia/