CSS, JS ve HTML için kod inceleme yönergeleri


9

İnceleme CSS, JS ve HTML için yönergeler oluşturmam istendi. JS için kodlama yönergeleri olduğunu biliyorum ama HTML ve CSS hakkında hiçbir şey bilmiyorum. JS'yi incelemek için kesinlikle bu yönergeleri izleyeceğim ve onlardan bahsedeceğim. Peki ya CSS ve HTML? Mantıksal hatalar ve girinti sorunları dışında, işaretlemeyi veya CSS'yi incelerken kontrol etmem gereken belirli şeyler var mı?


1
Bu sadece bugün HN idi, başlamak için iyi bir yer olabilir. taitems.github.com/Front-End-Development-Guidelines
agradl

Yanıtlar:


5

Aranacak bazı şeyler:

  • Yapısal bilgiler uygun HTML etiketleri kullanılarak tanımlanıyor mu? H1- H6başlıklar, UL/ OLve LIlisteler vb. için?
  • Hiçbir miras HTML etiketleri (Are <b>, <i>, <center>, <font>) kullanılır?
  • Site mümkün olan en düşük miktarda biçimlendirme kullanıyor mu?
  • Stil bilgileri CSS dosyalarına harici mi?
  • Tüm Javascript harici mi? olay işleyicileri dahil mi?
  • CSS sınıf adları img-captionform ( bold-red) veya content ( pink-elephant) yerine sayfa ( ) içindeki işleve karşılık geliyor mu?
  • Görüntüler uygun biçimde mi (türe bağlı olarak PNG veya JPEG)?
  • Javascript kütüphanelerinin simge durumuna küçültülmüş versiyonları kullanılmış mı?
  • İsteğe bağlı olarak, yerel olarak geliştirilen tüm Javascript ve CSS dosyaları simge durumuna küçültülmüş mü?
  • HTML / CSS doğrulanıyor mu?
  • YSlow (veya benzeri) performansı kontrol etmek / optimize etmek için kullanıldı mı?
  • (çoğunlukla) [SEO] Siteye Javascript ile erişilebilir mi?
  • [SEO] En alakalı içerik HTML'nin üstünde mi yer alıyor?

Steve Saunders'ın kitabını daha hızlı web sitelerinde buldum. Oldukça yararlı ve sizin bahsettiğiniz bazı noktalar iyidir.
Kumar

0

HTML'de iyi bir stilin önemli unsurlarından biri aşamalı iyileştirmedir . Bu, HTML düzeninin CSS veya JavaScript olmasa bile iyi bir şekilde işleneceği anlamına gelir. Ardından, JS / CSS işlendikten sonra, daha iyi görünecektir (örneğin, eski stil HTML <select>açılır menüsü canlandırılacaktır).

Bu da müdahaleci olmayan işaretleme ile ilgilidir. <font style="color:red;font-size:16pt">Hello</font>Biri yerine kullanacaktı <div class="red-colored-big-fond">Hello</div>.

JavaScript ile aynı. <button onclick="javascript:alert('a');">Clickme</button>Biri yerine bir düğme sınıfı / kimliği belirtir ve JavaScript'ten hedefler. Ayrıca, biçimlendirme kodunuzun bakımını kolaylaştırır.


0

Görevi gerçekleştirmek için en az miktarda işaretlemenin kullanıldığını doğrulayın. İşaretlemenin semantik olduğundan da emin olun, bir etiket aynı şeyi yaptığında ve daha fazla bilgi verdiğinde kullanmayın. Açıklıkların blok elemanları yapılmadığını ve tam tersini doğrulayın.

Ayrıca, alex dolambaçlı bir şekilde büyük bir noktaya getiriyor. Kimsenin "kırmızı renkli-büyük-yazı tipi" gibi sınıf adları kullanmadığından emin olun, çünkü gerçek biri için konuşlandırıldıktan yaklaşık 20 saniye sonra küçük bir mavi yazı tipine geçecektir. Aslında bu CSS gördüm:

.arial12pt { font-family: Verdana; font-size: 8pt; }

İşaretlemenizdeki her şey, sayfanın nasıl göründüğünü değil, sayfanın ne olduğunu açıklamalıdır. Aşamalı geliştirme konusunda kesinlikle katılıyorum, ama yine dolambaçlı bir şekilde. Sayfanın CSS ile onsuz olduğu yere yakın bir yere bakma zorunluluğu yoktur. Aynı görünmelerini sağlamaya çalışmayın, çünkü sonuçta tablo-arazi ve spacer.gif'e döneceksiniz.


0

HTML ile ilgili olarak, her zaman dosyalarımda hiyerarşiler ve girinti için bir noktaya işaret ediyorum. Örneğin, bir sürü div varsa:

<div id="content">
   <div id="post">
     <div class="title">
       Blah Blah Title
     </div>
   </div>
</div>

Bu, mizanpajlar ve şablonlar oluşturan çoğu kişi için oldukça açık, ancak çoğu zaman, herhangi bir yapısal hiyerarşisi olmayan karmaşık HTML görmüyorum, bu da başka bir kişi için okumayı zorlaştırıyor. Sanırım daha çok CS geçmişinden geliyor, bu aklımda kalan bir şey. Aynı şey CSS için de geçerli. Diyelim ki bir div tasarlıyorsunuz:

#whatever{
    background-image: url('blah.gif');
    color: #FFF000;
}

Girinti, PHP / Ruby / Whatever gibi karışık başka bir dile alıştığınızda hızlı bir şekilde okumayı kolaylaştırır. Yine, en iyi nasıl çalıştığınıza bağlıdır, ancak diğerleri HTML'imi okuduğunda, onu gerçekten organize etmeyi seviyorum :).

Ayrıca, yukarıda belirtildiği gibi, özellikle tüylü olduğunda (diğer dillerdeki değişkenleri ve yöntemleri adlandırmak gibi) CSS sınıflarınızı ve kimliklerinizi ilgili adlarınız düzeninize adlandırmak her zaman harika bir fikirdir. Dikkat edilmesi gereken başka bir şey, marjların, dolguların ve diğer hizalama sorunlarının korkunç "tahmin ve kontrolü" dür. Sıklıkla kaçınmaya çalıştığım bir şey, kenar boşluklarıma ve dolgularıma negatif sayılar koymaktır. Düzeni kendiniz yapmadıysanız ve daha sonra geri dönüp değiştirmek isterseniz kafa karıştırıcı olabilir, elden geçirmeniz gerekebilir. Bence, güzel görünse bile, CSS'de hokey veya "kludgy" gibi bir şey denemek her zaman iyi bir fikirdir; CSS'nizi yeniden yapılandırmanız gerekse bile, bunu yapmanın genellikle daha iyi bir yolu vardır!


0

Javascript için her zaman JSLint ile doğrulamak istiyorum, JSLint kullanarak değil sadece deli olduğunu yakalar birçok hata düşünebilirsiniz.


0

Sevdiğim bu standartlar belgesine rastladım . Ayrıca ilerici geliştirme hakkında söylenenleri yankılayacağım. Genel olarak, bir başkası HTML / CSS yazıyorsa, daha sonra satırın aşağısına bakabilmeli ve işaretlemenin ne kadar kötü olmadığını hoş bir şekilde şaşırtmalı ve basit stil ayarlamalarını kolay ve verimli bir şekilde yapabilmelisiniz.

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.