it-swarm.com.de

Sollte ich einem schlechten Codierungsstil folgen, um die an meinem Arbeitsplatz festgelegten Konventionen zu befolgen?

Ich arbeite seit ungefähr einem Jahr an meinem Arbeitsplatz. Ich arbeite hauptsächlich in unserer GUI-Oberfläche, die Methoden aus einem C-Backend verwendet, aber ich muss mich im Allgemeinen nicht mit ihnen befassen, außer mit Rückgabewerten. Unsere GUI ist angesichts unserer Einschränkungen ziemlich vernünftig strukturiert.

Ich wurde beauftragt, dem Befehlszeilenteil des Programms eine Funktion hinzuzufügen. Die meisten dieser Funktionen sind 300 Zeilen lang und schwer zu bedienen. Ich versuche, Teile davon zu sammeln, um an bestimmte Alarminformationen zu gelangen, und ich habe Probleme, mich zu organisieren. Ich weiß, dass ich meine Tests komplizierter mache, indem ich sie in einer einzigen langen Funktion mache.

Sollte ich einfach alles in einer riesigen Funktion gemäß dem Stil der vorhandenen Funktionen behalten oder sollte ich die Alarme in ihren eigenen Funktionen kapseln?

Ich bin mir nicht sicher, ob es angemessen ist, gegen die aktuellen Codierungskonventionen zu verstoßen, oder ob ich einfach in die Kugel beißen und den Code für mich selbst etwas verwirrender machen sollte.

Zusammenfassend vergleiche ich

showAlarms(){
    // tons of code
}

gegen

showAlarms(){
   alarm1();
   alarm2();
   return;
}

alarm1(){
    ...
    printf(...);
    return;
}

EDIT: Vielen Dank für den Rat an alle. Ich habe beschlossen, meinen Code faktorisiert zu gestalten und dann zu fragen, was sie wollen. Wenn sie alles in einem wollen, kann ich einfach aus meinem faktorisierten Code herausschneiden und ihn wieder in 1 umwandeln große Funktion. Dies sollte es mir ermöglichen, es einfacher zu schreiben und zu testen, selbst wenn sie den gesamten Code in einer einzigen Definition haben möchten.

UPDATE: Am Ende waren sie mit dem faktorisierten Code zufrieden und mehr als eine Person hat mir dafür gedankt, dass ich diesen Präzedenzfall geschaffen habe.

101
Justin

Das ist wirklich zwischen Ihnen und Ihren Teamkollegen. Niemand sonst kann Ihnen die richtige Antwort geben. Wenn ich es jedoch wagen darf, zwischen den Zeilen zu lesen, gibt die Tatsache, dass Sie diesen Stil "schlecht" nennen, einige Informationen, die darauf hindeuten, dass es besser ist, ihn langsam anzugehen. Sehr wenige Codierungsstile sind tatsächlich "schlecht". Es gibt solche, die ich selbst nicht benutzen würde, aber sie haben immer einen Reim oder Grund. Dies legt für mich nahe, dass die Geschichte mehr enthält, als Sie bisher gesehen haben. Herumzufragen wäre ein sehr weiser Anruf. Jemand weiß vielleicht etwas, was Sie nicht wissen.

Ich bin persönlich darauf gestoßen, als ich zum ersten Mal in die unternehmenskritische Echtzeitcodierung vordrang. Ich habe Code wie diesen gesehen:

lockMutex(&mutex);
int rval;
if (...)
{
    ...
    rval = foo();
}
else
{
    ...
    rval = bar();
}
unlockMutex(&mutex);
return rval;

