Framework Interop Group에서 제시하는 Code Convention 룰(PHP 언어에만 적용되는) 이다.
1 PSR-0 / Autoloading Standard
PSR-0 는 객체지향 PHP 에서 객체간의 충돌을 방지하고, 객체의 자동 불러오기(autoloader)의 상호운용성을 위해 반드시 지켜야할 네이밍 규칙을 명시하고 있다. 하지만 2014.10.21 부로 폐기되고, PSR-4로 대체되었다.
2 PSR-1 / Basic coding standard
2.1 PHP Tags
아래의 두 태그만 사용한다.
2.2 Character Encoding
UTF-8로 사용, BOM(Byte Order Mark)은 사용하지 않는다.
2.3 Namespace and Class Names
네임스페이스와 클래스 이름은 (구 PSR-0) PSR-4 규격에 따라서 “autoloading”을 지원하도록 만들어야 한다.
이는 각 클래스 이름이 파일에 대응하며, 네임스페이스는 최소한 1 레벨 이상의 깊이를 가져야 함을 의미한다. (Top 레벨은 벤더 이름이다.)
클래스 이름은 반드시 StudlyCaps형식을 따라야 한다.
PHP 5.3 이후의 코드들은 반드시 네임스페이스 규칙을 따라야 한다.
PHP 5.2이하에서 만들어진 코드라면 클래스 이름앞에 Vendor_를 표기한다.
2.4 Class Constants, Properties, Methods
2.4.1 Class Constants
클래스 상수는 반드시 대문자와 언더바로만 선언해야 한다.
2.4.2 Properties
Properties(멤버변수)에 대해서는 $StudlyCaps, $camelCase, $under_score 중 어느 것을 사용해도 상관없다.
무엇이든 합리적인 범위안에서 일관성있게 사용하면 된다.
2.4.3 Methods
메서드 이름은 반드시 camelCase()를 따른다.
3 PSR-2 / General Coding style
일반적인 Coding Style Guide로 PSR-1을 기본으로 추가적인 요구사항들을 가이드 한다.
3.1 Overview
- 코드는 반드시 PSR-1을 따라야 한다.
- 코드 들여쓰기(indenting)은 반드시 4개의 스페이스 문자를 사용한다.
- 라인의 길이는 80또는 그 이하를 권장한다.
- namespace 다음에는 반드시 하나의 공백라인을 추가해야 한다.
- use 다음에는 반드시 하나의 공백라인을 추가해야 한다.
- 클래스에서 braces({})는 반드시 다음 줄에 추가한다.
- 메서드에서 braces는 반드시 다음 줄에 추가한다.
- 모든 메서드와 propertis에 반드시 visibility( public, protected ,private)를 선언해야 한다.
- abstract와 final은 반드시 visibility 전에 선언해야 한다.
- static는 반드시 visibility 다음에 사용해야 한다.
- Control structure keywords (제어문 키워드) 다음에는 반드시 공백을 포함한다.
- Control structures(제어문) 다음의 braces({})는 반드시 하나의 공백을 포함하고, control structures(제어문)와 같은 라인에서 열고 반드시 다음 라인에서 닫는다.
- Control structures(제어문)의 여는 괄호 다음과 닫는 괄호 이전에 반드시 공백을 두면 안된다.
3.1.1 예제
3.2 General
3.2.1 Basic Coding Standard
코드는 반드시 PSR-1의 기본 규칙을 따라야 한다.
3.2.2 Files
- 모든 PHP 파일은 반드시 UNIX LF(linefeed)으로 끝맺어야 한다. (에디터 사용 시 설정에서 UNIX LF로 설정)
- 모든 PHP 파일은 반드시 한줄의 공백줄로 끝맺어야 한다.
- 닫는 태그(?>)는 반드시 생략하여야 하고 파일은 오직 PHP만을 포함하고 있어야 한다.
3.2.1 Lines
- 줄 길이에 Hard limit를 반드시 주지 않는다. (hard limit: 사용자가 절대 넘을 수 없는 최대 값)
- Soft limit는 반드시 120자다. (Soft limit: 사용자가 사용할 수 있는 최대 값)
- 줄 길이는 80자를 넘지 않는 것을 권장한다.
- 라인의 마지막에 절대 공백을 두지 않는다.
- 공백 라인은 가독성을 높이기 위하여 사용되어야 하며 관련된 코드 블럭을 보여줘야(시사해줘야) 한다.
- 반드시 한 줄에 하나 이상의 statement(명령문)를 두지 않는다. 한 줄 아끼려고 가독성을 해치지 말라.
3.2.1 Indenting
Indent는 반드시 4개의 스페이스 문자를 이용한다. 탭을 사용하지 않는다.
3.2.1 Keywords and True/False/Null
- PHP의 키워드는 반드시 소문자를 사용한다.
- PHP 상수 true, false, null은 반드시 소문자여야 한다.
3.3 Namespace and Use Declarations
- namespace 선언 후 다음 라인은 반드시 하나의 공백 라인을 두어야 한다.
- use 선언은 반드시 namespace 선언 다음에 해야 한다.
- 반드시 한번에 하나의 use 선언을 한다. (한 라인에 이어서 선언하지 않는다.)
- use블럭 다음 라인은 반드시 하나의 공백 라인을 두어야 한다.
For example:
3.4 Classes, Properties, and Methods
Class 용어는 classes, interfaces, traits 모두를 의미한다.
3.4.1 Extends and Implements
-
extends,
implements 키워드는 반드시 class 선언 라인에 선언한다.
- 클래스의 opening brace(“{“)는 반드시 자신의 라인에 있어야 한다. (class 선언 다음 라인)
- 클래스의 closing brace(“}”)는 반드시 class body 다음 라인에 있어야 한다. (body에 있는 코드와 한 라인에 있으면 안된다)
implements의 목록은 여러 줄에 걸쳐 분할할 수 있다.
목록의 첫 번째 interface 항목은 다음 행에 있어야 하며 각각의 후속 라인 당 하나의 interface로 기술한다.
각 항목들은 한 번의 인덴트가 있어야 한다.
3.4.2 Properties
- Visibility ( public, protected ,private)는 반드시 모든 property들에 선언되어야 한다.
- var 키워드는 property를 선언 하는 데 사용할 수 없다.
- statement당 하나 이상의 property 선언이 있으면 안된다.
- property명은 언더스코어(“_”)로 시작되지 않도록 한다.
Property 선언 예
3.4.3 Methods
- 모든 메소드에 반드시 Visibility를 선언한다.
- 메소드 이름은 언더스코어(“_”)로 시작되지 않도록 한다.
- 메소드 이름 다음에는 절대 공백이 포함되어 있으면 안된다.
- 메소드의 opening brace(“{“)는 반드시 자신의 라인에 있어야 한다. (method 선언 다음 라인)
- 메소드의 closing brace(“}”)는 반드시 메소드 body 다음 라인에 있어야 한다. (body에 있는 코드와 한 라인에 있으면 안된다)
- 열고 닫는 괄호 안쪽으로 절대 공백이 있으면 안된다.
메소드 선언 예 (괄호, 콤마, 스페이스, 브레이스의 배치를 참고하라.)
3.4.4 Method Arguments
- 메소드의 아규먼트 리스트 부분의 콤마 앞부분에는 절대 공백이 들어가면 안되며, 콤마 다음에는 반드시 하나의 공백이 들어가야 한다.
- 디폴트 밸류가 필요한 메소드의 아규먼트는 가장 마지막에 위치하도록 한다.
메소드 아규먼트 항목들은 여러 줄에 걸쳐 분할 할 수 있다.
이렇게 할 경우 첫 번째 아규먼트 항목은 반드시 다음 라인에 있어야 하며, 나머지 각 항목들은 항목 당 하나의 라인을 가져야 한다.
또한 닫는 괄호와 여는 브레이스는 반드시 하나의 공백 사이를 두고 한 라인에 있어야 하며, 메소드의 마지막 아규먼트 다음 라인에 있어야 한다.
각 항목들은 한 번의 인덴트가 있어야 한다.
3.4.5 abstract, final, static
- abstract, final 선언은 반드시 visibility 선언 이전에 하여야 한다.
- static 선언은 반드시 visibility 선언 다음에 있어야 한다.
3.4.6 Method and Function Calls
- 메소드나 펑션 호출 구문에서 메소드 또는 펑션 이름과 여는 괄호 사이에 절대 공백이 있으면 안되며 닫는 괄호 이전에 공백이 있으면 안된다.
- 여는 괄호와 닫는 괄호 안에 절대 공백을 두지 않는다.
- 호출되는 메소드, 펑션의 아규먼트 리스트 사이에 콤마 앞에는 절대 공백이 있으면 안되며 각 콤마 다음에는 하나의 공백을 두어야 한다.
3.5 Control Structures
The general style rules for control structures are as follows:
- 컨트롤 스트럭쳐 키워드 다음에는 반드시 하나의 공백을 둔다.
- 여는 괄호 다음에는 절대 공백을 두지 않는다.
- 닫는 괄호 이전에 절대 공백을 두지 않는다.
- 닫는 괄호와 여는 브레이스 사이에 반드시 하나의 공백을 둔다.
- 스트럭쳐의 바디는 반드시 한 번 들여 쓰기(4개의 스페이스)한다.
- 닫는 브레이스는 반드시 바디의 다음 라인에 둔다.
- 각 스트럭쳐의 바디는 반드시 브레이스로 감싸줘야 한다.
This standardizes how the structures look, and reduces the likelihood of introducing errors as new lines get added to the body.
3.5.1 if, elseif, else
괄호, 공백, 브레이스의 배치를 숙지하세요. 그리고 else와 elseif는 이전 바디의 닫는 브레이스와 같은 라인에 있습니다.
elseif 키워드는 else if와 같이 사용하지 말아야 한다. 모든 제어 키워드는 하나의 단어처럼 사용한다.
3.5.2 switch, case
아래의 switch 스트럭쳐에서 괄호, 스페이스, 브레이스의 배치를 숙지.
- case 스테이트먼트는 반드시 switch 의 뎁스로부터 한 번의 인덴트(4개의 스페이스)가 있어야 한다.
- break 키워드는 반드시 case의 바디와 동일한 레벨에서 한번의 인덴트(4개의 스페이스)가 있어야 한다.
- 비어있지 않은 case 바디에 고의적으로 break를 사용하지 않을 경우 반드시 “// no break” 와 같이 주석을 남긴다.
3.5.3 while, do while
아래의 while, do while 스테이트먼트에서 괄호, 스페이스, 브레이스의 위치를 숙지.
3.5.4 for
아래의 for 스테이트먼트에서 괄호, 스페이스, 브레이스의 위치를 숙지.
3.5.5 foreach
아래의 foreach 스테이트먼트에서 괄호, 스페이스, 브레이스의 위치를 숙지.
3.5.6 try, catch
아래의 try, catch 블럭에서 스테이트먼트에서 괄호, 스페이스, 브레이스의 위치를 숙지.
3.6 Closures
- Closures는 반드시 function 키워드 다음과 use 키워드 앞 뒤로 하나의 공백을 두어야한다.
- 여는 브레이스는 반드시 closures의 첫 번째 라인에 있도록 하며 닫는 브레이스는 반드시 바디의 다음 라인에 있어야 한다.
- 여는 괄호 다음의 아규먼트나 변수 사이에는 절대 공백을 두지 않으며, 닫는 괄호 이전의 아규먼트나 변수 사이에도 절대 공백을 두지 않는다.
- 아규먼트 항목들 또는 변수 항목들 사이의 콤마 앞에는 절대 공백을 두지 않으며, 콤마 뒤에는 반드시 하나의 공백을 둔다.
- Closure 의 아규먼트 중 디폴트 밸류가 있는 아규먼트일 경우 해당 아규먼트는 반드시 가장 마지막에 위치하도록 한다.
아래의 Closure 선언에서 스테이트먼트에서 콤마, 스페이스, 브레이스의 위치를 숙지.
Argument lists and variable lists MAY be split across multiple lines,
아규먼트 항목들 또는 변수 항몰들은 여러줄에 걸쳐 분할 할 수 있다.
이렇게 할 경우 첫 번째 항목은 반드시 다음 라인에 있어야 하며, 나머지 각 항목들은 항목 당 하나의 라인을 가져야 한다.
각 항목들은 한 번의 인덴트가 있어야 한다.
닫는 괄호와 여는 브레이스는 반드시 항목들 다음 라인에 있어야 하며, 하나의 공백을 사이로 같은 라인에 있어야 한다.
펑션 또는 메소드 호출 시 아규먼트로 사용되는 closure일 때도 위 포맷팅 룰을 적용할 수 있다는것을 숙지.
'IT > Web Programming' 카테고리의 다른 글
Front-End 발전 역사와 개발 생태계 (0) | 2018.05.16 |
---|---|
PDF 컨버터(출력물) DOMPDF 사용팁 (0) | 2018.05.13 |
[javascript] Promise를 사용해봅시다. (0) | 2018.05.09 |
[javascript]라이브러리 모음 (0) | 2018.05.04 |
[크로스브라우징]익스플로러와 비익스플로러에서의 Date Object (0) | 2018.05.02 |
[CSS] font-size의 새로운 단위 [em] (0) | 2018.04.14 |
[HTML] HTML 어떻게 읽는것이 좋을까? (0) | 2018.04.13 |
Xml Web Service 를 사용하기 위한 IIS 및 ASP.NET 2.0 설정 (0) | 2018.04.09 |