Kontrak: Sisi praktis semantik

() translation by (you can also view the original English article)

Kita semua menyadari bahwa kita harus menulis kode semantik. Mungkin, Anda bahkan menggunakan <section> atau <em> dengan benar, dan merasa cukup baik tentang diri Anda. Tapi, apakah Anda juga mempertimbangkan kontrak tersirat yang ada saat Anda kode?

Mari kita bayangkan bahwa pelanggan meminta tautan teks, "Lihat Lebih Banyak,"yang akan mengungkapkan teks tambahan pada halaman. <a href="#">see more</a> dengan penangan klik harus bekerja dengan sempurna, bukan? Hei, ini terlihat dan berfungsi sesuai permintaan!

Tidak, itu tidak akan selalu berfungsi dengan benar, karena melanggar kontrak antara Anda dan browser. Secara khusus, saya mengacu pada yang mengatakan atribut href harus memiliki nilai yang merupakan URL yang valid.

Ada masalah praktis yang dapat timbul ketika melanggar kontrak, dan mereka banyak alasan yang lebih baik untuk menulis kode semantik daripada hal-hal yang Anda biasanya pikirkan ketika Anda mendengar istilah, "semantik".

Argumen populer untuk kode semantik

Namun, ada alasan yang lebih praktis untuk peduli semantik: kontrak.

Jika Anda meminta seorang pengembang rata-rata nilai apa kode semantik, Anda mungkin akan mendengar sesuatu di sepanjang baris:

Itu membantu Penyandang Cacat
Dengan baik menggambarkan kode membuatnya lebih mudah untuk mesin untuk menafsirkan

Keduanya, sayangnya, sangat mudah untuk mengabaikan. "Orang-orang buta dan robot tidak target audience" terlalu sederhana tanggapan, terlepas dari bagaimana sesat atau bodoh mungkin.

Dalam kasus lain, Anda bahkan mungkin mendengar siklus penalaran, seperti "kode non-semantik buruk, karena itu tidak bermakna." Ini adalah gagasan populer ke titik bahwa parodi di atasnya sudah bermunculan di seluruh web!

Namun, ada alasan yang lebih praktis untuk peduli semantik: kontrak.

Penggunaan kontrak

Setiap kali Anda menggunakan beberapa fungsi yang disediakan oleh vendor browser, bahasa pemrograman Anda atau API, Anda mengandalkan kontrak.

Di satu sisi kontrak ada penyedia fungsionalitas. Misalnya, bila Anda menggunakan <a>tag, browser pengembang menjanjikan kepada Anda bahwa mereka akan menyediakan cara yang mudah untuk pengguna aplikasi Anda untuk menavigasi ke URL tertentu.</a>

Seperti biasa, namun, ada sisi lain dari perjanjian tersebut. Pelaksana fungsi berjanji untuk menggunakan fungsi seperti yang telah ditetapkan. Segera setelah dia menyalahgunakan fungsi ini, semua taruhan adalah off - menuju kegagalan potensial.

Browser fungsi kontrak

Mari kita kembali ke "Lihat More" contoh dari sebelumnya. Di hari-hari awal JavaScript, pengembang akan menulis JavaScript mereka menggunakan protokol palsu, javascript:

1	<a href="javascript:ShowMore()">See More</a>

Relatif cepat, mereka mulai menyadari bahwa pendekatan ini memiliki setidaknya satu praktis Cacat: kode JavaScript dipajangkan di status bar dari browser, yang tidak terlihat profesional. Jawaban untuk dilema ini adalah untuk memindahkan kode ke handler onclick, dan mengganti href atribut dengan pengidentifikasi kosong hash, seperti:

1	<a href="#" onclick="ShowMore();return false;">See More</a>

Tentu saja, ini tidak menyelesaikan segala sesuatu. Jika ShowMore memiliki kesalahan, kembali palsu tidak pernah disebut, dan halaman menggulir ke atas - perilaku pasti tidak diinginkan.

Hari ini, pengembang memisahkan mereka HTML dan JavaScript dan menggunakan teknik pencegahan tepat acara:

1	<a href="#" class="show-more">See More</a>

