PHP 프로그래밍을 위한 다섯 가지 좋은 습관

저자：Eve Cole 업데이트 시간：2009-06-07 14:57:08

특정 상황에 따라 다르지만 일반 개발자는 우수한 개발자보다 효율성이 10~20% 정도 떨어지는 경우가 많습니다. 좋은 개발자는 풍부한 경험과 좋은 프로그래밍 습관을 갖고 있기 때문에 더 효율적입니다. 나쁜 프로그래밍 습관은 효율성에 영향을 미칩니다. 이 기사는 몇 가지 좋은 프로그래밍 습관을 보여줌으로써 더 나은 프로그래머가 되는 데 도움이 됩니다.

이러한 좋은 프로그래밍 습관은 효율성을 높일 뿐만 아니라 애플리케이션의 수명 주기 전반에 걸쳐 유지 관리하기 쉬운 코드를 작성할 수 있게 해줍니다. 작성하는 코드에는 많은 유지 관리가 필요할 수 있으며, 이는 상당한 비용을 발생시킵니다. 좋은 프로그래밍 습관을 개발하면 설계 품질(예: 모듈성)이 향상되어 코드를 더 쉽게 이해하고 유지 관리하기가 더 쉬워지며 유지 관리 비용도 절감할 수 있습니다.

잘못된 프로그래밍 습관은 코드 결함을 유발하여 유지 관리 및 수정을 어렵게 만들고 수정 시 다른 결함이 발생할 가능성이 높습니다. 다음은 PHP 코드가 이러한 함정을 피하는 데 도움이 되는 5가지 좋은 프로그래밍 습관입니다.

◆좋은 이름을 사용하십시오.

◆더 작은 부분으로 나누어 보세요.

◆코드에 주석을 추가합니다.

◆오류 상황을 처리합니다.

◆복사하여 붙여넣기를 사용하지 마세요.

이러한 습관은 아래에 자세히 설명되어 있습니다.

좋은 이름 지정 사용

설명적인 이름을 사용하면 코드를 더 쉽게 읽고 이해할 수 있으므로 좋은 이름 지정을 사용하는 것이 가장 중요한 프로그래밍 습관입니다. 코드가 이해하기 쉬운지는 향후에도 유지 관리가 가능한지에 달려 있습니다. 코드에 주석 처리가 없더라도 이해하기 쉽다면 향후 변경이 크게 촉진될 것입니다. 이 습관의 목표는 당신이 작성하는 코드를 책처럼 읽고 이해하기 쉽게 만드는 것입니다.

나쁜 습관: 모호하거나 의미 없는 이름

목록 1의 코드에는 너무 짧고 읽기 어려운 약어와 메서드의 기능을 반영하지 않는 메서드 이름이 포함된 변수 이름이 포함되어 있습니다. 메소드 이름이 한 가지 작업을 수행해야 한다는 인상을 주지만 실제로는 다른 작업을 수행하는 경우 오해의 소지가 있으므로 심각한 문제가 발생합니다.

목록 1. 나쁜 습관: 모호하거나 의미 없는 이름

<?php

function getNBDay($d){
스위치($d) {
사례 5:
사례 6:
사례 7:
1을 반환합니다.
기본:
반환 ($d + 1);
}
}

$day = 5;

$nextDay = getNBDay($day);

echo ("다음 날: " . $nextDay . "n")

;

모범 사례: 설명적이고 간결한 이름

목록 2의 코드는 좋은 프로그래밍 사례를 보여줍니다. 새로운 메소드 이름은 매우 설명적이며 메소드의 목적을 반영합니다. 마찬가지로 변경된 변수 이름이 더 설명적입니다. 가장 짧게 남아 있는 유일한 변수는 $i이며, 이 목록에서는 루프 변수입니다. 많은 사람들이 너무 짧은 이름을 사용하는 것에 눈살을 찌푸리지만, 코드의 기능을 명확하게 나타내기 때문에 루프 변수에 사용하는 것이 허용됩니다(심지어 유익하기도 합니다).

목록 2. 모범 사례: 설명적이고 간결한 이름