Als der helle und glänzende OO C++ - Entwickler, den ich war, machte ich sie sofort auf die Fehlerrisiken aufmerksam, die sie hatten, indem ich Mutexe manuell sperrte und entsperrte, anstatt [~ # ~] raii [~ # ~ zu verwenden ] . Ich bestand darauf, dass dies besser war:

MutexLocker lock(mutex);
if (...)
{
    ...
    return foo();
}
else
{
    ...
    return bar();
}

Viel einfacher und sicherer, oder?! Warum sollten Entwickler daran denken, ihre Mutexe auf allen Kontrollflusspfaden freizuschalten, wenn der Compiler dies für Sie tun kann?

Nun, was ich später herausfand, war, dass es dafür einen Verfahrensgrund gab. Wir mussten bestätigen, dass die Software tatsächlich korrekt funktionierte, und es gab eine endliche Liste von Tools, die wir verwenden durften. Mein Ansatz mag in einer anderen Umgebung besser gewesen sein, aber in der Umgebung, in der ich gearbeitet habe, würde mein Ansatz den Arbeitsaufwand für die Überprüfung des Algorithmus leicht verzehnfachen, da ich gerade ein C++ - Konzept von RAII in einen Codeabschnitt eingefügt habe Das wurde nach Maßstäben gehalten, die dem Denken im C-Stil wirklich zugänglicher waren.

Was für mich nach einem schlechten, geradezu gefährlichen Codierungsstil aussah, war eigentlich gut durchdacht, und meine "gute" Lösung war tatsächlich die gefährliche, die später Probleme verursachen würde.

Also frag herum. Es gibt sicherlich einen erfahrenen Entwickler, der mit Ihnen zusammenarbeiten kann, um zu verstehen, warum sie dies so tun. Oder es gibt einen erfahrenen Entwickler, der Ihnen helfen kann, die Kosten und den Nutzen eines Refaktors in diesem Teil des Codes zu verstehen. Wie auch immer, fragen Sie herum!

100
Cort Ammon

Glauben Sie wirklich, dass es nur eine Frage des Stils ist, schwer zu bedienende Funktionen mit 300 Zeilen zu haben? Wenn Sie also dem schlechten Beispiel folgen, könnte das Gesamtprogramm aufgrund der Konsistenz in einem besseren Zustand bleiben? Ich denke, Sie glauben es nicht, sonst hätten Sie diese Frage hier nicht gestellt.

Ich vermute, diese Funktionen sind so lang, weil es in unserem Geschäft viele mittelmäßige Programmierer gibt, die nur Features über Features stapeln, ohne auf Lesbarkeit, Codequalität, korrekte Benennung, Komponententests und Refactoring zu achten, und sie haben nie gelernt, richtige Abstraktionen zu erstellen . Sie müssen selbst entscheiden, ob Sie dieser Herde folgen oder ein besserer Programmierer sein möchten.

Nachtrag aufgrund der Kommentare: "300 Zeilen" und "schwer zu verwenden" sind meiner Meinung nach starke Anzeichen für schlechten Code. Nach meiner Erfahrung ist es sehr unwahrscheinlich, dass es einen "versteckten technischen Grund" gibt, warum ein solcher Code nicht besser lesbar implementiert werden kann, vergleichbar mit dem Beispiel der Antwort von Cort Ammon. Ich stimme Cort jedoch zu, dass Sie dies mit den Verantwortlichen im Team besprechen sollten - nicht um unklare Gründe zu finden, warum der Code oder diese "Art von Stil" nicht geändert werden kann, sondern um herauszufinden, wie der Code sicher überarbeitet werden kann, ohne Dinge zu beschädigen .

83
Doc Brown

Nein.

In dem Buch Pragmatic Programmer spricht der Autor über die Broken Window Theory .

Dieser theoretische Zustand:

Stellen Sie sich ein Gebäude mit ein paar zerbrochenen Fenstern vor. Wenn die Fenster nicht repariert werden, besteht die Tendenz, dass Vandalen einige weitere Fenster zerbrechen. Schließlich können sie sogar in das Gebäude einbrechen, und wenn es nicht besetzt ist, werden sie möglicherweise zu Hausbesetzern oder leichten Bränden im Inneren.

Oder betrachten Sie einen Bürgersteig. Es sammelt sich etwas Müll an. Bald sammelt sich mehr Müll an. Schließlich lassen die Leute sogar Müllsäcke aus Restaurants zum Mitnehmen oder brechen sogar in Autos ein.

In dem Buch schreibt der Autor eine Parallele zwischen dieser Theorie und dem Code. Sobald Sie einen Code wie diesen gefunden haben, halten Sie an und stellen sich dieselbe Frage.

Und die Antwort lautet: Nein.

Sobald Sie dieses zerbrochene Fenster verlassen - in unserem Fall schlechten Code - wird der Effekt erzeugt, dass jeder zerbrochene Fenster zurücklässt.

Und eines Tages wird der Code zusammenbrechen.

Geben Sie allen eine Kopie von Clean Code und Clean Coder .

Und während Sie sich mit dem Thema befassen, ist eine Kopie von TDD auch eine gute.

42
linuxunil

Ja, mach es. Struktur! = Stil

Sie sprechen von Struktur, nicht von Stil. Stilrichtlinien schreiben (normalerweise) keine Struktur vor, da die Struktur im Allgemeinen aufgrund ihrer Eignung für ein bestimmtes Problem und nicht aufgrund ihrer Eignung für eine Organisation ausgewählt wird.

Achtung

Seien Sie nur verdammt sicher, dass Sie in anderen Bereichen, die Ihnen möglicherweise nicht in den Sinn gekommen sind, keine negativen Konsequenzen haben. Zum Beispiel,

  • Stellen Sie sicher, dass Sie keine Unterschiede oder Code-Zusammenführungen komplizieren, da Sie Ähnlichkeiten mit vorhandenem Code ausgelöscht haben.
  • Stellen Sie sicher, dass Ausnahmeströme korrekt in die Luft sprudeln und Stapelspuren nicht mit einem riesigen Haufen unleserlichen Unsinns verschmutzt werden.
  • Stellen Sie sicher, dass Sie nicht versehentlich öffentliche Einstiegspunkte freigeben, die bei direktem Aufruf Probleme verursachen würden (fügen Sie sie nicht in die Karte ein und/oder exportieren Sie sie nicht).
  • Überladen Sie den globalen Namespace nicht, z. Wenn für Ihre kleineren Funktionen alle ein globaler Kontext erforderlich ist, der zuvor im funktionslokalen Bereich deklariert wurde.
  • Sehen Sie sich unbedingt alle Protokolle an und fragen Sie sich, ob Sie im Support-Team waren, wenn die von Ihrem Code generierten Protokolle verwirrend wären, wenn sie mit den Protokollen eines Codes verwoben würden, den Sie nicht berühren.
  • Stellen Sie sicher, dass Sie den vorhandenen Stil einhalten, z. Auch wenn sie Old-School verwenden ngarische Notation und es Ihre Augen bluten lässt, bleiben Sie im Einklang mit der allgemeinen Codebasis. Das einzige, was schmerzhafter ist als das Lesen der ungarischen Notation, ist das Lesen von Code, der ein Dutzend verschiedene Notationstypen verwendet, je nachdem, wer was geschrieben hat.

Sei sanft

Denken Sie daran, dass Sie Teil eines Teams sind, und obwohl guter Code wichtig ist, ist es auch sehr wichtig, dass Ihre Teammitglieder in der Lage sind, die Dinge zu pflegen, die Sie geschrieben haben, wenn Sie in den Urlaub fahren. Versuchen Sie, sich an einen Fluss zu halten, der für Menschen, die an den alten Stil gewöhnt sind, Sinn macht. Nur weil du der klügste Kerl im Raum bist, heißt das nicht, dass du über alle Köpfe reden solltest!

24
John Wu

Ich sehe dies nicht als Code-Konvention. Ich sehe dies als jemanden, der nicht versteht, wie man wartbaren Code schreibt, der leicht zu verstehen ist. Ich würde Ihren Code in verschiedene Funktionen aufteilen, wie Sie vorschlagen, und Ihr Team über die Vorteile dieser Funktion aufklären, während ich versuche zu verstehen, warum 300-Zeilen-Funktionen für akzeptabel gehalten werden. Es würde mich sehr interessieren, ihre Argumentation zu hören.

5
Bernard

Die Antwort ist in der Codeüberprüfung.

Die eigentliche Frage ist, ob Sie der einzige sind, der bereit ist, damit zu arbeiten, wenn Sie gut faktorisierten Code einreichen.

Ich glaube, wie die meisten Leute hier, dass 300 Leitungsfunktionen ein Greuel sind. Windex auf eine Mülldeponie zu bringen, wird jedoch nicht viel nützen. Das Problem ist nicht der Code, sondern die Codierer.

Nur richtig zu sein ist nicht genug. Sie müssen Leute auf diesem Stil verkaufen. Zumindest beim Lesen. Wenn Sie dies nicht tun, enden Sie wie dieser arme Kerl: gefeuert, weil Ihre Fähigkeiten zu weit über Ihren Mitarbeitern liegen

Fangen Sie klein an. Fragen Sie nach und finden Sie heraus, ob jemand andere kleinere Funktionen bevorzugt. Schnuppern Sie noch besser in der Codebasis und sehen Sie, ob Sie herausfinden können, wer die kleinsten schreibt (möglicherweise stellen Sie fest, dass der hässlichste Code der älteste Code ist und die aktuellen Codierer besseren Code schreiben). Sprechen Sie mit ihnen darüber und sehen Sie, ob Sie einen Verbündeten haben. Fragen Sie, ob sie jemanden kennen, dem es genauso geht. Fragen Sie, ob sie jemanden kennen, der kleine Funktionen hasst.

Sammeln Sie diese kleine Gruppe und sprechen Sie über Änderungen. Zeigen Sie ihnen die Art von Code, den Sie schreiben möchten. Stellen Sie sicher, dass sie es lesen können. Nehmen Sie alle Einwände ernst. Nehmen Sie die Änderungen vor. Lassen Sie Ihren Code genehmigen. Sie haben jetzt die Macht eines Meetings hinter sich. Wenn Sie noch einige davon verwenden, können Sie ein einseitiges Dokument erstellen, das den von Ihnen eingeführten neuen Stil explizit akzeptiert.

Meetings sind überraschend mächtige Dinge. Sie können Schlagkraft erzeugen. Mit Schlagkraft kämpfen Sie gegen diejenigen, die sich dieser Bewegung widersetzen. Und genau das ist es an diesem Punkt. Eine Bewegung. Sie kämpfen für das Recht, den Status Quo zu verbessern. Die Menschen fürchten Veränderungen. Sie müssen süß reden, cajole und stupsen. Aber mit etwas Glück verwandeln Sie sich in Akzeptanz.

5
candied_orange

Bevor ich die Aussage mache, dass die Praktiken schlecht sind, würde ich zunächst einen Schritt tun, um den Grund für große Methoden und andere Praktiken zu verstehen, die als schlecht empfunden werden könnten.

Dann müssten Sie sicherstellen, dass die Testabdeckung ziemlich hoch oder wirklich hoch ist (soweit Sie dies ohne größere Umgestaltung erreichen können). Wenn dies nicht der Fall ist, würde ich darauf hinarbeiten, dass die Abdeckung wirklich hoch ist, obwohl Sie den Code nicht geschrieben haben. Dies hilft dabei, eine Beziehung aufzubauen, und Ihr neues Team wird Sie ernster nehmen.

Sobald Sie diese Grundlagen abgedeckt haben, würde Sie niemand, der bei klarem Verstand ist, herausfordern. Führen Sie als Bonusgegenstand ein Mikro-Benchmarking durch, das Ihren Fall wirklich bereichert.

Oft trägt die Art und Weise, wie Sie Word verwenden, wesentlich dazu bei, die Codekultur zu ändern. Mit gutem Beispiel vorangehen. Oder noch besser, warten Sie auf einen Code, den Sie schreiben können - Refactor und Unit Test zum Teufel und Bratsche - Sie werden gehört.

3
skipy

Diese Art von Frage ist im Grunde "bitte lesen Sie meine Teamkollegen". Zufällige Leute im Internet können das nicht. Alle Antworten, die Sie erhalten, sind nur persönliche Meinungen der Leute über den Codierungsstil. Der Konsens ist, dass kürzere Methoden vorzuziehen sind, aber Sie scheinen dies bereits selbst zu denken, sodass Sie dies nicht wiederholen müssen.

Die aktuelle Codebasis scheint also einen anderen Codierungsstil zu verwenden als den, den Sie bevorzugen. Was sollte man tun? Zuerst müssen Sie herausfinden:

  1. Ist dies eine bewusste Entwurfsentscheidung, die von Ihrem aktuellen Team unterstützt wird?
  2. Wollen sie, dass du diesem Stil folgst?

Es gibt nur einen Weg, dies herauszufinden. Fragen.

Es kann mehrere Gründe für lange Funktionen geben. Dies könnte daran liegen, dass das Team glaubt, dass lange Funktionen besser sind als mehrere kurze Funktionen. Dies könnte auch daran liegen, dass es sich um Legacy-Code handelt und das Team bevorzugt, dass neuer Code einem saubereren Design folgt. Wenn Sie also nicht mit dem Team sprechen und dessen Argumentation verstehen, können Sie entweder als Entwickler in Schwierigkeiten geraten.

3
JacquesB

Manchmal muss man mit dem Fluss gehen.

Wie Sie sagten, wurden Sie beauftragt, eine Funktion in einer vorhandenen funktionierenden Codebasis zu implementieren.

Unabhängig von der Unordnung, und ich verstehe, ist es verlockend, es aufzuräumen. In der Geschäftswelt haben Sie jedoch nicht immer die Möglichkeit, Code umzugestalten.

Ich würde sagen, mach einfach das, worum du gebeten wurdest, und mach weiter.

Wenn Sie der Meinung sind, dass es sich lohnt, umzugestalten oder neu zu schreiben, müssen Sie dies zur Diskussion mit dem Team bringen.

2
meda

Es gibt verschiedene Ebenen des "Stils".

Auf einer Ebene, die normalerweise Teil der Codierungskonventionen ist, bedeutet dies, wo Leerzeichen, Leerzeilen, Klammern und Namen (gemischte Groß- und Kleinschreibung, Unterstriche usw.) eingefügt werden müssen.

Auf einer anderen Ebene befindet sich das Programmiermodell, manchmal Dinge wie das Vermeiden von Statik oder das Verwenden von Schnittstellen über abstrakte Klassen, das Aufdecken von Abhängigkeiten und vielleicht sogar das Vermeiden einiger esoterischer Sprachfunktionen.

Dann gibt es die Bibliotheken und Frameworks, die vom Projekt verwendet werden.

Manchmal gibt es eine maximale Begrenzung der Funktionsgröße. Aber selten gibt es eine Mindestgrenze! Sie sollten also herausfinden, welche dieser Dinge die Mächte für wichtig halten, und versuchen, dies zu respektieren.

Sie müssen herausfinden, ob das Team die Umgestaltung des vorhandenen Codes ablehnt. Dies sollte nach Möglichkeit unabhängig vom Hinzufügen neuen Codes erfolgen.

Selbst wenn sie den vorhandenen Code nicht umgestalten möchten, können Sie möglicherweise einige Ebenen in Abstraktionen für den neuen Code einfügen, den Sie hinzufügen. Dies bedeutet, dass Sie im Laufe der Zeit eine bessere Codebasis entwickeln und möglicherweise den alten Code als migrieren können Wartung erfordert.

1
Erik Eidt