1	$('a.show-more').on('click', function(event) {
2	event.preventDefault();
3	ShowMore();
4	});

Tapi coba tebak? Masih ada banyak masalah dengan pendekatan ini: Buka di tab baru, bookmark atau menyalin link tidak bekerja seperti pengguna mungkin mengharapkan (terutama, jika ada <base> tag pada halaman), yang hasil dalam kebingungan, dan mungkin, kehilangan pelanggan.

Perhatikan bagaimana semua masalah yang digambarkan sejauh ini muncul dari satu kenyataan. Pengembang telah melanggar mereka bagian dari kontrak dengan pembuat browser: href atribut harus berisi URL yang benar, tetapi, sebaliknya, pengembang telah memasukkan semua jenis sampah.

Jika kita mencoba untuk menyesuaikan diri dengan kontrak kami, kita harus bertanya kepada diri sendiri: "Mengapa tidak kontrak memungkinkan kita untuk melakukan apa yang kita butuhkan?" Jawabannya sederhana: kita menyalahgunakan <a>tag. Kami hanya menggunakannya, karena kita ingin teks "Lihat More" untuk muncul dan berperilaku seperti link.</a> Namun, ketika kita menggunakan kata-kata, seperti "Lihat" dan "muncul," Apakah ini tidak domain CSS? Bukankah ini "Lihat More" link, pada kenyataannya, hanya sebuah tombol? Ini mudah untuk menerapkan:

1	<button type="button" class="link-style show-more">See More</button>

1	$('button.show-more').on('click', ShowMore);

a, .link-style {
    color: @your-shade-of-blue;
    text-decoration: underline;
}
.link-style {
    font: inherit;
    background: none;
    border: none;
    cursor: pointer;
}

Terlepas dari berapa banyak cara-cara baru untuk berinteraksi dengan link ditambahkan ke masa depan iterasi dari browser, pendekatan ini akan terus bekerja, karena kita tidak melanggar kontrak apapun dengan browser. Kami menggunakan elemen untuk menyampaikan makna mereka, dan, daripada terus-menerus bekerja di sekitar masalah baru, kita tahu bahwa browser akan memperlakukan ini dengan benar, karena ia mengerti apa yang kita inginkan.

Tentu saja, itu mungkin membutuhkan beberapa baris tambahan CSS reset beberapa tombol default styling. It's worth it! Jangan menjadi malas.

Spesifikasi sebagai kontrak

... mereka yang tahu semantik, dan secara sadar mengabaikannya.

Pada tahun 2005, sebagian besar komunitas pengembangan web belajar dengan cara yang keras yang mengabaikan persyaratan HTTP buruk. Google Web Accelerator yang baru dirilis akan mengambil URL pada halaman untuk meminimalkan waktu tunggu pengguna dalam sebuah klik.

Ini rusak malapetaka di aplikasi, yang mengabaikan HTTP, dan menempatkan merusak operasi di balik link sederhana. Dan ada banyak aplikasi tersebut.

Masalahnya tidak tinggal di tangan para pengembang yang tidak mengerti semantik metode HTTP. Tidak, masalah datang dari orang-orang yang Tahukah semantik, sengaja mengabaikan mereka dan tidak berbagi pengetahuan.

Kontrak Pemeliharaan

Kode yang membingungkan itu buruk!

Kontrak ini juga ada antara pengembang. Setiap kali Anda menulis baris kode, Anda membuat janji masa depan pengembang itu terjadi persis apa yang tampaknya untuk melakukan. Dengan kata lain, membingungkan kode buruk!

Misalnya, menggunakan fungsi penyaringan (seperti filter dengan Python) untuk mengulang melalui item tidak benar, karena ada kontrak tersirat bahwa penyaringan fungsi hanya mengubah daftar, tanpa efek samping:

def show(item):
    print(item)

fruits = ['orange', 'apple', 'lemon']

filter(show, fruits)  # Incorrect usage of filter

Sebaliknya, gunakan eksplisit mengulang melalui daftar:

def show(item):
    print(item)

fruits = ['orange', 'apple', 'lemon']

for fruit in fruits:
    show(fruit)