<?php
정의('월요일', 1);
정의('화요일', 2);
정의('수요일', 3);
정의('목요일', 4);
정의('금요일', 5);
정의('토요일', 6);
정의('일요일', 7);
/*
*
* @param $dayOfWeek
* @return int 요일, 1은 월요일 등입니다.
*/
함수 findNextBusinessDay($dayOfWeek){
$nextBusinessDay = $dayOfWeek;
스위치($dayOfWeek) {
금요일:
토요일:
일요일:
$nextBusinessDay = 월요일;
부서지다;
기본:
$nextBusinessDay += 1;
부서지다;
}
$nextBusinessDay를 반환합니다.
}
$day = 금요일;
$nextBusDay = findNextBusinessDay($day);
echo ("다음 날은:" . $nextBusDay . "n");
?>

큰 조건을 메서드로 분리한 다음 조건을 설명하는 이름으로 메서드 이름을 지정하는 것이 좋습니다. 이 기술은 코드의 가독성을 향상시키고 조건을 구체적으로 만들어 추출 및 재사용이 가능하도록 할 수 있습니다. 조건이 변경되면 방법을 업데이트하는 것도 쉽습니다. 메서드에는 의미 있는 이름이 있기 때문에 코드의 목적을 반영하고 코드를 더 쉽게 읽을 수 있습니다.

프로그래밍을 계속하기 전에

작은 부분의

문제를 해결하는 데 집중하는 것이 더 쉬울 것입니다.

급한 문제를 해결하면서 프로그램을 계속하다 보면 기능이 점점 길어지게 됩니다. 장기적으로 이것은 문제가 되지 않지만, 돌아가서 더 작은 조각으로 리팩터링하는 것을 기억하는 것이 좋습니다.

리팩토링은 좋은 생각이지만 더 짧고 집중적인 코드를 작성하는 습관을 들여야 합니다. 짧은 메소드는 하나의 창에서 읽을 수 있으며 이해하기 쉽습니다. 방법이 너무 길어서 한 창에서 읽을 수 없으면 전체 아이디어를 처음부터 끝까지 빠르게 따라갈 수 없기 때문에 따라가기가 어려워집니다.

메소드를 작성할 때 각 메소드가 한 가지 작업만 수행하도록 하는 습관을 들여야 합니다. 이는 좋은 습관입니다. 첫째, 메서드가 한 가지 작업만 수행하면 재사용할 가능성이 더 높으며, 둘째, 해당 메서드는 테스트하기 쉽고, 셋째, 해당 메서드는 이해하고 변경하기 쉽습니다.

나쁜 습관: 지나치게 긴 메소드(너무 많은 작업 수행)

목록 3은 많은 문제가 있는 매우 긴 함수를 보여줍니다. 많은 일을 하기 때문에 충분히 컴팩트하지 않습니다. 또한 읽기, 디버그 및 테스트가 더 쉽습니다. 여기에는 파일 반복, 목록 작성, 각 개체에 값 할당, 계산 수행 등이 포함됩니다.

목록 3. 나쁜 습관: 함수가 너무 길다

<?php

function writeRssFeed($user)
{
//DB 연결 정보를 가져옵니다.

// 사용자의 선호도를 조회합니다...
$link = mysql_connect('mysql_host', 'mysql_user', 'mysql_password')
OR die(mysql_error())

// 쿼리
$perfsQuery = sprintf("user_perfs WHERE user= '%s'에서 max_stories 선택",
mysql_real_escape_string($user));

$result = mysql_query($query, $link);

$max_stories = 25; // 기본값은 25입니다.

if ($row = mysql_fetch_assoc($result)) {
$max_stories = $row['max_stories'];
}

//가서 내 데이터 가져오기
$perfsQuery = sprintf("SELECT * FROM 스토리 WHERE post_date = '%s'",
mysql_real_escape_string());

$result = mysql_query($query, $link);

$feed = "<rss 버전="2.0">" .
"<채널>" .
"<title>나의 위대한 피드</title>" .
"<링크> http://www.example.com/feed.xml </link>" .
"<설명>세계 최고의 피드</설명>" .
"<언어>en-us</언어>" .
"<pubDate>2008년 10월 20일 화요일 10:00:00 GMT</pubDate>" .
"<마지막 빌드 날짜>2008년 10월 20일 화요일 10:00:00 GMT</마지막 빌드 날짜>" .
"<문서> http://www.example.com/rss </docs>" .
"<generator>내피드 생성기</generator>" .
"<managingEditor> [email protected] </managingEditor>" .
"<webMaster> [email protected] </webMaster>" .
"<ttl>5</ttl>";

// 피드 빌드...
while ($row = mysql_fetch_assoc($result)) {
$title = $row['제목'];
$link = $row['링크'];
$description = $row['설명'];
$date = $row['날짜'];
$guid = $row['guid'];

$feed .= "<항목>";
$feed .= "<제목>" .
$feed .= "<링크>" .$link "</링크>";
$feed .= "<설명> " . $description "</설명>";
$feed .= "<pubDate>" . $date .
$feed .= "<guid>" .
$feed .= "</항목>";
}

$feed .= "</rss";

// 서버에 피드를 씁니다...
echo($feed);

}

