Ich bin überrascht, dass der Code des Projekts, an dem ich arbeite, zu schmutzig ist. Es wurde ursprünglich nicht von uns geschrieben, sondern erbte den Code einer anderen Firma (ein sehr berühmter Ort). Hmmm, haben Sie den vom Erstklässler geschriebenen Code ohne Codeüberprüfung veröffentlicht? ?? Oder wird es von jemandem geschrieben, der nur in anderen Sprachen schreiben kann (wahrscheinlich C-Sprache ...?) Und die Codeüberprüfung wird unten weggelassen? ?? Es ist nutzlos knifflig und funktioniert es überhaupt nicht gut? ?? ?? Das ist ein ehrlicher Eindruck. Deshalb habe ich beschlossen, die gesamte zu modifizierende Klasse umzugestalten, damit es keinen Sinn macht, sie mit dem Originalcode zu vergleichen und JUnit vollständig neu zu schreiben. ... Es scheint, dass die Fehler nicht in die Reparatur eingebettet werden ... Nachdem ich es ausführlich gelesen hatte, fand ich eine Reihe von Fehlern. Nun, JUnit ist auch voller Löcher, so dass es unvermeidlich sein kann. Nun, ich konnte es damit veröffentlichen! ?? Aus diesem Grund habe ich von oben gehört, dass "Materialien für die gemeinsame Umgestaltung von Beispielen und Trends erstellt werden". Daher möchte ich, dass Sie sich beim Schreiben von Java ♡ dessen bewusst sind. Der Inhalt ist flauschig und für neue Programmierer. Ich denke, Veteranen tun es wahrscheinlich unbewusst. ** Die Reihenfolge, in der die Überschriften aufgeführt sind, ist die Reihenfolge, in der sie angezeigt wurden, nicht die Reihenfolge der Priorität. ** Ich möchte, dass du dir über alles bewusst bist.
** Beachten Sie von Anfang an, dass der Code, den Sie bei der Arbeit schreiben, nicht nur von Ihnen selbst, sondern auch von anderen gelesen wird **. Und selbst wenn Sie es selbst schreiben, wird es im Laufe der Zeit genauso schwer zu lesen sein, wie es jemand anderes geschrieben hat. Können Sie sagen, dass Sie Wartungs- und Reparaturarbeiten bis zum Ende des Systems selbst durchführen können, selbst wenn Sie sich um die Freigabe und Fehlerbehandlung kümmern?
** Geben Sie Projekten, deren Codierungsstandards zu befolgen sind, höchste Priorität. Die Einhaltung von Kodierungsstandards ist die Grundhaltung. ** ** **
** Wahnsinnig wichtig. ** Führt direkt zur Lesbarkeit. Code, der als Ergebnis im Geschäftsleben geschrieben wurde, wird grundsätzlich von anderen Personen als Ihnen selbst gelesen. Ich werde es reparieren. Wenn Sie ihm einen Namen geben, den Sie zu diesem Zeitpunkt nicht verstehen können, bleibt er normalerweise hängen. ~~ Ich kann es nicht lesen! Ich bin kurz davor rauszulaufen. ~~
Angenommen, Sie deklarieren drei String-Variablen. Dann str1, str2, str3 ... in der Reihenfolge der Verwendung Was ist str1 auf den ersten Blick! ?? Es wird sein. Ich kenne nur den Typ. ~~ Wenn Sie sich die Deklaration des Typs ansehen, können Sie sie auf einen Schlag sehen. ~~ Es ist das gleiche wie keine Informationen zu haben. Mit einem solchen Namen kennen Sie sich vielleicht eine Woche später nicht einmal, geschweige denn einen Monat später. Ist ein Ingenieur, der den Code, den er geschrieben hat, nicht einmal lesen kann, nicht zu cool? ?? Geben Sie ihm einen sinnvollen Namen.
Grundsätzlich wird es in Java wie folgt benannt. ** Befolgen Sie gegebenenfalls die Codierungskonventionen. ** ** ** Ich sehe es oft, aber es ist nicht gut, dass die Variablennamen eine Mischung aus Schlangen- und Kamelfällen sind. Lassen Sie uns zumindest innerhalb der Klasse vereinheitlichen. Es ist nicht gut, Englisch und Romaji zu mischen. Wie "Chohyo erstellen". Sie können "Bericht erstellen" verwenden. Warum machst du "Formen" in römischen Schriftzeichen? Googeln Sie englische Wörter, die Sie nicht verstehen. Mit Ausnahme von Fällen wie DB-Tabellendefinitionen, die mit römischen Zeichen gemischt sind und Variablen sind, in denen DB-Elemente gespeichert sind.
Wenn es sich um eine sehr temporäre Variable mit einem kurzen Gültigkeitsbereich handelt, kann es sich um str von String oder num von int handeln. Erweiterung für Schleifenvariablen. Dies ist jedoch eine Geschichte, die nur zulässig ist, wenn die Absicht der Variablen in einem kurzen Bereich leicht zu verstehen ist und es im Grunde besser ist, sie richtig zu benennen. ** Geben Sie jedoch üblichen Variablennamen mit eingeschränkter Verwendung keine Originalität **. Insbesondere das "e" und "ex" der Ausnahme in der try-catch-Klausel und das "i" und "j" der Zählervariablen der for-Schleife. Wenn sie Ihnen Originalität verleihen, nimmt die Lesbarkeit ab. Sie können es so lassen, wie es ist. Vermeiden Sie außerdem die Verwendung üblicher Variablennamen für Variablen anderer Verwendungszwecke und Typen.
In Qiita gibt es viele Artikel über bestimmte Benennungsmethoden und Tipps. Versuchen Sie, nach etwas wie "Java Naming" zu suchen. Bitte lesen Sie mehrere Artikel parallel. ** Es ist schlecht zu fühlen, dass Sie nur durch das Lesen eines einzelnen Artikels verstehen. ** ** **
Versuchen Sie, die Anzahl der Zweige zu reduzieren und die Benennung entsprechend dem Inhalt vorzunehmen. Auch wenn sie weggelassen werden, werden einfache, die keine Kommentare erfordern, weggelassen. Wie wir oft sehen, ist das Deklarieren von Variablen in irgendeiner Weise weniger lesbar. Wenn Sie einen Wert speichern, für den nur eine kurze Beschreibung erforderlich ist, auf die in einer Variablen nur einmal verwiesen wird, erhöht sich die zu lesende Beschreibung entsprechend. Besonders wenn der Anwendungsbereich groß ist. Wenn es in einer Variablen gespeichert ist, wird oft angenommen, dass der Wert notwendig ist, da in der nachfolgenden Verarbeitung darauf verwiesen wird. Im Fall von Methodenketten, Methodenverschachtelung, Verkettung von Zeichenfolgen usw., bei denen die Beschreibung möglicherweise zu lang oder zu kompliziert ist, ist es meiner Meinung nach besser, sie in einer Variablen zu speichern, die angesichts der Einfachheit des Debuggens angemessen ist.
Selbst für eine Klasse oder sogar eine Methode ist es umso wahrscheinlicher, dass Fehler auftreten, je mehr Zeilen vorhanden sind. Außerdem nimmt die Anzahl der einfachen Tests und die Anzahl der Schritte zu. Gut lesbarer Code ist oft übersichtlich organisiert. Mit anderen Worten, es ist kein langer Code. Andere können nicht lesen ~~ Unlesbar ~~ Schwer zu lesender Code ist eine Brutstätte von Fehlern. Es besteht eine hohe Wahrscheinlichkeit, dass die verantwortliche Person während einer Untersuchung oder Reparatur die Hölle sieht (wahres Gesicht).
Es funktioniert wie erwartet, aber es ist nicht korrekt, "== true" und "== false" in der ** if-Anweisung ** zu beschreiben. Die if-Anweisung von Java wertet nur boolesche Werte aus, sodass das folgende schlechte Beispiel nur in den Papierkorb verschoben wird. Was tun mit verschachtelten booleschen Urteilen?
//Bedingte Beurteilung der überflüssigen if-Erklärung
//Schlechtes Beispiel
if (Bedingung A.== true &&Bedingung B.== false) {
}
//Gutes Beispiel
if (Bedingung A.&& !Bedingung B.) {
}
Im Folgenden finden Sie einige häufig auftretende schlechte Beispiele für Variablendeklarationen und Wertinitialisierungen. Es ist auch bedeutungsloser und redundanter Code, wenn die Zuweisung nur die Initialisierung überschreibt.
//Redundante Variablendeklaration Es macht keinen Sinn, den Wert zum Zeitpunkt der Deklaration einfach zu überschreiben
//Schlechtes Beispiel Nr. 1 Es ist nicht immer erforderlich, mit null zu initialisieren
List<String> list = null;
list = new ArrayList<String>(Arrays.asList(new String[]{"ABC", "123"}));
//Schlechtes Beispiel # 2 Die Initialisierung muss nicht neu sein
List<String> list = new ArrayList<String>(0);
list = new ArrayList<String>(Arrays.asList(new String[]{"ABC", "123"}));
//Schlechtes Beispiel Nr. 3: Deklaration und Initialisierung müssen nicht getrennt werden
List<String> list;
list = new ArrayList<String>(Arrays.asList(new String[]{"ABC", "123"}));
//Gutes Beispiel: Wenn Sie ersetzen, initialisieren Sie nicht unnötig gleichzeitig mit der Deklaration
List<String> list = new ArrayList<String>(Arrays.asList(new String[]{"ABC", "123"}));
Nehmen Sie den Fall, in dem die Zuordnung zur Variablen selbst im Zusammenhang mit der Deklaration und Initialisierung der obigen Variablen verzweigt. In diesem Fall ist es sinnvoll, die Deklaration und Zuweisung zu einem separaten Schritt zu machen. Wenn jedoch nur zwei Muster vorhanden sind, können Sie nur "if" anstelle von "if ~ else" schreiben. Selbst wenn 3 oder mehr Verzweigungsmuster vorhanden sind, sollten Sie die if-Anweisung optimieren. Wenn es sich um eine Verzweigung nach Aufzählungstyp handelt, ist es auch nützlich, eine "switch" -Anweisung abzugeben.
//Wenn sich die Aufgabe selbst verzweigt(Nur 2 Verzweigungsmuster)
//Redundantes Beispiel
String str = null;
if (Bedingung A.) {
str = "ABC";
} else {
str = "123";
}
//Beispiel für das Löschen unnötiger Zweige
String str = "123";
if (Bedingung A.) {
str = "ABC";
}
//Bei Verwendung des ternären Operators
String str =Bedingung A.? "ABC" : "123";
Wenn die Ableitung des Werts, der der Bedingung A oder str zugewiesen werden soll, nicht einfach ist, kann der obige Code auf eine Zeile von "String str = call other method;" gesetzt werden, sodass der Rückgabewert eine andere Methode mit dem Wert von str ist. Ich finde es gut, das zu tun. Die Vor- und Nachteile der Verwendung nur eines weniger komplizierten Prozesses als separate Methode können vom Code-Prüfer abhängen. ** Sofern dies nicht durch Codierungskonventionen verboten ist, ** empfiehlt es auch die Verwendung von ternären Operatoren, wenn Werte unter einfachen Bedingungen geändert werden. Die Verwendung von ternären Operatoren sollte jedoch auf einfache Zweige beschränkt sein. Wenn mehrere Bedingungen vorliegen oder die Bedingungen oder Zweige verschachtelt sind, wird die Lesbarkeit verringert. Beenden Sie sie daher.
Implementieren Sie vorhandene Funktionen nicht selbst. Die Herstellung und Prüfung ist eine Verschwendung, die Sie sonst nicht bezahlen müssten. Weit davon entfernt, bedeutungslos zu sein, ist es ein Minus.
Ich sehe es sehr oft, aber es scheint, dass die Bibliothek apache.commons verfügbar ist, aber nur die Standard-API verwendet wird. Sie können sehen, dass die Methode durch die Kombination von Standard-APIs erstellt wird, auch wenn die allgemeine Klasse schlecht abgeschnitten ist. Natürlich weiß ich, dass es Fälle gibt, in denen die Version der Commons-Bibliothek niedrig ist und es keine geeignete Methode gibt oder die Commons-Bibliothek überhaupt nicht verwendet werden kann, und wenn ja, kann nicht geholfen werden. Es ist nicht gut, freiwillig Räder neu zu entwickeln, die verwendet, aber nicht verwendet werden können. Es ist auch eine schlechte Idee, eine gemeinsame Klasse in Ihrem Projekt zu haben und dort zu deklarieren, aber verwenden Sie sie nicht.
//Überprüfen Sie, ob die Zeichenfolge null oder leer ist
//Schlechtes Beispiel
if (str == null || str.isEmpty()) {
}
//Gutes Beispiel
if (StringUtils.isEmpty(str)) {
}
//Wenn die Zeichenfolge null oder zugeschnitten ist und leer ist, konvertieren Sie sie in die angegebene Zeichenfolge
//Schlechtes Beispiel
String str = value;
if (StringUtils.isBlank(str)) {
str = "Nicht festgelegt";
}
//Gutes Beispiel
String str = StringUtils.defaultIfBlank(value, "Nicht festgelegt");
//Objekt-Null-Prüfung
//Schlechtes Beispiel
if (obj == null) {
}
//Gutes Beispiel
if (Objects.isNull(obj)) {
}
Das Durchsuchen des Webs und das Überprüfen, ob die Funktion in der von Ihnen verwendeten Bibliothek vorhanden ist, kostet viel Geld. Die Neuentwicklung der Räder, die sich darum kümmert, ist jedoch eher ein Minus als ein Plus. Tu es nicht. Sobald Sie den Code geschrieben haben, müssen Sie so viel testen, wie Sie schreiben. Bei vorhandenen Funktionen müssen Sie diesen Teil nicht detailliert testen. Wenn es sich um eine Commons-Bibliothek handelt, wird sie auf der ganzen Welt verwendet und funktioniert fast garantiert, wenn keine Fehler vorliegen. Es wäre vielmehr eine großartige Leistung, herauszufinden, ob es richtig verwendet wurde, einen Fehler zu verursachen und es der OSS-Community zu melden. Es ist ein Level, auf das Sie stolz sein können. Aber wenn Sie es selbst schreiben, müssen Sie alles testen. Niemand garantiert den Betrieb. Aber dieser Test ist nutzlos. Wenn Sie ein Smartphone haben, können Sie es auf Ihrem Smartphone nachschlagen, um die Telefonnummer des Geschäfts herauszufinden, in das Sie unterwegs gehen möchten, oder? Du gehst nicht in die Telefonzelle und ziehst die Stadtseite, oder? Sie rufen nicht einmal den Telefonnummernführer an, oder? Das ist es.
** Nicht zu wissen ist keine schlechte Sache. Was schlecht ist, ist diese nachlässige Einstellung, die Sie nicht einmal kennen. ** ** ** Lassen Sie uns zumindest das Innere des Projekts überprüfen. ** Untersuchen Sie sich und wenden Sie sich an einen Experten. (Lassen Sie den Überprüfungsprozess nicht selbst aus.) Wenn die von Ihnen benötigte Funktion nicht vorhanden ist, wissen Sie, dass dies nicht der Fall ist. Wenn ja, fragen Sie einen Experten, ob er es als gemeinsame Funktion herstellen oder nur in dem Teil beschreiben soll, für das Sie verantwortlich sind. Die im konkreten Beispiel gezeigte Commons-Bibliothek ist je nach Version möglicherweise nicht vorhanden. Selbst wenn ein Verwendungsbeispiel durch die WEB-Suche gefunden wird, gibt es möglicherweise eine Methode, die in der im verantwortlichen Projekt verwendeten Version nicht vorhanden ist. Aber das gibt Ihnen mehr Einblick.
Wenn Sie versucht haben, es herauszufinden, aber Javadoc auf Englisch schwer zu lesen ist, lesen Sie den Code direkt. In vielen Fällen ist es schneller. Die StringUtils-Commons-Klasse sagt nichts Schwieriges aus. Die meisten Methoden können auch von Anfängern gelesen werden. Die meisten Methodennamen sind leicht zu verstehen. Öffnen wir den Code des in der zuständigen Angelegenheit verwendeten Glases direkt in der IDE. Wenn Sie Eclipse verwenden, ist es möglicherweise einfacher, die gesuchte Funktion zu finden, indem Sie die Methoden mithilfe der Gliederungsansicht in ABC-Reihenfolge anordnen.
Es ist keine Schulprüfung, Sie müssen sie also nicht ins Japanische übersetzen. Es wäre schön, wenn wir grob übersetzen und direkt übersetzen könnten. Ich verlasse mich auch auf die Google-Übersetzung. Aber wenn das Sinn macht, ist es okay. Verwenden Sie, was Sie verwenden können. Sie können die Bedeutung erhalten, indem Sie die Wörter wie diese im Satz durchsuchen. Dies gilt insbesondere für verschiedene Ausnahmen. Es ist nicht gut, es einfach zu werfen, bevor Sie es tun.
Wenn Sie diese Arbeit fortsetzen möchten, ist die Aktualisierung Ihres Wissens unerlässlich. Wenn Sie nur mit dem Wissen arbeiten möchten, das Sie gelernt haben, ist dieser Job nicht geeignet.
Die Bibliotheken, die verwendet werden können, variieren je nach Angelegenheit. Sie müssen sich nicht jedes Mal an alles erinnern, aber Sie müssen es nachschlagen. Einige Leute schaffen es aufgrund des Hirntodes, aber bitte hören Sie damit auf, weil es nichts anderes ist als die Anhäufung technischer Schulden. Stapeln Sie keinen Code, der nicht geschrieben werden soll. Es ist ein schwieriges Wort, aber ich möchte, dass Sie jedes Mal, wenn Sie Schwierigkeiten haben, es zu analysieren, eine Menge Code umgestalten können. (Es gibt viele solcher Positionen)
Das Datums- und Uhrzeitmanagement von Java wurde von Datum und Kalender auf LocalDateTime geändert, oder? Mit dem Aufkommen des Pakets java.nio.file sind Dateivorgänge viel einfacher geworden, oder?
Kürzlich habe ich nach Java 8 ein neues Bauprojekt realisiert, bei dem ich keinen Versuch mit Ressourcen, keinen Lambda-Ausdruck, keine Stream-API oder keine Option sehe. … Das Wissen der Mitglieder hat aufgehört. Ich denke, dieses Muster wird häufig in Regierungsbüros und Infrastrukturverträgen verwendet. Aber es sollte neue Absolventen als Mitglieder geben. Da der umgebende Code Legacy-Code ist, schreibe ich Legacy-Code. Es ist ein schlechter Trend. Bis vor kurzem konnte ich keinen Java 8-ähnlichen Code lesen. Weil es bis zu Java6 nur einen Fall von Legacy-Code gab. Ich konnte das Verständnis selbst nach dem Lesen der Dokumente nicht einholen ... Ich konnte es nicht tun, ohne tatsächlich zu schreiben und mich zu bewegen ... Ich kann mich nicht an das Wissen erinnern, das ich nicht verwenden muss ... Ich wurde jedoch einem Java 8-Projekt zugewiesen, sodass ich mich bewusst daran erinnerte. Dank dessen habe ich mich im Laufe eines halben Monats an die Stream-API gewöhnt, so dass ich fast aufgehört habe, für Anweisungen zu schreiben. Dies ist Google-Lehrer. Jetzt, wo ich Java 8-Code lesen kann, kann ich mehr tun. Haben Sie keine Angst mehr, Beispielcode im Lambda-Stil in Ihren Suchergebnissen zu sehen. Ich muss nicht rechts abbiegen. (Lol) Ich bin froh, wie alt ich bin, um zu wissen, was ich nicht weiß, und um mehr tun zu können.
Zum Beispiel ist es schwierig, JUnit-Testfälle Code zu schreiben. Lange und komplexe Methoden erhöhen die Kosten für das Denken und Schreiben von Testfällen. Es ist schwierig zu warten und zu reparieren. Lassen Sie uns über eine andere Beschreibungsmethode für denselben Verarbeitungsinhalt nachdenken, z. B. die Aufteilung der Verarbeitung der Hauptmethode in kleine Teile und die Aufteilung der verteilten Verarbeitung in separate Methoden. Ich habe gesehen, dass eine öffentliche Methode einer völlig neuen Klasse aufgrund der Renovierung 300 Zeilen überschritten hat, aber ich habe gehört, dass es sich um eine Beschwerde eines Kunden handelt. Es geht um Java im Jahr 2019. Es ist kein altes C. Natürlich war die Verarbeitung tief verschachtelt und die Lesbarkeit sehr gering. Eine Ebene, auf der nur die Person, die sie geschrieben hat, JUnit schreiben kann. Mir wurde geholfen, aber ich konnte es nicht ohne einen Kommentar von ihm tun. Sie sollten jedoch auf jeden Fall die Dummheit stoppen, den ** Zugriffsmodifikator der Split-Methode als privat zu entfernen, um ihn in JUnit ** aufzurufen. Machen Sie das Testziel zum Testen falsch. So etwas ist nichts als ein Sturz. Ich sehe es wirklich oft.
Verwenden Sie Reflection, wenn es aufgrund von Einschränkungen des Zugriffsmodifikators nicht aus der Testklasse aufgerufen werden kann. Machen Sie die Testzielmethode geschützt und rufen Sie sie von der Testklasse auf, die die Testzielklasse erbt. protected ist kein Zugriffsmodifikator für Testzwecke. Auch private statische Methoden können durch Reflexion aufgerufen und getestet werden ...
** Nachtrag 1 ** Ich habe einen Artikel über eine JUnit-Testklasse geschrieben, die ein privates Methodenfeld aufruft. Private Methode in JUnit testen Private Variablen in Reflexion verweisen / festlegen
** Nachtrag 2 ** Zugriffsqualifizierer sind in Java obligatorisch. Wenn Sie sich nicht sicher sind, überprüfen Sie sie. Einige Sprachen wie JavaScript und Python verfügen nicht über Zugriffsmodifikatoren, aber Java ist eine Sprache mit Zugriffsmodifikatoren. Ich habe darüber nachgedacht, warum Python und JavaScript keine Zugriffsmodifikatoren haben - Qiita
Wie ich oben geschrieben habe, ist Code mit tiefer Verschachtelung (bedingte Verzweigung und Schleifenblöcke haben eine mehrstufige verschachtelte Struktur) kompliziert und unlesbar, und JUnit ist auch schwer zu schreiben. Solch tief verschachtelter Code ist auch ein Zeichen, das den Prozess in separate Methoden unterteilt. Code, der die Lesbarkeit nicht berücksichtigt, ist schwer zu testen.
Zum Beispiel einfach, wenn die Verschachtelung durch Invertieren der Bedingung reduziert werden kann. Wenn das Argument in einem allgemeinen Muster nicht leer ist, wird es verarbeitet. Wenn es jedoch leer ist, wird ein fester Wert zurückgegeben. Kehren Sie in diesem Fall die Bedingung um und beschreiben Sie sie so, dass das nicht verarbeitete Muster zuerst die Verarbeitung beendet.
//schlechtes Beispiel
boolean result = false;
if (Bedingung A.) {
//Bearbeitung bei Bedingung A.
// ………
} else {
return result;
}
return result;
//Gutes Beispiel
if (!Bedingung A.) {
return false;
}
boolean result = false;
//Bearbeitung bei Bedingung A.
//Danach wird der Rückgabewert zurückgegeben, wenn eine vorzeitige Rückgabe möglich ist.
// ………
return result;
Das obige Ergebnis ist das gleiche. Dies allein reduziert jedoch die Anzahl der Nester in der Verarbeitung, die innerhalb des Blocks der Bedingung A ausgeführt wird, um eins. Wenn der Block von Bedingung A mehrere Zeilen enthält, ist es auch weniger lesbar, dass Sie nicht wissen, was Sie außer Bedingung A tun sollen, bis Sie den Block von Bedingung A gelesen haben. Selbst wenn in der for-Anweisung eine bedingte Verzweigung durchgeführt wird, kann die Verschachtelung reduziert werden, indem dieses Muster fortgesetzt / unterbrochen wird. Im schlechten Fall ist der Rückgabewert von else eine Variable, sodass Sie nicht auf einen Blick erkennen können, wie hoch der Rückgabewert ist. Es gibt kein anderes Muster als false, also ist "return false" in Ordnung. Da nach der Rückgabe keine Verarbeitung erfolgt, muss diese nicht in einer Variablen gespeichert werden. Außerdem wird der Umfang der Variablen eingeschränkt, da sie nicht mehr vor der if-Anweisung deklariert werden müssen.
Was ist falsch daran, denselben Prozess einzeln an mehreren Stellen zu schreiben? Das liegt daran, dass Wartung und Reparaturen schwierig sind. Angenommen, ein Prozess wird an mehreren Stellen ausgeführt, aber alle werden einzeln beschrieben. Es wurde beschlossen, den Prozess zu reparieren. Es ist notwendig, für alle Teile den gleichen Inhalt zu bestätigen, zu reparieren und zu testen. Im Falle derselben Beschreibung kann sie durch Kopieren korrigiert werden. Wenn die Anzahl der Korrekturen zunimmt, tritt definitiv eine Kopierpemis auf. Dies ist häufig bei Kommentaren und fehlenden Änderungen des Variablennamens der Fall. Darüber hinaus muss der gesamte Code auf Überschuss oder Mangel am Ausführungsort des Prozesses überprüft werden. Sie können dies innerhalb der Klasse tun, aber wenn Sie es nicht allgemein machen, können Sie am Ende das gesamte Projekt überprüfen. Alle sich wiederholenden Kosten sind verschwenderisch und würden sonst weggelassen.
Schneiden wir die Beschreibung, die dieselbe Verarbeitung ausführt, in eine Methode aus. Werte, die sich am Aufrufort unterscheiden, können als Argumente übergeben werden. Wir empfehlen, dass Sie Code schreiben, der schnell funktioniert, und ihn dann umgestalten. Es ist sicherer und sicherer, wenn Sie auch JUnit schreiben und vor dem Refactoring bestätigen, dass der Verarbeitungsinhalt korrekt ist. Sobald Sie es geschrieben haben, ist es leicht zu bemerken: "Ich habe das Gefühl, ich habe diesen Prozess schon einmal geschrieben ...?"
Dies ist jedoch bei Neuproduktionen der Fall, und in Ausnahmefällen kann es unvermeidlich sein, das vorhandene System zu reparieren. In einem vorhandenen System, in dem derselbe Prozess beispielsweise einzeln in mehreren Klassen beschrieben wird, enthalten einige der Klassen, die gemeinsam genutzt werden sollen, die zu reparierende Klasse. Bei der Änderung eines vorhandenen Systems werden häufig Teile, die nicht geändert werden müssen, nicht so weit wie möglich geändert. Dies liegt daran, dass die modifizierte Klasse neben der Granularität und Phase eine Art erneutes Testen benötigt, was den Aufwand erhöht. In einem solchen Fall wird, selbst wenn die Richtlinie ein Refactoring durchführen soll, das nicht mit dem Inhalt der Reparatur zusammenhängt, in den meisten Fällen nur das Refactoring innerhalb der zu reparierenden Klasse durchgeführt, und das Refactoring, das eine für eine andere Klasse gemeinsame Methode ausschneidet, wird nicht durchgeführt. ist. Erkundigen Sie sich bei der Überholung eines vorhandenen Systems bei Ihrem Vorgesetzten oder Experten nach Verfügbarkeit und Umfang des Refactorings.
Es ist am besten, nicht (so viel wie möglich) Code freizugeben, der ein Refactoring erfordert, das eine technische Haftung darstellt.
Erstens sollten C-Sprachlerner beim Schreiben von ** Java die C-Sprache vergessen. C-Sprache und Java sind unterschiedlich. ** ** ** Java und C sehen möglicherweise etwas ähnlich aus (Codierungsstil). C-Sprache und Java unterscheiden sich jedoch. Der einzige Unterschied besteht darin, dass die Namen von Java und JavaScript ähnlich sind. Der Inhalt ist völlig anders. Bitte nicht mitmachen. ** Sie können Java nicht schreiben, nur weil Sie C schreiben können. ** Leg dich wirklich nicht mit mir an. C-Sprache ist nicht objektorientiert. Es ist eine andere Sache. Das einzige, was sie gemeinsam haben, ist ihr Aussehen. ** Wenn ein aktiver Kämpfer und Kanna Hashimoto die gleichen Kleider tragen, beurteilen Sie sie als die gleiche Person? Nicht wahr? Es ist das gleiche wie das. ** ** **
Deklarieren Sie Variablen nicht zu Beginn einer Methode zusammen. Selbst wenn Sie die IDE verwenden, werden normale lokale Variablen nur so oft angezeigt wie der Typ. Wenn die Erklärung weit von dem Ort entfernt ist, an dem sie tatsächlich verwendet wird, ist es Zeitverschwendung, die Erklärung einzusehen. ** Wie so oft bei Leuten aus C (oder VBA) ist dies eine schlechte Praxis in Java. ** ** ** Deklarieren Sie Variablen unter Berücksichtigung des Verwendungsumfangs. Es macht keinen Sinn, Variablen zu schreiben, die nur innerhalb des Blocks außerhalb des Blocks verwendet werden. Schreibe es lieber.
Gelegentlich handelt es sich um ein Projekt, das immer noch die alten Codierungskonventionen verwendet und in einer Kopf-an-Kopf-Erklärung geschrieben ist. Aber das ist heute eine verdammte Regel in Java, deshalb sollten Sie in einigen Fällen Fragen stellen.
Stellen Sie sich einen Bereich als nutzbaren Bereich vor.
In Java können innerhalb eines Blocks deklarierte Variablen nicht außerhalb des Blocks verwendet werden. (Blockbereich)
Beispiel: Eine for-Anweisung wie for (int i = 0; i <array.length; i ++) {, der hier deklarierte Schleifenzähler "i" verursacht einen Kompilierungsfehler außerhalb der for-Anweisung. Es kann nicht für Blöcke wiederverwendet werden.
Sie müssen nur diese Variable im Block kennen. Allein durch Eingrenzen des zu beachtenden Bereichs wird die Lesbarkeit erheblich verbessert.
Außerhalb des Blocks deklarierte Variablen können auch nach dem Verlassen des Blocks referenziert und zugewiesen werden.
es kann. Ja es ist möglich. Sie müssen wissen, wo die Variable verwendet wird, da dies möglich ist.
Die effektive Verwendung des Blockbereichs besteht darin, deutlich zu machen, dass er nur dort verwendet wird. Es speichert die Erinnerung an das Gehirn des Lesers und die Erinnerung an JavaVM.
Minimieren wir also den Umfang der Variablen.
Die Wiederverwendung von Variablen verringert die Lesbarkeit und führt zu Fehlern. Sie müssen wissen, wo die Variable verwendet wird. Der Grund, warum die starke Verwendung globaler Variablen schlecht gesagt wird, ist die Schwierigkeit, sie zu verwalten. Wo zu ersetzen und wo zu verweisen. Es ist schwer, alles im Auge zu behalten. Darüber hinaus besteht die Möglichkeit, dass der Wert bei seiner Wiederverwendung initialisiert werden muss, aber es erhöht auch die Möglichkeit, einen Fehler zu erstellen, indem vergessen wird, ihn zu initialisieren. Bei der Wiederverwendung ist der Variablenname in der Regel generisch, aber das ist auch nicht gut. Mit anderen Worten, die Wiederverwendung von Variablen ist schädlich und hat keinen Vorteil. ** Es ist eine Abkürzung, die nicht weggelassen werden darf.
In früheren Zeiten gab es die Tendenz, Variablen zu deklarieren, die in einer Schleife außerhalb der Schleife verwendet wurden, um Speicherplatz zu sparen. Aber jetzt muss ich mir nicht mehr so viele Sorgen machen. Wenn Sie es nur in einer Schleife verwenden, deklarieren Sie es in einer Schleife. Wenn Sie es außerhalb der Schleife deklarieren, werden Sie vergessen, dass Sie es jedes Mal am Anfang der Schleife initialisieren müssen, und Sie werden fehlerhaft sein! Im Gegenteil, es gibt Schleifenzähler und andere Variablen, die außerhalb der Schleife deklariert werden sollten.
Für Zugriffsmodifikatoren gilt das Gleiche wie für Variablen. Machen Sie nichts öffentlich oder ohne Zugriffsmodifikatoren, egal ob es sich um eine Methode oder eine Variable handelt **. Berühren von überall ist kein Vorteil. In den meisten Fällen ist dies ein Nachteil.
** Schreiben Sie keinen Code, den Sie nicht verstehen **. Es ist einfach, eine Situation zu erstellen, in der Sie es nicht wissen, aber es funktioniert ... ** Ich weiß es nicht, also kopieren Sie es nicht **. Selbst beim Kopieren ist es wichtig, dass Sie es richtig lesen, den Inhalt verstehen und den Quellcode der Kopie entsprechend dem Einfügeziel umgestalten.
Bitte bedenke. Sie sollten keinen Code schreiben, den Sie nicht selbst erklären können, wenn Sie in einer Codeüberprüfung gefragt werden. "Weil ich es durch Suchen gefunden habe" "Weil es einen Ort gab, der so geschrieben wurde" etc ... Dies sind nicht die Gründe. Auch keine Antwort. Es ist nur eine Ausrede. Kopieren und fügen Sie nicht wegen Hirntod ein, sondern lesen und verstehen Sie zumindest, was Sie tun. ** Gewöhnen Sie sich an, Javadoc für APIs zu lesen, die Sie nicht verstehen **. Auch wenn es sich um eine Methode handelt, lesen Sie bitte, welche Art der Verarbeitung in dieser Methode ausgeführt wird. Sie können keinen Erfahrungswert erhalten, ohne zu lesen.
Gelegentlich (auch wenn ich kein Neuling bin) frage ich "Sag mir einen Referenzcode" und wenn ich ihn unterrichte, kopiere ich den Code so wie er ist. Sie sollten die Bedeutung von "Referenz" einmal im Wörterbuch nachschlagen. ** Wenn nur diese Leute nicht arbeiten, werden sie die Person beschuldigen, die sie unterrichtet hat! !! !! !! !! !! !! !! !! ** ** ** Ist dein Kopf eine Dekoration? Ah? ** Übernimm die Verantwortung für deinen Code, Scheiße! !! !! !! !! ** Es ist eine Aktion, der nicht geholfen werden kann, selbst wenn sie verflucht ist.
Besonders öffentliche Methoden. Das Schreiben von Testklassen für lange öffentliche Methoden kann äußerst schwierig sein. Lassen Sie uns 1 Methode 1 Funktion kennen. Die Testklasse ist auch leicht zu schreiben. Es ist auch einfach, einen Methodennamen anzugeben. Sie können die private Methode von der privaten Methode aus aufrufen. Versuchen Sie daher, sie nicht so kompliziert wie möglich zu gestalten. Je weniger Funktionen Sie haben, desto kürzer ist Ihr Code. Ich denke, es ist am besten, es in maximal 100 Zeilen / Methode maximal zu passen. Persönlich verwende ich die Anzahl der Zeilen, die auf einem Bildschirm angezeigt werden können, als Richtlinie, ohne zu scrollen.
Das Ändern einer Methode, die mit der Verarbeitung überladen ist, erweitert den Testumfang erheblich. Wenn die drei Funktionen der Prozesse A, B und C mit einer Methode verarbeitet werden, ist ein Test erforderlich, um zu bestätigen, dass die Prozesse B und C nicht betroffen sind, auch wenn nur Prozess A geändert wird. Wahrscheinlich. Java ist objektorientiert, daher ist es eine gute Idee, das Prinzip der Einzelverantwortung zu berücksichtigen. [Prinzip der Einzelverantwortung | 97 Dinge, die Programmierer wissen sollten](https://xn--97-273ae6a4irb6e2hsoiozc2g4b8082p.com/%E3%82%A8%E3%83%83%E3%82%BB%E3%82 % A4 /% E5% 8D% 98% E4% B8% 80% E8% B2% AC% E4% BB% BB% E5% 8E% 9F% E5% 89% 87 /)
Es ist leicht zu lesen, wenn Sie die private Methode aufrufen, die jeden Prozess in der öffentlichen Methode der Reihe nach ausführt. Wenn die Methoden für jeden Prozess getrennt werden, wird die Testfreundlichkeit erheblich verbessert. Betrachten Sie es als ein Plastikmodell. Wenn Sie nur die Armteile lackieren möchten, ist es einfacher zu arbeiten, wenn Sie die Armteile entfernen können. Wenn es sich um eine einteilige weiche Vinylfigur handelt, müssen Sie darauf achten, dass die Farbe bis auf den Arm nicht hervorsteht.
Erklären Sie dasselbe Literal mit ähnlicher Absicht als Konstante, um es an einem Ort zu konsolidieren und sinnvoll zu machen. Es gibt keinen Grund, einen Wert zu belassen, der immer wieder mit der gleichen Absicht als magische Zahl verwendet wird. Wenn es als Konstante benannt wird: "Was ist dieser Wert?" Und "Warum ist dieser Wert?" Wird definitiv reduziert. Wenn Sie es als Konstante deklarieren und verwenden und den Wert ändern, müssen Sie nur den konstanten Wert ändern. Wenn Sie es an mehreren Orten verwenden, ist es ein großer Vorteil. Grundsätzlich ist es nicht gut, die magische Zahl zu belassen, da sie hart codiert ist.
Es gibt jedoch auch Fälle von Fall zu Fall, da zu viele private Konstanten für Literale, die jeweils nur an einer Stelle verwendet werden, die Lesbarkeit beeinträchtigen. Zum Beispiel, wenn der Variablenname zipCd ist und "Teilzeichenfolge (0, 3)" oder "Teilzeichenfolge (3)" ist. Sie können dies erkennen, indem Sie nur die Tatsache betrachten, dass die Postleitzahl an der Bindestrichposition geteilt ist. Wenn es sich jedoch um einen Geschäftswert handelt, sollte er als Konstante deklariert und verwendet werden, oder es sollte eine Methode zu seiner Verarbeitung sein.
Wenn sich Änderungen ergeben, empfiehlt es sich, anstelle einer Konstanten eine externe Eigenschaftendatei aufzurufen. Sie können es durch den Schlüsselnamen aussagekräftig machen, wenn Sie es von der Eigenschaft erhalten, und Sie müssen den Code nicht ändern.
** Hinzugefügt aus dem Kommentarbereich ** Wenn die Werte zufällig gleich sind, aber unterschiedliche Verwendungen und Absichten haben, verwenden Sie keine gemeinsamen Konstanten. Es ist ein Schritt in Richtung Fehler. Wenn der Zweck oder die Absicht anders ist, deklarieren Sie ihn mit einer anderen Konstante. Es ist wichtig, darüber nachzudenken, wie Sie es als Konstante bezeichnen.
Zumindest ist Javadoc mit @param, @return und @throws erforderlich, die der Quelle entsprechen. Java ist eine IDE-Prämisse, und es wäre schön, wenn es genügend Erklärungen gäbe, um diese Methode aufzurufen, nachdem nur Javadoc überprüft wurde. Andernfalls müssen Sie während der Wartung und Reparatur alle Funktionen des angerufenen Teilnehmers lesen.
Zum Beispiel das Tag "@ param", das den Inhalt des Arguments erklärt, und das Tag "@ return", das den Rückgabewert erklärt. Es steht außer Frage, dass es selbst kein Tag gibt, obwohl es sich um eine Methode mit Argumenten und Rückgabewerten handelt. Es gibt Muster wie "@param str", die nicht nur durch den Variablennamen erklärt werden (wird es nur automatisch generiert und in Ruhe gelassen?). Ich entschuldige mich jedoch und möchte, dass Sie es sofort korrigieren.
Trotzdem ist es immer noch gut, wenn Sie anhand der Benennung erkennen können, dass der Typ charakteristisch ist. Mit "int update (Connection con, String sql, Map <String, Object> params)" können Sie auf einen Blick sehen, dass die Verbindung, die SQL-Anweisung und die in die SQL-Anweisung einzubettenden Parameter übergeben werden, um die Datenbank zu aktualisieren und die Nummer zurückzugeben. .. (** Javadoc Beschreibung ist noch erforderlich, aber **) Aber ich kann nicht erraten, was zu übergeben ist, was zu tun ist und was zurückzugeben ist, eine Methode wie "String edit (String str, String value, boolean flg)". Vielleicht wird die Person, die es geschrieben hat, es im Laufe der Zeit nicht verstehen. Wenn jedoch Javadoc geschrieben wird, sind die Kosten für das Lesen des Inhalts fast unnötig.
Javadoc ist mehr als nur zum Zeitpunkt der Herstellung geschrieben. Argumente und Rückgabewerte können sich während der Renovierung erhöhen, verringern oder ändern. In diesem Fall müssen Sie unbedingt ein Update durchführen. ** Javadocs, die nicht mit dem Code übereinstimmen, sind minus ** statt null. Es ist Müll. ~~ Sollte ins Feuer der Hölle geworfen werden. ~~ Zumindest eine Übersicht, Argumente und Rückgabewert. Ordnen Sie diese drei dem damaligen Code zu. Es ist eine gute Idee, sich daran zu gewöhnen, Javadoc zu überprüfen, wenn Sie Code schreiben oder ändern.
** Verknüpfen Sie keine Kommentare mit dem Designdokument, z. B. einschließlich der Kapitelnummer des Designdokuments **. Beim Ändern des Entwurfsdokuments müssen die Kommentare des Codes außer dem Änderungsziel synchronisiert werden, nur weil sich die Artikelnummer geändert hat. Es gibt viele Projekte, in denen das Designdokument nicht verwaltet wird (obwohl es seltsam ist, dass es normal ist), und der Code und das Designdokument weichen ständig voneinander ab.
~~ Und zum Zeitpunkt der Renovierung heißt es, dass "das Designdokument unzuverlässig ist, aktualisieren Sie also das Designdokument basierend auf dem Code" und die Anzahl der Schritte erhöht sich verschwenderisch ...
Unkomplizierte Verarbeitung und ** Kommentare, die einzeln für jeden einfachen bedingten Zweig geschrieben werden, sind weniger lesbar **. Schreiben Sie keinen Code, der die Anzahl der Zeilen halbiert, wenn Sie einen Kommentar löschen. Es ist java.lang.String der Standard-API, die häufig verwendet wird, aber bitte lesen Sie es einmal. Mit Eclipse können Sie zur Quelle springen, indem Sie einfach F3 drücken. Ich glaube, es gibt keine detaillierten Kommentare außer Javadoc.
Benötigen Sie beispielsweise eine Bedingung oder einen Kommentar wie "Wenn die Anzahl der Elemente in der Liste 0 ist", die nur durch Betrachten des Codes verstanden werden können? Überlegen Sie beim Schreiben eines Kommentars, ob Sie ihn überhaupt benötigen. Wäre es selbst bei einer komplizierten Zustandsbeurteilung nicht unnötig, Kommentare abzugeben, wenn Sie eine andere Methode mit einem beschreibenden Namen verwenden? Code, für den keine Kommentare erforderlich sind, ist leicht zu lesen.
Eine große Anzahl von Kommentaren kann lächerlich geändert werden, wenn der Code geändert wird. Darüber hinaus nimmt mit zunehmender Anzahl von Kommentaren die Anzahl fehlerhafter Kommentare zu, die aufgrund fehlender Korrektur- oder Kopier- / Einfügefehler von der Verarbeitung abweichen. du musst. Ich kann bestätigen. Falsche Kommentare sind weniger lesbar als keine Kommentare. Es ist eine Brutstätte von Käfern.
Tabulatoren und Leerzeichen einrücken, Zeilenumbrüche vor und nach der wellenförmigen Klammer "{}", Leerzeichen vor und nach dem Operator und der Klammer "()" usw. Selbst wenn Sie in der Umfrage eine grep-Suche durchführen, wird diese nicht abgefangen, es sei denn, Sie betrachten die Anzahl der Leerzeichen als regulären Ausdruck und es gibt nichts Gutes. Wenn Sie eine IDE verwenden, verfügt diese meiner Meinung nach über eine automatische Formatierungsfunktion. Daher empfiehlt es sich, die Formatierung beim Speichern so einzustellen, dass sie formatiert wird. Wenn Sie die Einstellungen freigeben, die den Codierungsstandards innerhalb des Projekts entsprechen, haben alle Mitglieder das gleiche Format. Da individuelle Unterschiede weniger wahrscheinlich sind, ist die Wartung einfacher.
Persönlich bevorzuge ich, dass das Format für jedes Projekt festgelegt wird. Auch wenn das Format nicht Ihre Präferenz ist. Es ist besser, als Code für jede Datei in verschiedenen Formaten zu pflegen oder zu ändern. Wenn sich Ihre Augen daran gewöhnen, dauert das Recherchieren und Lesen weniger lange. Weil die Formate vollständig sind.
Es handelt sich in der Regel um ein altes Projekt ohne Versionsverwaltung. Die Kultur des Kommentierens und Zurücklassens von nicht repariertem Code ist nur schädlich. Tun Sie es also nicht. Bitte setzen Sie die Versionsverwaltung für ein solches Projekt ein.
Die Komplexität von auskommentiertem und nicht kommentiertem Code kann die Lesbarkeit erheblich beeinträchtigen. Manchmal war es zu kompliziert und ich konnte aufgrund einer Reparatur wie "Dann den Teil auskommentieren, der zum Zeitpunkt von XX auskommentiert wurde" nicht herausfinden, wo ich auskommentieren sollte.
Hinterlassen Sie keinen Code, der gerade nicht funktioniert. Wenn Sie es behalten möchten, belassen Sie es im Versionsverwaltungsverlauf. Weil Sie den Unterschied überprüfen können. Was ist Versionsverwaltung für ...
Codierungsstile und -formate sind wie Religionen, daher dachte ich, ich würde nur sagen, dass ich wollte, dass sie vereinheitlicht werden, aber lassen Sie mich dies einfach sagen. Ich denke, es ist ein schlechter Code, der keine Wartung oder Aufarbeitung im Auge hat.
Wenn Sie es beispielsweise konkret schreiben, ist es so.
String name = null;
String zip = null;
String address = null;
String telephone = null;
int sex = 0;
Wenn Sie versuchen, eine Variable mit dem Namen "emailAddress" mit einem String hinzuzufügen und sie an einem Leerzeichen auszurichten, das dem vorhandenen Format entspricht, ist der Variablenname der hinzuzufügenden "emailAddress" am längsten, sodass Sie auch andere Zeilen ausrichten müssen. .. Wenn der Typ "Geschlecht" von "int" in "BigDecimal" geändert wird, ist der Typname länger als "String", sodass Sie in der anderen Zeile ein Leerzeichen nach dem Typnamen einfügen müssen, um die Ziffern auszurichten. Nein, es ist möglicherweise kein "Muss", aber nicht einheitliche Formate sind nicht gut. Warum geraten Menschen, die die Ausrichtung von Ziffern mögen, absichtlich in Schwierigkeiten, auch wenn sie sich die Mühe machen?
Wenn Sie dies nicht rechtfertigen, müssen Sie nur eine Zeile mit "String emailAddress = null" hinzufügen und den Typnamen und den Anfangswert mit "BigDecimal sex = null" ändern. Wenn Sie eine grep-Suche durchführen, müssen Sie sie nicht in einen regulären Ausdruck schreiben, da die Anzahl der Leerzeichen variabel ist und Sie den Vorteil der Rechtfertigung nicht finden können.
Verbessert es die Lesbarkeit? Lassen Sie uns die Lesbarkeit an einer anderen Stelle verbessern. Jemand wird die Ziffern niemals ausrichten, während sie beibehalten werden. Wenn Sie die Ziffern nicht ausrichten, können Sie sie nur erzwingen, wenn ein Kompilierungsfehler angezeigt wird. Die Person, die es geschrieben hat, hat es möglicherweise in einem Schrifteditor mit einheitlicher Breite geschrieben, während andere es möglicherweise in einer proportionalen Schriftart angezeigt haben. Beispielsweise gibt es einige Fälle, in denen der Code in Excel eingefügt wird, um das Material für das reparierte Teil zu erstellen, aber die Standard-MS P Gothic hat nicht die gleiche Breite. Es ist schwer zu erkennen, da es unregelmäßig angeordnet ist und keine Bedeutung für die Ausrichtung der Ziffern hat. Es ist seltsam, den Code zu schreiben, der sogar die Anzeigeschrift angibt. Geben Sie das Format nicht an, obwohl es kein Rich-Text ist.
** Nur die Einzüge, die die logische Struktur darstellen , müssen ausgerichtet werden. ( Einzug = Einzug am Zeilenanfang. Nicht in der Zeile enthalten **)
Nun, wenn es im Kodierungsstandard angegeben ist, wird es ausgerichtet, während Blut gespuckt wird. ** Absolute Codierungsstandards. ** ** ** Ich persönlich mag es jedoch nicht. Beschreiben Sie es zumindest in der im Projekt üblichen Formatierungseinstellungsdatei. Erzwingen Sie kein Projekt, das nicht einmal eine Konfigurationsdatei enthält.
Ich persönlich mag es. Über Kommentare in if-Anweisungen. Bitte hören Sie auf, nach der schließenden Klammer im vorherigen Abschnitt von if-else oder else einen Kommentar einzufügen. ** Java ist nicht C #. ** ** ** Ich habe in der Vergangenheit tatsächlich einen Fehler verursacht, indem ich den Code im zweiten Beispiel geändert habe, das ich unten hasse. Ich wurde gebeten, eine Behindertenabstimmung abzugeben. Es ist kein Trauma mehr. Wenn Sie es sehen, möchte ich es mit aller Kraft loswerden. Ich hasse es wirklich, weil es schwer zu sagen ist, wie viel eine if-Aussage ist. Benötigen Sie diesen Kommentar überhaupt? Korrekt. Wenn es viele bedingte Verzweigungen gibt, ist es meiner Meinung nach besser, einen Aufzählungstyp zu erstellen und ihn mit einer switch-Anweisung zu schreiben.
Nun, ** wenn die Codierungskonventionen sind, müssen Sie sie befolgen **. .. ..
//Bevorzugtes Beispiel
if (Bedingung A.) {
//Im Falle der Bedingung A.
} else if (Bedingung B.) {
//Im Falle der Bedingung B.
} else {
//Anders als oben
}
//Unzufriedenes Beispiel 1
//Im Falle der Bedingung A.
if (Bedingung A.) {
}
//Im Falle der Bedingung B.
else if (Bedingung B.) {
}
//Anders als oben
else {
}
//Unzufriedenes Beispiel 2
//Im Falle der Bedingung A.
if (Bedingung A.) {
//Im Falle der Bedingung B.
} else if (Bedingung B.) {
//Anders als oben
} else {
}
Artikel, auf die Sie verweisen möchten, interessante Artikel, interessante Artikel usw. Bitte in Ihrer Freizeit.
■ Erstaunliche Java-Programmierung (hören wir auf) Ich lachte viel. Es gibt viele Fälle, die ich häufig in Code-Reviews von Neulingen sehe.
■ Drei Haupttugenden von Programmierern Ich bin faul und ungeduldig, deshalb möchte ich keine einfachen Aufgaben erledigen und kann meinen Augen nicht am meisten trauen. Also lernte ich Excel-Funktionen, VBA, reguläre Ausdrücke und SQL, damit ich es meinem PC überlassen konnte. Es wird auf Feldebene stark genutzt. Das Gefühl, Spaß zu haben, ist sehr wichtig.
■ SE-Terminologie im Wunderland Mein Lieblingsartikel. Ich frage mich, warum das so ist. Wenn ich es bemerke, spreche ich damit.
Recommended Posts