Di sisi lain, jika Anda dapat mengandalkan kontrak, itu, sebagai akibatnya, memungkinkan Anda untuk memperjelas kode Anda. Misalnya, menggunakan array_filter bukan untuk loop di PHP untuk item filter memungkinkan pengembang lain untuk memahami apa yang terjadi setelah sekilas tunggal:

1	$incomes = [20, 15, -7, 19];
2	$profits = array_filter($incomes, function($i){
3	return $i > 0;
4	});

Bandingkan potongan di atas menggunakan untuk loop:

1	$incomes = [20, 15, -7, 19];
2	$profits = [];
3
4	foreach ($incomes as $i) {
5	if ($i > 0) {
6	$profits[] = $i;
7	}
8	}

Versi kedua lebih buruk, tidak hanya karena itu lebih lama, tetapi juga karena array_filter menyediakan harapan. Hal ini jelas $profits yang merupakan bagian dari $incomes. Ada tidak ada konvensi tersebut dengan generik untuk loop, yang menjelaskan mengapa kami tidak membuat asumsi, tanpa pertama memecahkan internal loop.

Menulis kode semantik benar

Bagaimana Anda membedakan antara kode yang dan semantik yang tidak? Bagaimana Apakah Anda memperhatikan kontrak ini? Untuk sebagian besar, hanya bertanya pada diri sendiri pertanyaan harus cukup.

Tag HTML

"Saya menggunakan tag <a>dan saya perlu untuk memasukkan sesuatu ke dalam sebuah href atribut. href menyimpan tujuan sasaran link. Jadi mana Apakah tag <a>saya link ke?" Nowhere? Yah, aku dapat kemudian menyimpulkan bahwa aku mungkin am menyalahgunakan tag ini.</a> </a>

Fungsi bernama

"Perlu mencetak isi daftar saya dalam fungsi filter. Adalah mencetak item bagian dari proses penyaringan?" Tidak benar-benar. Itu berarti saya 'm menyalahgunakan filter.

Fungsi yang melakukan terlalu banyak

"Saya sedang menulis sebuah getFoo metode, dan perlu menambahkan beberapa modifikasi kode di dalamnya. Memodifikasi negara akal sebagai bagian dari mendapatkan foo? Siapa pun yang hanya ingin mendapatkan foo harapkan bahwa sesuatu terjadi?" Mungkin tidak!

Keprihatinan pemisahan

"Saya ingin menambahkan beberapa JavaScript dalam atribut onclick HTML. Apakah ini benar?" File Anda memodifikasi .html, tepat? Sebaliknya, tempat JavaScript dan CSS dalam .js dan .css file, masing-masing. Selalu.

Tentu saja, dalam banyak kasus, beberapa pengetahuan tambahan mungkin diperlukan untuk menilai situasi dengan benar. Apa yang paling penting adalah untuk mulai berpikir tentang hal ini, dan untuk menghindari prinsip "(kinda) cara kerjanya, sehingga cukup baik." Sebaliknya, selalu bertanya kepada diri sendiri, "apa kode saya menulis benar-benar berarti?"

Kesimpulan

Melanggar kontrak menjamin bahwa kerjasama akan istirahat.

Kerjasama selalu tergantung pada usaha dari kedua belah pihak. Sebagian besar pengembangan perangkat lunak mengurangi Kerjasama: kerjasama antara hardware produsen, programmer sistem, browser pengembang, Perpustakaan penulis, pengembang website, dan banyak orang lain. Melanggar kontrak menjamin bahwa kerjasama akan istirahat.

Kode semantik adalah satu kontrak tersebut. Peduli tentang hal itu untuk kebaikan Anda sendiri!

Catatan kaki

Semantik: Istilah "semantik" sering disalahpahami. Dalam konteks artikel ini, saya menggunakan istilah untuk membedakan arti dari kode dari hasil menghasilkan kode. Sebagai contoh, makna semantik dari <a>tag adalah representasi dari link, sementara sederhana, praktis makna itu diklik, digarisbawahi teks.</a>

Tegasnya, kosong fragmen identifier # mungkin dianggap berlaku dalam konteks ini. Teknis ini, namun, ketinggalan titik saya membuat dalam artikel.