?>이런 메소드를 몇 개 더 작성하면 유지 관리가 진짜 문제가 됩니다.

좋은 습관: 관리 가능하고 기능별 메서드

목록 4 원래 메서드를 더 간결하고 읽기 쉬운 메서드로 다시 작성합니다. 이 예에서 긴 메서드는 여러 개의 짧은 메서드로 구분되며 각 짧은 메서드는 한 가지 작업을 담당합니다. 이러한 코드는 향후 재사용 및 테스트에 매우 유용합니다.

목록 4. 모범 사례: 관리하기 쉬운 함수별 접근 방식

<?php

function createRssHeader()
{
"<rss version="2.0">"을 반환합니다.
"<채널>" .
"<title>나의 위대한 피드</title>" .
"<링크> http://www.example.com/feed.xml </link>" .
"<설명>세계 최고의 피드</설명>" .
"<언어>en-us</언어>" .
"<pubDate>2008년 10월 20일 화요일 10:00:00 GMT</pubDate>" .
"<마지막 빌드 날짜>2008년 10월 20일 화요일 10:00:00 GMT</마지막 빌드 날짜>" .
"<문서> http://www.example.com/rss </docs>" .
"<generator>내피드 생성기</generator>" .
"<managingEditor> [email protected] </managingEditor>" .
"<webMaster> [email protected] </webMaster>" .
"<ttl>5</ttl>";
}

함수 createRssFooter()
{
"</채널></rss>"를 반환합니다.
}

함수 createRssItem($title, $link, $desc, $date, $guid)
{
$item .= "<아이템>";
$item .= "<제목>" .
$item .= "<링크>" .$link "</링크>";
$item .= "<설명> " . $설명 "</설명>";
$item .= "<pubDate>" . $date .
$item .= "<guid>" .
$item .= "</항목>";
$item을 반환합니다.
}

함수 getUserMaxStories($db_link, $default)
{
$perfsQuery = sprintf("user_perfs WHERE user= '%s'에서 max_stories 선택",
mysql_real_escape_string($user));

$result = mysql_query($perfsQuery, $db_link);

$max_stories = $기본값;

if ($row = mysql_fetch_assoc($result)) {
$max_stories = $row['max_stories'];
}

$max_stories를 반환합니다.
}

함수 writeRssFeed($user)
{
//DB 연결 정보를 가져옵니다.
$settings=parse_ini_file("rss_server.ini");

// 사용자의 선호도를 조회합니다...
$link = mysql_connect($settings['db_host'], $settings['user'],
$settings['password']) OR die(mysql_error())

$max_stories = getUserMaxStories($link, 25);

//가서 내 데이터 가져오기
$newsQuery = sprintf("SELECT * FROM 스토리 WHERE post_date = '%s'",
mysql_real_escape_string(time()));

$result = mysql_query($newsQuery, $link);

$feed = createRssHeader();

$i = 0;
// 피드 빌드...
while ($row = mysql_fetch_assoc($result)) {
if ($i < $max_stories) {
$title = $row['제목'];
$link = $row['링크'];
$description = $row['설명'];
$date = $row['날짜'];
$guid = $row['guid'];

$feed .= createRssItem($title, $link, $description, $date, $guid);

$i++;
} 또 다른 {
부서지다;
}
}

mysql_close($link);

$feed .= createRssFooter();

// 서버에 피드를 씁니다...
에코($피드);
}
?> 긴 메소드를 짧은 메소드로 분할하는 것에도 한계가 있으며, 과도한 분할은 역효과를 낳습니다. 그러므로 이 좋은 습관을 남용하지 마십시오. 코드를 큰 덩어리로 나누면 긴 코드를 나누지 않는 것만큼 읽기가 어려워질 수 있습니다.

