Jika Anda peduli dengan kode itu sendiri, dan bagaimana kode itu ditulis, dan tidak hanya mementingkan pembuatan program yang berfungsi, ini berarti Anda ingin kode Anda bersih. Pengembang profesional menulis kode tidak hanya untuk komputer, tetapi juga untuk dirinya sendiri yang memenuhi kode ini di masa depan, dan untuk programmer lain. Kode yang Anda tulis tidak hilang selamanya di perut komputer. Itu hidup, berubah, dan jika itu ditulis dengan buruk, itu mungkin sangat mengganggu seseorang yang harus mengeditnya setelah Anda menulisnya. Ada kemungkinan bahwa Anda akan menjadi "seseorang" ini.

Berdasarkan ide-ide ini, kode bersih dapat didefinisikan sebagai kode yang ditulis sedemikian rupa sehingga menjelaskan dirinya sendiri. Kode ini dapat dengan mudah dipahami oleh orang-orang, akan mudah untuk memodifikasi atau memperluasnya.
Kode dan pertanyaan WTF
Inti dari pertanyaan WTF, seperti "WTF itu?" Datang ke kejutan dan dendam ekstrem. Dalam bahasa Rusia, perasaan ini dapat diungkapkan dengan pertanyaan "Apa-apaan ini?". "Sialan," tergantung pada situasinya, mungkin memberi jalan kepada sesuatu yang sama sekali tidak dapat dicetak. Berapa kali Anda pernah menambahkan kode seseorang dan mengajukan pertanyaan serupa?
Ketika bertanya pada diri sendiri pertanyaan WTF tentang kode orang lain, programmer bertanya pada diri sendiri apa itu (WTF itu?), Apa yang coba dilakukan oleh penulis kode (WTF yang Anda lakukan di sini?), Mengapa ini atau itu membangun hadir dalam kode (WTF adalah ini untuk?)
Berikut adalah gambar yang menurutnya satu-satunya indikator kualitas kode yang dapat diandalkan adalah jumlah pertanyaan WTF per menit.
Di sebelah kiri adalah kode yang baik. Di sebelah kanan itu burukTetapi serius, untuk membantu Anda mendengarkan kode bersih, kami mengutip Robert Martin, yang dikenal sebagai Paman Bob: βBahkan kode program yang buruk dapat bekerja. Namun, jika kode tidak "bersih," itu akan selalu mengganggu pengembangan proyek. "
Sekarang mari kita lihat beberapa pedoman praktis untuk menulis kode bersih. Kami akan menggunakan JavaScript di sini, tetapi rekomendasi ini dapat diterapkan untuk pengembangan dalam bahasa lain.
1. Pemeriksaan kesetaraan yang ketat
Cobalah untuk menggunakan
===
daripada
==
.
2. Variabel
Beri nama variabel sehingga nama mereka akan mengungkapkan esensi mereka, peran mereka dalam program. Dengan pendekatan ini, akan lebih mudah untuk mencarinya dalam kode, dan siapa pun yang melihat kode ini dapat lebih mudah memahami makna tindakan yang mereka lakukan.
Buruk:
let daysSLV = 10; let y = new Date().getFullYear(); let ok; if (user.age > 30) { ok = true; }
Baik:
const MAX_AGE = 30; let daysSinceLastVisit = 10; let currentYear = new Date().getFullYear(); ... const isUserOlderThanAllowed = user.age > MAX_AGE;
Tidak perlu menambahkan kata-kata tambahan ke nama variabel yang tidak diperlukan.
Buruk:
let nameValue; let theProduct;
Baik:
let name; let product;
Anda tidak boleh memaksa seseorang yang membaca kode harus mengingat lingkungan di mana variabel dinyatakan.
Buruk:
const users = ["John", "Marco", "Peter"]; users.forEach(u => { doSomething(); doSomethingElse();
Baik:
const users = ["John", "Marco", "Peter"]; users.forEach(user => { doSomething(); doSomethingElse();
Anda tidak perlu memberikan nama variabel dengan informasi yang berlebihan tentang konteks di mana mereka digunakan.
Buruk:
const user = { userName: "John", userSurname: "Doe", userAge: "28" }; ... user.userName;
Baik:
const user = { name: "John", surname: "Doe", age: "28" }; ... user.name;
3. Fungsi
Gunakan nama deskriptif panjang untuk fungsi. Mengingat bahwa suatu fungsi adalah deskripsi tindakan tertentu, namanya harus berupa kata kerja atau frasa yang sepenuhnya menjelaskan esensi dari fungsi tersebut. Nama-nama argumen harus dipilih sehingga mereka cukup menggambarkan data yang mereka wakili. Nama fungsi harus memberi tahu pembaca kode apa sebenarnya fungsi ini lakukan.
Buruk:
function notif(user) {
Baik:
function notifyUser(emailAddress) {
Hindari menggunakan daftar panjang argumen. Idealnya, fungsi harus memiliki dua atau lebih sedikit argumen. Semakin sedikit argumen yang dimiliki fungsi, semakin mudah untuk mengujinya.
Buruk:
function getUsers(fields, fromDate, toDate) {
Baik:
function getUsers({ fields, fromDate, toDate }) {
Gunakan argumen default, berikan mereka preferensi daripada konstruksi bersyarat.
Buruk:
function createShape(type) { const shapeType = type || "cube";
Baik:
function createShape(type = "cube") {
Suatu fungsi harus menyelesaikan satu masalah. Berusaha keras untuk memastikan bahwa satu fungsi tidak melakukan banyak tindakan.
Buruk:
function notifyUsers(users) { users.forEach(user => { const userRecord = database.lookup(user); if (userRecord.isVerified()) { notify(user); } }); }
Baik:
function notifyVerifiedUsers(users) { users.filter(isUserVerified).forEach(notify); } function isUserVerified(user) { const userRecord = database.lookup(user); return userRecord.isVerified(); }
Gunakan
Object.assign
untuk menetapkan properti objek secara default.
Buruk:
const shapeConfig = { type: "cube", width: 200, height: null }; function createShape(config) { config.type = config.type || "cube"; config.width = config.width || 250; config.height = config. height || 250; } createShape(shapeConfig);
Baik:
const shapeConfig = { type: "cube", width: 200
Jangan gunakan bendera sebagai parameter. Penggunaannya berarti bahwa fungsi melakukan lebih banyak tindakan daripada yang seharusnya dilakukan.
Buruk:
function createFile(name, isPublic) { if (isPublic) { fs.create(`./public/${name}`); } else { fs.create(name); } }
Baik:
function createFile(name) { fs.create(name); } function createPublicFile(name) { createFile(`./public/${name}`); }
Jangan mencemari ruang lingkup global. Jika Anda perlu memperluas objek yang ada, gunakan kelas ES dan mekanisme pewarisan alih-alih membuat fungsi dalam rantai prototipe objek standar.
Buruk:
Array.prototype.myFunc = function myFunc() {
Baik:
class SuperArray extends Array { myFunc() {
4. Konstruksi bersyarat
Cobalah untuk tidak menyebutkan variabel boolean sehingga ada negasi dalam nama mereka. Hal yang sama berlaku untuk fungsi yang mengembalikan nilai boolean. Menggunakan entitas tersebut dalam konstruksi bersyarat membuatnya sulit untuk membaca kode.
Buruk:
function isUserNotBlocked(user) {
Baik:
function isUserBlocked(user) {
Gunakan formulir singkat untuk konstruksi bersyarat. Mungkin rekomendasi ini mungkin tampak sepele, tetapi perlu disebutkan. Gunakan pendekatan ini hanya untuk variabel logis, dan jika Anda yakin bahwa nilai variabel tidak akan
undefined
atau
null
.
Buruk:
if (isValid === true) {
Baik:
if (isValid) {
Hindari konstruksi logis sedapat mungkin. Gunakan polimorfisme dan warisan sebagai gantinya.
Buruk:
class Car {
Baik:
class Car {
5. kelas ES
Kelas muncul dalam JavaScript relatif baru. Mereka dapat disebut gula sintaksis. Apa yang terjadi ketika menggunakan kelas didasarkan pada prototipe objek, seperti sebelumnya. Tetapi kode yang menggunakan kelas terlihat berbeda. Secara umum, jika memungkinkan, kelas ES harus lebih disukai daripada fungsi konstruktor biasa.
Buruk:
const Person = function(name) { if (!(this instanceof Person)) { throw new Error("Instantiate Person with `new` keyword"); } this.name = name; }; Person.prototype.sayHello = function sayHello() { }; const Student = function(name, school) { if (!(this instanceof Student)) { throw new Error("Instantiate Student with `new` keyword"); } Person.call(this, name); this.school = school; }; Student.prototype = Object.create(Person.prototype); Student.prototype.constructor = Student; Student.prototype.printSchoolName = function printSchoolName() { };
Baik:
class Person { constructor(name) { this.name = name; } sayHello() { } } class Student extends Person { constructor(name, school) { super(name); this.school = school; } printSchoolName() { } }
Atur metode sehingga mereka bisa dirantai. Banyak perpustakaan menggunakan pola ini, seperti jQuery dan Lodash. Akibatnya, kode Anda akan lebih padat daripada tanpa menggunakan pola ini. Intinya adalah bahwa pada akhir setiap fungsi kelas Anda perlu mengembalikan
this
. Ini akan memungkinkan Anda untuk menggabungkan panggilan fungsi-fungsi tersebut ke dalam rantai.
Buruk:
class Person { constructor(name) { this.name = name; } setSurname(surname) { this.surname = surname; } setAge(age) { this.age = age; } save() { console.log(this.name, this.surname, this.age); } } const person = new Person("John"); person.setSurname("Doe"); person.setAge(29); person.save();
Baik:
class Person { constructor(name) { this.name = name; } setSurname(surname) { this.surname = surname;
6. Apa yang lebih baik tidak dilakukan
Siapa pun yang ingin kode-nya bersih harus berusaha untuk tidak mengulanginya. Intinya adalah untuk menghindari situasi di mana Anda harus menulis kode yang sama. Selain itu, Anda tidak perlu meninggalkan fungsi dan fragmen program yang tidak digunakan yang tidak pernah dieksekusi di basis kode.
Kode duplikat dapat muncul karena berbagai alasan. Sebagai contoh, sebuah proyek mungkin memiliki sepasang fungsi yang sedikit berbeda. Sifat perbedaan ini atau kurangnya waktu memaksa programmer, misalnya, untuk membuat dua fungsi independen yang berisi kode yang hampir sama. Dalam situasi seperti itu, menyingkirkan kode duplikat adalah mengabstraksi perbedaan dan bekerja dengannya di tingkat yang lebih tinggi.
Sekarang mari kita bicara tentang kode yang tidak digunakan. Ini adalah kode yang ada dalam basis kode tetapi tidak melakukan apa pun. Ini terjadi, misalnya, ketika pada tahap pengembangan tertentu diputuskan bahwa tidak ada lagi arti dalam fragmen tertentu dari program. Untuk menghilangkan fragmen kode seperti itu, Anda perlu meninjau basis kode dengan hati-hati dan menghapusnya. Cara termudah untuk menyingkirkan kode tersebut pada saat diputuskan tidak diperlukan lagi. Kemudian, Anda bisa melupakan untuk apa ia digunakan. Ini akan sangat mempersulit pertarungan dengannya.
Jika Anda menunda perang melawan kode yang tidak perlu, program akan menyerupai apa yang ditunjukkan pada gambar berikut.
Terkadang kode saya terlihat seperti balkon ini. Saya tidak tahu tugas apa yang sedang dia selesaikan, tetapi saya takut untuk menyingkirkannya.Ringkasan
Di sini kita telah membahas hanya sebagian kecil dari tindakan yang dapat diambil untuk memperbaiki kode. Penulis materi ini percaya bahwa prinsip-prinsip yang dibahas di sini sering dilupakan. Programmer mencoba mengikuti mereka, tetapi, karena berbagai alasan, tidak selalu berhasil dalam hal ini. Mungkin, di awal proyek, semua orang ingat pentingnya kode bersih, sebagai hasilnya, programnya rapi. Kemudian, ketika tenggat waktu semakin dekat, mereka sering lupa tentang kemurnian kode, hanya memperhatikan apa yang ditandai sebagai TODO atau REFACTOR. Pada saat-saat seperti itu, pelanggan proyek akan mendesak agar proyek diselesaikan tepat waktu, dan bukan bahwa kodenya bersih.
Cukup sering, kami menerbitkan materi tentang masalah penulisan kode JavaScript berkualitas tinggi. Jika Anda tertarik dengan topik ini, berikut adalah beberapa tautan.
Kami berharap apa yang Anda pelajari dengan membaca artikel ini dan apa yang dapat Anda temukan di publikasi lain akan membantu Anda dalam pencarian Anda untuk menulis kode JavaScript yang bersih.
Pembaca yang budiman! Pernahkah Anda mengajukan pertanyaan WTF saat membaca kode orang lain?

