PHP Coding Standards

Bayangkan Anda baru bergabung dengan sebuah tim dan membuka proyek PHP mereka: satu berkas memakai indentasi tab, berkas lain memakai spasi, dan nama method berganti-gaya antara getData(), get_data(), bahkan GetData(). Setiap kali membuka berkas baru, otak Anda harus menyesuaikan diri dengan “dialek” penulisnya sebelum bisa fokus ke logika. Coding standards adalah jawaban untuk masalah ini: sekumpulan kesepakatan tertulis tentang bagaimana kode ditulis agar seluruh tim menghasilkan kode yang terasa seperti ditulis oleh satu orang. Pada chapter ini kita akan membahas mengapa standar penting bagi tim, mengenal ekosistem PSR dari PHP-FIG, dan cara memulai adopsinya tanpa menciptakan aturan sendiri dari nol.

Mengapa Tim Membutuhkan Coding Standards #

Kode dibaca jauh lebih sering daripada ditulis. Setiap kali melakukan code review, menelusuri bug, atau menambah fitur, pengembang membaca kode yang sudah ada lebih lama daripada menulis kode baru. Standar gaya mempercepat proses membaca tersebut karena otak tidak perlu lagi mem-parsing variasi format yang tidak relevan dengan logika. Anggota tim baru pun bisa langsung produktif karena pola yang dilihat di satu modul berlaku sama di modul lain.

Standar juga meningkatkan kualitas code review. Tanpa kesepakatan, kolom komentar review mudah terkuras untuk hal-hal sepele seperti posisi kurung kurawal atau lebar indentasi. Fenomena debat panjang soal hal sepele ini sering disebut bikeshedding — energi review yang seharusnya dipakai memeriksa logika malah habis untuk memperdebatkan selera format. Dengan standar (apalagi jika diterapkan otomatis oleh formatter), diskusi sepele hilang dan review kembali fokus pada perilaku kode.

Perhatikan dua potongan kode berikut. Keduanya valid, keduanya menghasilkan output yang sama persis, tetapi keduanya berdiri di dua dunia keterbacaan yang berbeda:

<?php
function hitung($h,$q){$t=$h*$q;return $t-($t*0.1);}
echo hitung(50000,3)."\n";

Output yang Dihasilkan:

135000

Versi kedua menulis logika yang sama dengan mengikuti kesepakatan gaya:

<?php

function hitungTotalSetelahDiskon(int $hargaSatuan, int $jumlah)
{
    $subtotal = $hargaSatuan * $jumlah;
    $potonganDiskon = $subtotal * 0.1;

    return $subtotal - $potonganDiskon;
}

echo hitungTotalSetelahDiskon(50000, 3) . "\n";

Output yang Dihasilkan:

135000

Mari kita bedah versi kedua baris per baris:

1. Baris 3: nama fungsi hitungTotalSetelahDiskon memakai gaya camelCase dan langsung mengungkapkan maksudnya — menghitung total setelah dipotong diskon.
2. Baris 3: kedua parameter diberi type declaration int dan nama deskriptif ($hargaSatuan, $jumlah), bukan $h dan $q yang memaksa pembaca menebak.
3. Baris 4-5: variabel lokal $subtotal dan $potonganDiskon menamai setiap nilai antara, satu statement per baris, indentasi empat spasi.
4. Baris 7: return berdiri sendiri dengan baris kosong sebelumnya sehingga hasil fungsi terlihat jelas.

Mengenal PHP-FIG dan Ekosistem PSR #

Kabar baiknya: Anda tidak perlu mendefinisikan standar sendiri. Ekosistem PHP sudah punya PHP-FIG (Framework Interop Group), kelompok yang dibentuk pada 2009 oleh para pengembang framework dengan tujuan membuat komponen PHP saling kompatibel. Hasil kerjanya berupa dokumen bernama PSR (PHP Standards Recommendation). Setiap PSR punya status siklus hidup: accepted (diterima dan layak dipakai), deprecated (ditinggalkan), atau masih berupa draf.

Beberapa PSR yang paling sering Anda jumpai sehari-hari:

Dua chapter berikutnya membedah tuntas PSR-1/PSR-12 (gaya penulisan) dan PSR-4 (pemetaan berkas). PSR lain seperti PSR-3 dan PSR-7 akan muncul kembali saat Anda bekerja dengan logging dan HTTP di section-section selanjutnya.

Mengadopsi Standar yang Sudah Ada #

Godaan terbesar tim kecil adalah menulis standar sendiri dari nol — padahal membuat dan merawat panduan custom berbiaya mahal, dan hasilnya jarang lebih baik dari yang sudah ada. Praktik yang jauh lebih murah: adopsi PSR-12 sebagai dasar, lalu jalankan formatter otomatis seperti PHP CS Fixer atau PHP_CodeSniffer agar aturan ditegakkan mesin, bukan diserahkan pada kedisiplinan manusia. Aturan tambahan khas proyek (misalnya larangan fungsi tertentu) cukup ditambahkan sedikit demi sedikit.

Prinsip pentingnya: standar adalah soal kesepakatan, bukan keindahan mutlak. Aturan yang “kurang cantik” menurut Anda tetap menang jika seluruh tim mengikutinya, karena nilai utama standar ada pada prediktabilitas. Berdebat mengganti aturan baku demi selera pribadi justru mengulang bikeshedding yang ingin kita hilangkan. Cara praktis menjalankannya — hook git, script Composer, hingga pipeline CI — dibahas pada chapter Coding Standards di Section Testing dan Quality Assurance .

Code Style Bukan Arsitektur #

Terakhir, penting memisahkan dua hal yang sering dicampuradukkan. Code style adalah lapisan permukaan kode: penamaan, indentasi, posisi kurung, panjang baris. Arsitektur adalah struktur di baliknya: bagaimana lapisan-lapisan disusun, siapa bergantung pada siapa, di mana logika bisnis tinggal. Sebuah proyek bisa rapi mematuhi PSR-12 namun tetap sulit diubah karena class-classnya saling terikat kencang.

Alat format otomatis hanya bisa menjaga lapisan permukaan; lapisan struktural butuh prinsip desain yang kita bahas pada chapter Clean Code dan Refactoring di section ini, serta pada Section Design Patterns dan Prinsip. Memahami batas ini menyelamatkan Anda dari ekspektasi keliru bahwa “sudah pakai PSR-12, pasti kodenya sehat”.

Ringkasan #

Coding standards adalah kesepakatan yang membuat tim berbicara dalam satu bahasa: membaca lebih cepat, onboarding lebih mudah, dan review fokus pada logika. PHP-FIG menyediakan standar siap pakai melalui PSR, dan strategi terbaiknya adalah mengadopsi PSR-12 plus formatter otomatis alih-alih menciptakan aturan sendiri. Dengan memahami bahwa standar adalah soal kesepakatan — dan bahwa standar gaya berbeda dari arsitektur — kita siap membedah aturan konkretnya, mulai dari PSR-1 dan PSR-12 pada chapter berikutnya.

Referensi #

• PSR-1: Basic Coding Standard
• PSR-12: Extended Coding Style
• PHP The Right Way