코드에 주석 추가하기

코드에 좋은 주석을 추가하는 것은 때로는 코드를 작성하는 것만큼 어려워 보일 수 있습니다. 우리는 종종 코드가 현재 수행 중인 작업에 주석을 다는 경향이 있기 때문에 무엇에 주석을 달아야 할지 아는 것이 쉽지 않습니다. 코드의 목적을 설명하는 것이 좋습니다. 함수의 덜 명확한 헤더 블록에서 독자는 메서드의 원래 목표뿐만 아니라 메서드의 입력 및 출력에 대해 설명합니다.

코드가 현재 수행 중인 작업을 주석으로 처리하는 것이 일반적이지만 이는 불필요합니다. 코드가 복잡하고 현재 수행 중인 작업을 주석으로 처리해야 하는 경우 이해하기 쉽도록 코드를 다시 작성해야 한다는 것을 의미합니다. 목적을 설명하는 주석을 제공하지 않고도 코드를 더 쉽게 읽을 수 있도록 좋은 이름과 짧은 메서드를 사용하는 방법을 알아보세요.

나쁜 습관: 함수에 주석을 많이 달거나 적게 달기

목록 5의 주석은 독자에게 코드가 수행하는 작업, 즉 루프를 반복하거나 숫자를 추가하는 내용만 알려줍니다. 그러나 현재 작업을 수행하는 이유를 무시합니다. 이로 인해 사람들은 코드를 안전하게 변경할 수 있는지(새로운 결함이 발생하지 않고) 알지 못한 채 코드를 유지 관리하게 됩니다.

목록 5. 나쁜 습관: 함수 주석이 너무 많거나 충분하지 않음

<?php

클래스 결과 메시지
{
비공개 $심각도;
비공개 $ 메시지;

공개 함수 __construct($sev, $msg)
{
$this->심각도 = $sev;
$this->메시지 = $msg;
}

공개 함수 getSeverity()
{
$this->severity를 반환합니다.
}

공개 함수 setSeverity($severity)
{
$this->심각도 = $심각도;
}

공개 함수 getMessage()
{
$this->메시지를 반환합니다.
}

공개 함수 setMessage($msg)
{
$this->메시지 = $msg;
}
}

함수 cntMsgs($messages)
{
$n = 0;
/* 메시지를 반복합니다... */
foreach($m개의 메시지) {
if ($m->getSeverity() == '오류') {
$n++; // 결과에 1을 추가합니다.
}
}
$n을 반환합니다.
}

$messages = array(new ResultMessage("Error", "이것은 오류입니다!"),
new ResultMessage("경고", "경고입니다!"),
new ResultMessage("Error", "이것은 또 다른 오류입니다!"));

$errs = cntMsgs($messages);

echo("결과에 " . $errs . " 오류가 있습니다.");

모범 사례: 주석이 달린 함수 및 클래스

목록 6의 주석은 독자에게 클래스와 메서드에 대해 알려줍니다. 목적. 이 주석은 코드가 현재 작업을 수행하는 이유를 설명하며, 이는 향후 코드를 유지 관리할 때 유용할 수 있습니다. 조건이 바뀌면 코드를 수정해야 할 수도 있지만, 코드의 목적을 쉽게 이해할 수 있다면 수정이 쉽습니다.

목록 6. 모범 사례: 주석이 달린 함수 및 클래스

