Je nach konkreter Situation sind durchschnittliche Entwickler oft 10 bis 20 % weniger effizient als exzellente Entwickler. Gute Entwickler sind effizienter, weil sie über umfassende Erfahrung und gute Programmiergewohnheiten verfügen. Schlechte Programmiergewohnheiten beeinträchtigen die Effizienz. Dieser Artikel hilft Ihnen, ein besserer Programmierer zu werden, indem er einige gute Programmiergewohnheiten demonstriert.
Diese guten Programmiergewohnheiten steigern nicht nur die Effizienz, sondern ermöglichen Ihnen auch das Schreiben von Code, der während des gesamten Lebenszyklus Ihrer Anwendung leicht zu warten ist. Der von Ihnen geschriebene Code erfordert möglicherweise viel Wartung; die Anwendungswartung ist ein erheblicher Kostenfaktor. Die Entwicklung guter Programmiergewohnheiten kann die Designqualität (z. B. Modularität) verbessern, den Code verständlicher und damit leichter zu warten machen und gleichzeitig die Wartungskosten senken.
Schlechte Programmiergewohnheiten führen zu Codefehlern, die die Wartung und Änderung erschweren, und führen bei der Änderung wahrscheinlich zu anderen Fehlern. Im Folgenden sind fünf gute Programmiergewohnheiten aufgeführt, die PHP-Code dabei helfen können, diese Fallstricke zu vermeiden:
◆Verwenden Sie eine gute Benennung.
◆In kleinere Teile teilen.
◆Kommentare zum Code hinzufügen.
◆Behandeln Sie Fehlerbedingungen.
◆Verwenden Sie kein Kopieren und Einfügen.
Diese Gewohnheiten werden im Folgenden detailliert beschrieben:
Verwenden Sie eine gute Benennung
. Die Verwendung einer guten Benennung ist die wichtigste Programmiergewohnheit, da beschreibende Namen das Lesen und Verstehen des Codes erleichtern. Ob der Code leicht verständlich ist, hängt davon ab, ob er in Zukunft gepflegt werden kann. Selbst wenn der Code unkommentiert ist, wird er zukünftige Änderungen erheblich erleichtern, wenn er leicht verständlich ist. Das Ziel dieser Gewohnheit besteht darin, den von Ihnen geschriebenen Code so einfach lesbar und verständlich wie ein Buch zu machen.
Schlechte Angewohnheit: Vage oder bedeutungslose Namen
Der Code in Listing 1 enthält zu kurze Variablennamen, unleserliche Abkürzungen und Methodennamen, die nicht die Funktionalität der Methode widerspiegeln. Wenn der Methodenname den Eindruck erweckt, dass er eine Sache tun soll, tatsächlich aber etwas anderes tut, führt dies zu ernsthaften Problemen, da er irreführend ist.
Listing 1. Schlechte Angewohnheiten: vage oder bedeutungslose Namen
<?php
function getNBDay($d){
switch($d) {
Fall 5:
Fall 6:
Fall 7:
Rückgabe 1;
Standard:
return ($d + 1);
}
}
$day = 5;
$nextDay = getNBDay($day);
echo ("Nächster Tag ist: " . $nextDay . "n")
;
Gute Praxis: Beschreibende und prägnante Namen
Der Code in Listing 2 demonstriert gute Programmierpraktiken. Die neuen Methodennamen sind sehr aussagekräftig und spiegeln den Zweck der Methode wider. Ebenso sind die geänderten Variablennamen aussagekräftiger. Die einzige Variable, die am kürzesten bleibt, ist $i, die in dieser Auflistung eine Schleifenvariable ist. Obwohl viele Leute die Verwendung zu kurzer Namen missbilligen, ist es akzeptabel (und sogar vorteilhaft), sie in Schleifenvariablen zu verwenden, da dies die Funktion des Codes klar angibt.
Listing 2. Gute Praxis: beschreibende und prägnante Namen
<?php
define ('MONTAG', 1);
define ('TUESDAY', 2);
define ('WEDNESDAY', 3);
define ('DONNERSTAG', 4);
define ('FREITAG', 5);
define ('SATURDAY', 6);
define ('SONNTAG', 7);
/*
*
* @param $dayOfWeek
* @return int Wochentag, wobei 1 Montag ist und so weiter.
*/
Funktion findNextBusinessDay($dayOfWeek){
$nextBusinessDay = $dayOfWeek;
switch($dayOfWeek) {
Fall FREITAG:
Fall SAMSTAG:
Fall SONNTAG:
$nextBusinessDay = MONTAG;
brechen;
Standard:
$nextBusinessDay += 1;
brechen;
}
return $nextBusinessDay;
}
$day = FREITAG;
$nextBusDay = findNextBusinessDay($day);
echo ("Nächster Tag ist:" . $nextBusDay . "n");
?＞
Wir empfehlen Ihnen, große Bedingungen in eine Methode aufzuteilen und die Methode dann mit einem Namen zu benennen, der die Bedingung beschreibt. Diese Technik kann die Lesbarkeit des Codes verbessern und die Bedingung konkretisieren, sodass sie extrahiert und sogar wiederverwendet werden kann. Es ist auch einfach, Methoden zu aktualisieren, wenn sich die Bedingungen ändern. Da eine Methode einen aussagekräftigen Namen hat, spiegelt er den Zweck des Codes wider und erleichtert die Lesbarkeit des Codes.
in kleineren Teilen
zu konzentrieren, bevor Sie mit der Programmierung fortfahren. Wenn Sie während der Lösung eines dringenden Problems weiter programmieren, wird die Funktion immer länger. Auf lange Sicht ist das kein Problem, aber Sie sollten daran denken, noch einmal zurückzugehen und es in kleinere Teile umzugestalten.
Refactoring ist eine gute Idee, aber Sie sollten es sich zur Gewohnheit machen, kürzeren, fokussierteren Code zu schreiben. Kurze Methoden können in einem Fenster gelesen werden und sind leicht zu verstehen. Wenn eine Methode zu lang ist, um in einem Fenster gelesen zu werden, wird es schwierig, ihr zu folgen, da man nicht schnell die gesamte Idee von Anfang bis Ende verfolgen kann.
Beim Erstellen von Methoden sollten Sie sich angewöhnen, dass jede Methode nur eine Aufgabe erfüllt. Dies ist eine gute Angewohnheit, denn erstens ist es wahrscheinlicher, dass eine Methode wiederverwendet wird, wenn sie nur eines tut. Drittens ist eine solche Methode leicht zu verstehen und zu ändern.
Schlechte Angewohnheit: Zu lange Methoden (tun zu viele Dinge)
Listing 3 zeigt eine sehr lange Funktion, die viele Probleme hat. Es macht viele Dinge, daher ist es nicht kompakt genug. Es ist auch einfacher zu lesen, zu debuggen und zu testen. Zu den Aufgaben gehören das Durchlaufen einer Datei, das Erstellen einer Liste, das Zuweisen von Werten zu jedem Objekt, das Durchführen von Berechnungen und mehr.
Listing 3. Schlechte Angewohnheit: zu lange Funktion
<?php
function writeRssFeed($user)
{
//DB-Verbindungsinformationen abrufen
// Benutzerpräferenzen nachschlagen...
$link = mysql_connect('mysql_host', 'mysql_user', 'mysql_password')
ODER die(mysql_error());
// Abfrage
$perfsQuery = sprintf("SELECT max_stories FROM user_perfs WHERE user= '%s'",
mysql_real_escape_string($user));
$result = mysql_query($query, $link);
$max_stories = 25; // standardmäßig 25;
if ($row = mysql_fetch_assoc($result)) {
$max_stories = $row['max_stories'];
}
// Geh und hol meine Daten
$perfsQuery = sprintf("SELECT * FROMstories WHERE post_date = '%s'",
mysql_real_escape_string());
$result = mysql_query($query, $link);
$feed = "＜rss version="2.0"＞" .
„<Kanal>“ .
„＜title＞Mein toller Feed＜/title＞“ .
„＜link＞ http://www.example.com/feed.xml ＜/link＞“ .
„＜description＞Der beste Feed der Welt＜/description＞“ .
„＜Sprache＞en-us＜/Sprache＞“ .
„＜pubDate＞Tue, 20. Okt. 2008 10:00:00 GMT＜/pubDate＞“ .
„＜lastBuildDate＞Tue, 20. Okt. 2008 10:00:00 GMT＜/lastBuildDate＞“ .
„＜docs＞ http://www.example.com/rss ＜/docs＞“ .
„<generator>MyFeed Generator</generator>“ .
„＜managingEditor＞ [email protected] ＜/managingEditor＞“ .
„＜webMaster＞ [email protected] ＜/webMaster＞“ .
„＜ttl＞5＜/ttl＞“;
// Den Feed erstellen...
while ($row = mysql_fetch_assoc($result)) {
$title = $row['title'];
$link = $row['link'];
$description = $row['description'];
$date = $row['date'];
$guid = $row['guid'];
$feed .= "<item>";
$feed .= "＜title＞" . $title .
$feed .= "＜link＞" . $link .
$feed .= "＜description＞ " $description .
$feed .= "＜pubDate＞" . $date .
$feed .= "＜guid＞" . $guid .
$feed .= "＜/item＞";
}
$feed .= "＜/rss";
// den Feed auf den Server schreiben...
echo($feed);
}
?>Wenn Sie noch ein paar Methoden wie diese schreiben, wird die Wartung zu einem echten Problem.
Gute Angewohnheit: Verwaltbare, funktionsspezifische Methodenliste
4 Schreiben Sie die ursprüngliche Methode in eine kompaktere, lesbarere Methode um. In diesem Beispiel wird eine lange Methode in mehrere kurze Methoden zerlegt, und jede kurze Methode ist für eine Sache verantwortlich. Ein solcher Code ist für zukünftige Wiederverwendung und Tests sehr hilfreich.
Listing 4. Bewährte Vorgehensweise: einfach zu verwaltender, funktionsspezifischer Ansatz
<?php
function createRssHeader()
{
return „<rss version="2.0">“ .
„<Kanal>“ .
„＜title＞Mein toller Feed＜/title＞“ .
„＜link＞ http://www.example.com/feed.xml ＜/link＞“ .
„＜description＞Der beste Feed der Welt＜/description＞“ .
„＜Sprache＞en-us＜/Sprache＞“ .
„＜pubDate＞Tue, 20. Okt. 2008 10:00:00 GMT＜/pubDate＞“ .
„＜lastBuildDate＞Tue, 20. Okt. 2008 10:00:00 GMT＜/lastBuildDate＞“ .
„＜docs＞ http://www.example.com/rss ＜/docs＞“ .
„<generator>MyFeed Generator</generator>“ .
„＜managingEditor＞ [email protected] ＜/managingEditor＞“ .
„＜webMaster＞ [email protected] ＜/webMaster＞“ .
„＜ttl＞5＜/ttl＞“;
}
Funktion createRssFooter()
{
return „＜/channel＞＜/rss＞“;
}
Funktion createRssItem($title, $link, $desc, $date, $guid)
{
$item .= "＜item＞";
$item .= "＜title＞" . $title .
$item .= "＜link＞" . $link .
$item .= "＜description＞ " $description .
$item .= "＜pubDate＞" . $date .
$item .= "＜guid＞" . $guid .
$item .= "＜/item＞";
return $item;
}
Funktion getUserMaxStories($db_link, $default)
{
$perfsQuery = sprintf("SELECT max_stories FROM user_perfs WHERE user= '%s'",
mysql_real_escape_string($user));
$result = mysql_query($perfsQuery, $db_link);
$max_stories = $default;
if ($row = mysql_fetch_assoc($result)) {
$max_stories = $row['max_stories'];
}
return $max_stories;
}
Funktion writeRssFeed($user)
{
//DB-Verbindungsinformationen abrufen
$settings = parse_ini_file("rss_server.ini");
// Benutzerpräferenzen nachschlagen...
$link = mysql_connect($settings['db_host'], $settings['user'],
$settings['password']) OR die(mysql_error());
$max_stories = getUserMaxStories($link, 25);
// Geh und hol meine Daten
$newsQuery = sprintf("SELECT * FROMstories WHERE post_date = '%s'",
mysql_real_escape_string(time()));
$result = mysql_query($newsQuery, $link);
$feed = createRssHeader();
$i = 0;
// Den Feed erstellen...
while ($row = mysql_fetch_assoc($result)) {
if ($i < $max_stories) {
$title = $row['title'];
$link = $row['link'];
$description = $row['description'];
$date = $row['date'];
$guid = $row['guid'];
$feed .= createRssItem($title, $link, $description, $date, $guid);
$i++;
} anders {
brechen;
}
}
mysql_close($link);
$feed .= createRssFooter();
// den Feed auf den Server schreiben...
echo($feed);
}
?> Es gibt auch Einschränkungen bei der Aufteilung langer Methoden in kurze Methoden, und eine übermäßige Aufteilung ist kontraproduktiv. Missbrauchen Sie diese gute Angewohnheit daher nicht. Das Aufteilen von Code in große Teile kann das Lesen ebenso erschweren wie das Nichtaufteilen von langem Code.
Hinzufügen von Kommentaren zu Ihrem Code
Das Hinzufügen guter Kommentare zu Ihrem Code kann manchmal genauso schwierig erscheinen wie das Schreiben des Codes. Es ist nicht einfach zu wissen, was mit Anmerkungen versehen werden soll, da wir häufig dazu neigen, mit Anmerkungen zu versehen, was der Code gerade tut. Es ist eine gute Idee, den Zweck Ihres Codes zu kommentieren. Im weniger offensichtlichen Headerblock der Funktion wird der Leser über die Ein- und Ausgaben der Methode sowie das ursprüngliche Ziel der Methode informiert.
Es ist üblich, auszukommentieren, was der Code gerade tut, aber das ist unnötig. Wenn der Code komplex ist und Sie auskommentieren müssen, was er gerade tut, empfiehlt dies, den Code neu zu schreiben, um ihn verständlicher zu machen. Lernen Sie, gute Namen und kürzere Methoden zu verwenden, um Ihren Code lesbarer zu machen, ohne Kommentare zu geben, die ihren Zweck erläutern.
Schlechte Angewohnheit: Über- oder Unterkommentierung von Funktionen
Die Kommentare in Listing 5 sagen dem Leser nur, was der Code tut – er durchläuft eine Schleife oder fügt eine Zahl hinzu. Aber es ignoriert, warum es seinen aktuellen Job macht. Dies führt dazu, dass die Leute, die den Code pflegen, nicht wissen, ob der Code sicher geändert werden kann (ohne dass neue Fehler entstehen).
Listing 5. Schlechte Angewohnheit: Zu viele oder nicht genug Funktionskommentare
<?php-
Klasse ResultMessage
{
privater $Schweregrad;
private $message;
öffentliche Funktion __construct($sev, $msg)
{
$this->severity = $sev;
$this->message = $msg;
}
öffentliche Funktion getSeverity()
{
return $this->severity;
}
öffentliche Funktion setSeverity($severity)
{
$this->severity = $severity;
}
öffentliche Funktion getMessage()
{
return $this->message;
}
öffentliche Funktion setMessage($msg)
{
$this->message = $msg;
}
}
Funktion cntMsgs($messages)
{
$n = 0;
/* durch die Nachrichten iterieren... */
foreach($messages as $m) {
if ($m->getSeverity() == 'Error') {
$n++; // eins zum Ergebnis hinzufügen;
}
}
return $n;
}
$messages = array(new ResultMessage("Fehler", "Das ist ein Fehler!"),
new ResultMessage("Warnung", "Dies ist eine Warnung!"),
new ResultMessage("Error", "Dies ist ein weiterer Fehler!"));
$errs = cntMsgs($messages);
echo("Es gibt " . $errs . " Fehler in der result.n"
?>
Gute Praxis: Annotierte Funktionen und Klassen
Die Kommentare in Listing 6 informieren den Leser über Klassen und Methoden Zweck. Dieser Kommentar erklärt, warum der Code seine aktuelle Aufgabe erfüllt, was bei der zukünftigen Wartung des Codes nützlich sein kann. Der Code muss möglicherweise geändert werden, wenn sich die Bedingungen ändern. Änderungen sind jedoch einfach, wenn der Zweck des Codes leicht verständlich ist.
Listing 6. Gute Praxis: annotierte Funktionen und Klassen
<?php
/**
* Die ResultMessage-Klasse enthält eine Nachricht, die zurückgegeben werden kann
* als Ergebnis eines Prozesses Die Nachricht hat einen Schweregrad und
* Nachricht.
*
* @author nagood
*
*/
Klasse ResultMessage
{
privater $Schweregrad;
private $message;
/**
* Konstruktor für die ResultMessage, der Ihnen die Zuweisung ermöglicht
* Schweregrad und Nachricht.
* @param $sev Siehe {@link getSeverity()}
* @param $msg
* @return unbekannter_Typ
*/
öffentliche Funktion __construct($sev, $msg)
{
$this->severity = $sev;
$this->message = $msg;
}
/**
* Gibt den Schweregrad der Nachricht zurück. Sollte eins sein
* „Information“, „Warnung“ oder „Fehler“.
* @return string Schweregrad der Nachricht
*/
öffentliche Funktion getSeverity()
{
return $this->severity;
}
/**
* Legt den Schweregrad der Nachricht fest
* @param $severity
* @return void
*/
öffentliche Funktion setSeverity($severity)
{
$this->severity = $severity;
}
öffentliche Funktion getMessage()
{
return $this->message;
}
öffentliche Funktion setMessage($msg)
{
$this->message = $msg;
}
}
/*
* Zählt die Nachrichten mit dem angegebenen Schweregrad im Array
* von Nachrichten.
*
* @param $messages Ein Array von ResultMessage
* @return int Anzahl der Nachrichten mit dem Schweregrad „Fehler“
*/
Funktion countErrors($messages)
{
$matchingCount = 0;
foreach($messages as $m) {
if ($m->getSeverity() == "Fehler") {
$matchingCount++;
}
}
return $matchingCount;
}
$messages = array(new ResultMessage("Fehler", "Das ist ein Fehler!"),
new ResultMessage("Warnung", "Dies ist eine Warnung!"),
new ResultMessage("Error", "Dies ist ein weiterer Fehler!"));
$errs = countErrors($messages);
echo("Es gibt " . $errs . " Fehler im Ergebnis.n")
;
Umgang mit Fehlern
Als allgemeine Faustregel gilt: Wenn Sie robuste Anwendungen schreiben möchten, befolgen Sie die 80/20-Regel für die Fehlerbehandlung: 80 % Ihres Codes werden für die Behandlung von Ausnahmen und Validierung verwendet, und 20 % Ihres Codes werden dafür verwendet die eigentliche Arbeit. Dies geschieht häufig beim Codieren der Grundlogik (Happy-Path) eines Programms. Das bedeutet, Code zu schreiben, der unter der Haube funktioniert, dass alle Daten verfügbar sind und alle Bedingungen wie erwartet sind. Ein solcher Code kann während des Lebenszyklus der Anwendung fragil sein. Im anderen Extremfall nimmt es viel Zeit in Anspruch, Code für Bedingungen zu schreiben, die Sie noch nie zuvor erlebt haben.
Diese Angewohnheit erfordert, dass Sie genügend Fehlerbehandlungscode schreiben, anstatt Code zu schreiben, der alle Fehler behandelt, sodass der Code nie abgeschlossen wird.
Schlechte Angewohnheiten: Überhaupt keine Fehlerbehandlung Der Code
in Listing 7 zeigt zwei schlechte Angewohnheiten. Erstens werden die Eingabeparameter nicht überprüft, obwohl bekannt ist, dass Parameter in bestimmten Zuständen Ausnahmen in der Methode verursachen. Zweitens ruft der Code eine Methode auf, die möglicherweise eine Ausnahme auslöst, die Ausnahme jedoch nicht behandelt. Wenn ein Problem auftritt, kann der Autor des Codes oder die Person, die den Code verwaltet, die Ursache des Problems nur vermuten.
Listing 7. Schlechte Angewohnheit: Fehlerbedingungen nicht behandeln
<?php
// Den tatsächlichen Namen des abrufen
Funktion „convertDayOfWeekToName($day)“
{
$dayNames = array(
"Sonntag",
"Montag",
"Dienstag",
"Mittwoch",
"Donnerstag",
"Freitag",
"Samstag");
return $dayNames[$day];
}
echo("Der Name des 0-Tages ist: " . ConvertDayOfWeekToName(0) . "n");
echo("Der Name des 10. Tages lautet: " . ConvertDayOfWeekToName(10) . "n");
echo("Der Name des 'orangen' Tages ist: " . convertDayOfWeekToName('orange') . "n")
;
Bewährte Vorgehensweise: Behandeln von Ausnahmen.
In Listing 8 wird das Auslösen und Behandeln von Ausnahmen auf sinnvolle Weise veranschaulicht. Eine zusätzliche Fehlerbehandlung macht den Code nicht nur robuster, sondern verbessert auch die Lesbarkeit des Codes und erleichtert so das Verständnis. Die Art und Weise, wie Ausnahmen behandelt werden, ist ein guter Hinweis auf die Absicht des ursprünglichen Autors beim Schreiben der Methode.
Listing 8. Bewährte Vorgehensweise: Umgang mit Ausnahmen
<?php
/**
* Dies ist die Ausnahme, die ausgelöst wird, wenn der Wochentag ungültig ist.
* @author nagood
*
*/
Klasse InvalidDayOfWeekException erweitert Ausnahme { }
Klasse InvalidDayFormatException erweitert Ausnahme { }
/**
* Ruft den Namen des Tages in der Woche ab
* Gibt einen Fehler zurück, wenn der angegebene Wert außerhalb des zulässigen Bereichs liegt.
*
* @param $day
* @return unbekannter_Typ
*/
Funktion „convertDayOfWeekToName($day)“
{
if (! is_numeric($day)) {
throw new InvalidDayFormatException('Der Wert '' . $day . '' ist ein ' .
'ungültiges Format für einen Wochentag.');
}
if (($day ＞ 6) || ($day ＜ 0)) {
throw new InvalidDayOfWeekException('Die Tagesnummer '' . $day . '' ist eine ' .
'ungültiger Wochentag. Es wird 0-6 erwartet.');
}
$dayNames = array(
"Sonntag",
"Montag",
"Dienstag",
"Mittwoch",
"Donnerstag",
"Freitag",
"Samstag");
return $dayNames[$day];
}
echo("Der Name des 0-Tages ist: " . ConvertDayOfWeekToName(0) . "n");
try {
echo("Der Name des 10. Tages lautet: " . ConvertDayOfWeekToName(10) . "n");
} Catch (InvalidDayOfWeekException $e) {
echo ("Beim Versuch, den Wert zu konvertieren, ist ein Fehler aufgetreten: " . $e->getMessage() . "n");
}
versuchen {
echo("Der Name des 'orangen' Tages ist: " . convertDayOfWeekToName('orange') . "n");
} Catch (InvalidDayFormatException $e) {
echo ("Beim Versuch, den Wert zu konvertieren, ist ein Fehler aufgetreten: " . $e->getMessage() . "n");
}
?>
Obwohl das Überprüfen von Parametern eine Bestätigung ist – wenn Sie Parameter benötigen, die sich in einem bestimmten Zustand befinden müssen, ist dies für die Benutzer der Methode hilfreich – sollten Sie sie überprüfen und sinnvolle Ausnahmen auslösen:
◆ Behandeln Sie Ausnahmen so genau wie möglich. Die Probleme die entstehen, hängen eng zusammen.
◆Dedizierte Behandlung jeder Ausnahme.
Verwenden Sie kein Kopieren und Einfügen.
Sie können Code von einer anderen Stelle in Ihren Code-Editor kopieren und einfügen, dies hat jedoch Vor- und Nachteile. Das Gute daran ist, dass durch das Kopieren von Code aus einem Beispiel oder einer Vorlage viele Fehler vermieden werden können. Der Nachteil ist, dass dies leicht zu vielen ähnlichen Programmiermethoden führt.
Achten Sie darauf, keinen Code von einem Teil der Anwendung in einen anderen zu kopieren und einzufügen. Wenn Sie so sind, beenden Sie diese schlechte Angewohnheit und überlegen Sie, diesen Code so umzuschreiben, dass er wiederverwendbar ist. Im Allgemeinen erleichtert die Speicherung des Codes an einer Stelle die spätere Wartung, da er nur an einer Stelle geändert werden muss.
Schlechte Angewohnheiten: Ähnliche Codeschnipsel
in Listing 9 zeigen mehrere Methoden, die nahezu identisch sind, jedoch unterschiedliche Werte haben. Es gibt Tools, die dabei helfen können, kopierten und eingefügten Code zu finden (siehe Ressourcen).
Listing 9. Schlechte Angewohnheiten: ähnliche Codeschnipsel
<?php
/**
* Zählt die Anzahl der im Array gefundenen Nachrichten
* ResultMessage mit dem getSeverity()-Wert „Error“
*
* @param $messages Ein Array von ResultMessage
* @return unbekannter_Typ
*/
Funktion countErrors($messages)
{
$matchingCount = 0;
foreach($messages as $m) {
if ($m->getSeverity() == "Fehler") {
$matchingCount++;
}
}
return $matchingCount;
}
/**
* Zählt die Anzahl der im Array gefundenen Nachrichten
* ResultMessage mit dem getSeverity()-Wert „Warning“
*
* @param $messages Ein Array von ResultMessage
* @return unbekannter_Typ
*/
Funktion countWarnings($messages)
{
$matchingCount = 0;
foreach($messages as $m) {
if ($m->getSeverity() == "Warning") {
$matchingCount++;
}
}
return $matchingCount;
}
/**
* Zählt die Anzahl der im Array gefundenen Nachrichten
* ResultMessage mit dem getSeverity()-Wert „Information“
*
* @param $messages Ein Array von ResultMessage
* @return unbekannter_Typ
*/
Funktion countInformation($messages)
{
$matchingCount = 0;
foreach($messages as $m) {
if ($m->getSeverity() == "Information") {
$matchingCount++;
}
}
return $matchingCount;
}
$messages = array(new ResultMessage("Fehler", "Das ist ein Fehler!"),
new ResultMessage("Warnung", "Dies ist eine Warnung!"),
new ResultMessage("Error", "Dies ist ein weiterer Fehler!"));
$errs = countErrors($messages);
echo("Es gibt " . $errs . " Fehler in der result.n");
?>
Gute Praxis: Wiederverwendbare Funktionen mit Parametern
Listing 10 zeigt den geänderten Code, der den kopierten Code in eine Methode einfügt. Eine weitere Methode wurde ebenfalls geändert und delegiert nun Aufgaben an die neue Methode. Die Entwicklung eines gemeinsamen Ansatzes nimmt Zeit in Anspruch und ermöglicht es Ihnen, innezuhalten und nachzudenken, anstatt instinktiv zu kopieren und einzufügen. Aber die Zeit, die in ein gemeinsames Vorgehen investiert wird, wird sich auszahlen, wenn Änderungen notwendig sind.
Listing 10. Gute Praxis: wiederverwendbare Funktionen mit Parametern
<?php
/*
* Zählt die Nachrichten mit dem angegebenen Schweregrad im Array
* von Nachrichten.
*
* @param $messages Ein Array von ResultMessage
* @return int Anzahl der Nachrichten, die mit $withSeverity übereinstimmen
*/
Funktion countMessages($messages, $withSeverity)
{
$matchingCount = 0;
foreach($messages as $m) {
if ($m->getSeverity() == $withSeverity) {
$matchingCount++;
}
}
return $matchingCount;
}
/**
* Zählt die Anzahl der im Array gefundenen Nachrichten
* ResultMessage mit dem getSeverity()-Wert „Error“
*
* @param $messages Ein Array von ResultMessage
* @return unbekannter_Typ
*/
Funktion countErrors($messages)
{
return countMessages($messages, "Errors");
}
/**
* Zählt die Anzahl der im Array gefundenen Nachrichten
* ResultMessage mit dem getSeverity()-Wert „Warning“
*
* @param $messages Ein Array von ResultMessage
* @return unbekannter_Typ
*/
Funktion countWarnings($messages)
{
return countMessages($messages, "Warning");
}
/**
* Zählt die Anzahl der im Array gefundenen Nachrichten
* ResultMessage mit dem getSeverity()-Wert „Warning“
*
* @param $messages Ein Array von ResultMessage
* @return unbekannter_Typ
*/
Funktion countInformation($messages)
{
return countMessages($messages, "Information");
}
$messages = array(new ResultMessage("Fehler", "Das ist ein Fehler!"),
new ResultMessage("Warnung", "Dies ist eine Warnung!"),
new ResultMessage("Error", "Dies ist ein weiterer Fehler!"));
$errs = countErrors($messages);
echo("Es gibt " . $errs . " Fehler in der result.n");
?＞
Fazit
Wenn Sie beim Schreiben von PHP-Code die in diesem Artikel besprochenen guten Gewohnheiten entwickeln, werden Sie dies tun in der Lage sein, Code zu erstellen, der leicht zu lesen, zu verstehen und zu warten ist. Wartbarer Code, der auf diese Weise erstellt wird, verringert das Risiko des Debuggens, Korrigierens und Erweiterns des Codes.
Die Verwendung guter Namen und kürzerer Methoden verbessert die Lesbarkeit des Codes. Der Zweck des Kommentierens von Code besteht darin, das Verständnis und die Erweiterung des Codes zu erleichtern. Der richtige Umgang mit Fehlern macht Ihren Code robuster. Hören Sie schließlich auf, Kopieren und Einfügen zu verwenden, um Ihren Code sauber zu halten und die Wiederverwendbarkeit zu verbessern.