Post

Some PSR That You Need To Know

Seorang developer, jarang sekali ditemui melakukan suatu yang seragam dalam penulisan code. Semua mengikuti naming convention dan coding style masing - masing.

Sejatinya, standar dalam menuliskan code adalah faktor yang sangat penting untuk mencapai kualitas kode yang tinggi. Common visual styles, naming conventions, dan pengaturan teknis lainnya memungkinkan kita untuk menghasilkan kumpulan code yang bersifat homogen. Sehingga code - code tersebut mudah dibaca dan mudah di pelihara.

Dalam article ini, akan dibahas beberapa standard yang umum sering digunakan.

PSR - 0

PSR - 0 menentukan bagaimana persyaratan wajib yang harus dipatuhi untuk autoloader interoperability.

  • NameSpace dan Class haruslah memenuhi syarat seperti ini \<VendorName>\<NameSpace>\<ClassName>
  • Setiap NameSpace harus memiliki nama dari top level NameSpace (VendorName)
  • Setiap NameSpace dapat memiliki banyak sub NameSpace sesuai yang dibutuhkan.
  • NameSpace dan Class yang memenuhi syarat, memiliki suffix ".php"

Contohnya seperti ini :

\Symfony\Core\Request => /path/ke/project/lib/vendor/Symfony/Core/Request.php

 PSR - 1

Aturan ini fokus pada convention name dan struktur file seperti ini :

  • Enforce PSR - 0
  • Class name di define dalam bentuk StudlyCase
  • Class constants di deffine dalam bentuk upper case dengan underscore separator
  • Method name di define dalam bentuk camelCase

PSR - 2

Aturan ini tentunya juga enforcing aturan pada PSR sebelumnya. Dan tujuan pada PSR 2 ini adalah agar terbentuknya suati single style guide dalam menghasilkan shared code yang terformat dengan seragam.

Beberapa contohnya ialah seperti ini :

  • Namespace & Use Declarations

- Harus ada satu blank line setelah namespace

- Semua "Use" declaration di deklarasikan setelah namespace

- Hanya ada satu "Use" keyword dalam satu line

- Harus ada satu blank line setelah block deklarasi "Use"

namespace App;
use \Vendor\Sample1;
use \Vendor\Sample2;
class Sample 
{
}
  • Extends & Implements

Extend dan Implement keyword harus di deklarasikan dalam satu line yang sama dengan class name. Contohnya seperti ini :

class ClassName extends ParentClass implements \ArrayAccess, \Countable
{
//constant,property,methods
}

Saat kita melakukan implements yang cukup banyak, maka bisa saja akan terbagi dalam beberapa line. Bila seperti itu, maka caranya adalah dengan memberi indentasi satu kali pada item - item yang di implement dan hanya satu item untuk tiap line nya seperti ini :

class ClassName extends ParentClass implements 
\ArrayAccess,
\Countable
{
//constant,property,methods
}

Dapat dilhat dalam beberapa contoh sebelumnya, pada aturan PSR 2 ini, Opening Braces haruslah pada line selanjutnya setelah Class name line, dan Clsing Braces pada line setelah body.

  •  Property

- Visibility harus di deklarasikan pada setiap property

- Hanya ada satu deklarasi property dalam tiap statement.

- Tidak menggunakan keyword "var" dalam mendeklarasikan property

- Property name tidak diawali dengan sebuah underscore untuk menentukan  visibilitynya

Contohnya seperti ini :

namespace \Vendor\Package;
class ClassName 
{
public $foo = null;
}
  • Method

- Tidak ada spasi setelah opening parenthesis dan sebelum closing parenthesis.

- Pada method argument, tidak ada spasi sebelum tanda koma, namun berikan satu spasi setelah tanda koma.

- Method argument yang memiliki default value, haruslah diletakan di akhir deklarsi argument - argument

Contohnya seperti ini :

namespace \Vendor\Package;
class ClassName 
{
public function foo($arg1,$arg2,$arg3=[])
{
//method body
}
}
  • if - elseif - else

- Gunakan keyword "elseif" bila lebih dari dua kondisi.

- Else dan Elseif berada pada line yang sama setelah closing brace sebelumnya

Contohnya seperti ini :

if ($sample) {
// if body
} elseif ($sample2) {
// elseif body
} else {
// else body;
}

Begitulah beberapa contoh dari PSR. Dalam kasus nyata, bayangkan saja saat kita menggunakan package atau menggunakan component apapun dari third party, namun tiap third party menggunakan convention name dan pengkodean yang berbeda. Tentunya akan menjadi berantakan. Begitupula dalam pekerjaan sebuah team.

Sekian yang dapat penulis sampaikan. Semoga bermanfaat.