<?php
/**
* ResultMessage 클래스는 반환될 수 있는 메시지를 보유합니다.
* 프로세스의 결과로 메시지에는 심각도가 있습니다.
* 메시지.
*
* @작가 나굿
*
*/
클래스 결과 메시지
{
비공개 $심각도;
비공개 $ 메시지;

/**
* 할당할 수 있는 ResultMessage의 생성자
* 심각도 및 메시지.
* @param $sev {@link getSeverity()} 참조
* @param $msg
* @return 알 수 없는_유형
*/
공개 함수 __construct($sev, $msg)
{
$this->심각도 = $sev;
$this->메시지 = $msg;
}

/**
* 메시지의 심각도를 반환합니다. 1이어야 합니다.
* "정보", "경고" 또는 "오류".
* @return string 메시지 심각도
*/
공개 함수 getSeverity()
{
$this->severity를 반환합니다.
}

/**
* 메시지의 심각도를 설정합니다.
* @param $심각도
* @return 무효
*/
공개 함수 setSeverity($severity)
{
$this->심각도 = $심각도;
}

공개 함수 getMessage()
{
$this->메시지를 반환합니다.
}

공개 함수 setMessage($msg)
{
$this->메시지 = $msg;
}
}

/*
* 배열에서 지정된 심각도의 메시지 수를 계산합니다.
* 메시지.
*
* @param $messages ResultMessage의 배열
* @return int 심각도가 "오류"인 메시지 수
*/
함수 countErrors($messages)
{
$matchingCount = 0;
foreach($m개의 메시지) {
if ($m->getSeverity() == "오류") {
$matchingCount++;
}
}
$matchingCount를 반환합니다.
}

$messages = array(new ResultMessage("Error", "이것은 오류입니다!"),
new ResultMessage("경고", "경고입니다!"),
new ResultMessage("Error", "이것은 또 다른 오류입니다!"));

$errs = countErrors($messages);

echo("결과에 " . $errs . " 오류가 있습니다.")

;

오류 처리

일반적으로 강력한 응용 프로그램을 작성하려면 오류 처리에 대한 80/20 규칙을 따르십시오. 코드의 80%는 예외 및 유효성 검사를 처리하는 데 사용되고 코드의 20%는 다음을 수행하는 데 사용됩니다. 실제 작업. 이는 프로그램의 기본 논리(행복 경로)를 코딩할 때 종종 수행됩니다. 이는 모든 데이터를 사용할 수 있고 모든 조건이 예상대로 작동하도록 내부적으로 작동하는 코드를 작성하는 것을 의미합니다. 이러한 코드는 애플리케이션 수명 주기 동안 취약할 수 있습니다. 다른 극단적인 경우에는 이전에 한 번도 경험하지 못한 조건에 대한 코드를 작성하는 데 많은 시간이 걸립니다.

이 습관을 사용하려면 모든 오류를 처리하는 코드를 작성하기보다는 오류 처리 코드를 충분히 작성하여 코드가 완료되지 않도록 해야 합니다.

나쁜 습관: 오류 처리가 전혀 없음

목록 7의 코드는 두 가지 나쁜 습관을 보여줍니다. 첫째, 특정 상태의 매개변수가 메서드에서 예외를 발생시키는 것으로 알려져 있음에도 불구하고 입력 매개변수를 확인하지 않습니다. 둘째, 코드는 예외를 발생시킬 수 있지만 예외를 처리하지는 않는 메서드를 호출합니다. 문제가 발생하면 코드 작성자나 코드를 유지 관리하는 사람은 문제의 원인만 추측할 수 있습니다.

목록 7. 나쁜 습관: 오류 조건을 처리하지 않음

<?php

// 실제 이름 가져오기
함수 변환DayOfWeekToName($day)
{
$dayNames = 배열(
"일요일",
"월요일",
"화요일",
"수요일",
"목요일",
"금요일",
"토요일");
$dayNames[$day]를 반환합니다.
}

echo("0일의 이름은 다음과 같습니다: " . ConvertDayOfWeekToName(0) . "n");
echo("10일의 이름은 다음과 같습니다: " . ConvertDayOfWeekToName(10) . "n");
echo("'오렌지' 요일의 이름은 다음과 같습니다: " . ConvertDayOfWeekToName('orange') . "n")

모범 사례: 예외 처리

목록 8은 의미 있는 방식으로 예외를 발생시키고 처리하는 방법을 보여줍니다. 추가적인 오류 처리는 코드를 더욱 강력하게 만들 뿐만 아니라 코드의 가독성도 향상시켜 이해하기 쉽게 만듭니다. 예외가 처리되는 방식은 메서드를 작성할 때 원 작성자의 의도를 잘 나타냅니다.

목록 8. 우수 사례: 예외 처리

<?php

/**
* 요일이 유효하지 않은 경우 발생하는 예외입니다.
* @작성자 나굿
*
*/
클래스 InvalidDayOfWeekException 확장 예외 { }

클래스 InvalidDayFormatException 확장 예외 { }

/**
* 요일에 주어진 요일의 이름을 구합니다.
* 제공된 값이 범위를 벗어나면 오류를 반환합니다.
*
* @param $일
* @return 알 수 없는_유형
*/
함수 변환DayOfWeekToName($day)
{
if (! is_numeric($day)) {
throw new InvalidDayFormatException('값 '' . $day . '' 는 ' 입니다.
'요일 형식이 잘못되었습니다.');
}

if (($day ≥ 6) || ($day ＜ 0)) {
throw new InvalidDayOfWeekException('일 번호 '' . $day . '' 는 ' 입니다.
'0-6이 올바르지 않습니다.');
}

$dayNames = 배열(
"일요일",
"월요일",
"화요일",
"수요일",
"목요일",
"금요일",
"토요일");
$dayNames[$day]를 반환합니다.
}

echo("0일의 이름은 다음과 같습니다: " . ConvertDayOfWeekToName(0) . "n")

try {
echo("10일의 이름은 다음과 같습니다: " . ConvertDayOfWeekToName(10) . "n");
} 잡기(InvalidDayOfWeekException $e) {
echo ("값을 변환하는 중 오류가 발생했습니다: " . $e->getMessage() . "n");
}

노력하다 {
echo("'오렌지색' 요일의 이름은 다음과 같습니다: " . ConvertDayOfWeekToName('orange') . "n");
} 잡기(InvalidDayFormatException $e) {
echo ("값을 변환하는 중 오류가 발생했습니다: " . $e->getMessage() . "n");
}

매개변수를 확인하는 것은 확인이지만 - 매개변수가 특정 상태에 있도록 요구하는 경우 메서드를 사용하는 사람들에게 도움이 될 것입니다. 매개변수를 확인하고 의미 있는 예외를 발생시켜야 합니다.

◆ 예외를 가능한 한 가깝게 처리합니다. 발생하는 것은 밀접한 관련이 있습니다.

◆각 예외를 전담 처리합니다.

복사-붙여넣기를 사용하지 마세요.

다른 곳에서 코드를 복사하여 코드 편집기에 붙여넣을 수 있지만 그렇게 하는 데에는 장단점이 있습니다. 좋은 점은 예제나 템플릿에서 코드를 복사하면 많은 실수를 피할 수 있다는 것입니다. 단점은 이로 인해 유사한 프로그래밍 방법이 많이 발생하기 쉽다는 것입니다.

애플리케이션의 한 부분에서 다른 부분으로 코드를 복사하여 붙여넣지 않도록 주의하세요. 만약 당신이 이런 식이라면, 이 나쁜 습관을 멈추고 재사용이 가능하도록 이 코드를 다시 작성하는 것을 고려해보세요. 일반적으로 코드를 한 곳에 두는 것은 한 곳에서만 변경하면 되기 때문에 나중에 유지 관리하기가 더 쉽습니다.

나쁜 습관: 목록 9의 비슷한 코드 조각은

거의 동일하지만 값이 다른 여러 메서드를 보여줍니다. 복사하여 붙여넣은 코드를 찾는 데 도움이 되는 도구가 있습니다(참고자료 참조).

목록 9. 나쁜 습관: 유사한 코드 조각

<?php
/**
* 배열에서 발견된 메시지 수를 계산합니다.
* getSeverity() 값이 "Error"인 ResultMessage
*
* @param $messages ResultMessage의 배열
* @return 알 수 없는_유형
*/
함수 countErrors($messages)
{
$matchingCount = 0;
foreach($m개의 메시지) {
if ($m->getSeverity() == "오류") {
$matchingCount++;
}
}
$matchingCount를 반환합니다.
}

/**
* 배열에서 발견된 메시지 수를 계산합니다.
* getSeverity() 값이 "Warning"인 ResultMessage
*
* @param $messages ResultMessage의 배열
* @return 알 수 없는_유형
*/
함수 countWarnings($messages)
{
$matchingCount = 0;
foreach($m개의 메시지) {
if ($m->getSeverity() == "경고") {
$matchingCount++;
}
}
$matchingCount를 반환합니다.
}

/**
* 배열에서 발견된 메시지 수를 계산합니다.
* getSeverity() 값이 "Information"인 ResultMessage
*
* @param $messages ResultMessage 배열
* @return 알 수 없는_유형
*/
함수 countInformation($messages)
{
$matchingCount = 0;
foreach($m개의 메시지) {
if ($m->getSeverity() == "정보") {
$matchingCount++;
}
}
$matchingCount를 반환합니다.
}

echo("결과에 " . $errs . " 오류가 있습니다.");
?>

모범 사례: 매개변수를 사용하여 재사용 가능한 함수

목록 10은 복사된 코드를 메서드에 넣는 수정된 코드를 보여줍니다. 또 다른 방법도 변경되어 이제 작업을 새 방법에 위임합니다. 공통 접근 방식을 구축하려면 설계하는 데 시간이 걸리며, 그렇게 하면 본능적으로 복사하여 붙여넣는 대신 잠시 멈춰서 생각할 수 있습니다. 그러나 공통 접근 방식에 투자한 시간은 변경이 필요할 때 보상을 받을 것입니다.

목록 10. 모범 사례: 매개변수가 있는 재사용 가능한 함수

<?php
/*
* 배열에서 지정된 심각도의 메시지 수를 계산합니다.
* 메시지.
*
* @param $messages ResultMessage 배열
* @return int $withSeverity와 일치하는 메시지 수
*/
함수 countMessages($messages, $withSeverity)
{
$matchingCount = 0;
foreach($m개의 메시지) {
if ($m->getSeverity() == $withSeverity) {
$matchingCount++;
}
}
$matchingCount를 반환합니다.
}

/**
* 배열에서 발견된 메시지 수를 계산합니다.
* getSeverity() 값이 "Error"인 ResultMessage
*
* @param $messages ResultMessage의 배열
* @return 알 수 없는_유형
*/
함수 countErrors($messages)
{
return countMessages($messages, "오류");
}

/**
* 배열에서 발견된 메시지 수를 계산합니다.
* getSeverity() 값이 "Warning"인 ResultMessage
*
* @param $messages ResultMessage의 배열
* @return 알 수 없는_유형
*/
함수 countWarnings($messages)
{
return countMessages($messages, "경고");
}

/**
* 배열에서 발견된 메시지 수를 계산합니다.
* getSeverity() 값이 "Warning"인 ResultMessage
*
* @param $messages ResultMessage 배열
* @return 알 수 없는_유형
*/
함수 countInformation($messages)
{
return countMessages($messages, "정보");
}

echo("결과에 " . $errs . " 오류가 있습니다.")

결론

PHP 코드를 작성할 때 이 기사에서 설명한 좋은 습관을 기르면 읽고, 이해하고, 유지 관리하기 쉬운 코드를 작성할 수 있습니다. 이러한 방식으로 구축된 유지 관리 가능한 코드는 코드 디버깅, 수정 및 확장의 위험을 줄여줍니다.
좋은 이름과 짧은 방법을 사용하면 코드 가독성이 향상됩니다. 코드에 주석을 다는 목적은 코드 이해와 확장을 용이하게 하는 것입니다. 오류를 적절하게 처리하면 코드가 더욱 강력해집니다. 마지막으로, 코드를 깔끔하게 유지하고 재사용성을 높이려면 복사-붙여넣기 사용을 중단하세요.