Clean Code / Software Principles - Wo seid ihr??


  • Mod

    @tbird sagte in Clean Code / Software Principles - Wo seid ihr??:

    @Columbo sagte in Clean Code / Software Principles - Wo seid ihr??:

    Bitte erklaer @hustbaer nicht, er soll sich mal ein Buch ueber Clean Code durchlesen... er ist routinierter als Du anzunehmen scheinst...

    Das ist möglich, und ich möchte mich, falls noch möglich, bei @hustbaer entschuldigen, falls ich ihm zu nahe getreten bin. Es Las sich so - aber natürlich kennen wir uns noch nicht.

    🤣

    Alles gut. War auch nur Spass. Aber hustbaer hat hier schon ueber 30k Beitraege verfasst und ist ein sehr erfahrener und kompetenter alter Hase. Du solltest also annehmen, dass seine Meinungen schon professionell fundiert sind.



  • @hustbaer sagte in Clean Code / Software Principles - Wo seid ihr??:

    Was sind denn die "gültigen" Coding Standards?

    Ich kenne da den MISRA-C Standard.

    Entdeckt habe ich diesen bei einer speziellen Embedded-IDE als auch bei CppCheck.



  • @tbird sagte in Clean Code / Software Principles - Wo seid ihr??:

    Ich bin bei uns Principle Software Architect und verantwortlich für Code Quality, Maintainability, Einhaltung der Coding Styles etc..

    Welche Rolle spielen bei dir Linting Tools ala CppCheck, clang-tidy,... ?

    Clean Code, das kann ja auch der striktere Einsatz gewisser Funktionen (z.B. std::for_each, std::accumulate,...) bedeuten.



  • Es gibt sehr wohl allgemeingültige Prinzipien / Standards, die einzuhalten sind, unabhängig von den "firmeninternen" >coding styles.

    Die Frage ist, z.b. wenn die firmentinternen Regeln mit den allgemeinen C++ Clean Code und teilweise auch Konzepten collidieren?

    Ich hab jetzt scho 2 mal erlebt im C++ Desktop Umfeld erlebt, das auto keyword verboten ist zu nutzen (wtf 😡 )
    partielle template spezialisierung verboten ist .... (und man generell templates nur im Notfall verwenden soll, weil zu fehleranfällig, mitm 2019er Compiler ??? )

    dass Dinge wie Clean Code, Lingua Franca, SOLID, allg. Software Principles (hier) sehr wenig beachtet werden.

    Wenn aber in Projekte kommst, meistens die, die schon zig Jahre laufen, wär ich froh wenn die grundlegenden Dinge passen würden ....

    • Plugins auch Plugins sind, und nicht nur so heissen,
    • man das Konzept von Ownership respektiert, (wenn std::shared_pointer die meistbenutzteste std Klasse im code ist)

    Da sind StyleGuides dein wenigstes Problem, glaub ich ....
    Schwer ists auch, wenn öfters das Projekt wechselst, und damit jedesmal der Style Guide zu 180° dreht ... ungarische Notation z.b.



  • @RHBaum sagte in Clean Code / Software Principles - Wo seid ihr??:

    (und man generell templates nur im Notfall verwenden soll, weil zu fehleranfällig, mitm 2019er Compiler ??? )

    Sry, OT: Hattest du/die Probleme mit älteren Compilern, wenn templates im Spiel waren? Oder meinst du, dass sich die Fehlermeldungen verbessert haben?
    Oder geht es um traits?



  • @wob sagte in Clean Code / Software Principles - Wo seid ihr??:

    Sehe ich differenzierter. Wir schreiben fast alles auf Englisch, aber manchmal gibt es im Englischen einfach kein optimal passendes Fachwort - oder es gibt auf Deutsch zwei Begriffe für leicht unterschiedliche Dinge, die aber beide in denselben englischen Fachbegriff übersetzt werden, wo die Unterscheidung dann nicht mehr möglich ist und es somit im Englischen uneindeutig wäre und immer noch gesondert erklärt werden müsste. In diesen Fällen verwenden wir auch deutsche Namen im Code.

    Sehe ich auch so.
    Es gibt uns im Team ein paar Fachworte, die sind historisch bedingt deutsch, und wenn ich in dem Zusammenhang etwas programmiere, dann verwende ich im Variablen/Methoden-Namen diesen deutschen Fachbegriff. Das kann dann mitunter schomal etwas denglisches werden wie "getWertpapierStammdaten()". Aber der große Vorteil ist: bei JEDEM Kollegen klingelt es bei dem Wort sofort und er weiß direkt was hier das Thema ist. Und das ist mir in dem Fall wichtiger als irgendwelche Pseudoregeln zum Dogma zu erklären. Zumal nicht jeder Kollege perfekt englisch schreibt/spricht und somit der englische Fachbegriff vermutlich keine Assoziation hervorruft.



  • Zitat: "Dann läuft in dieser Firma grunsätzlich etwas schief..."
    Oh liebe/r @tbird,
    da kennst Du die Unternehmen nicht. Die ich im Auge hatte, sind sehr erfolgreich bzw. finanziell sehr potent.

    PS. Wie funktioniert das eigentlich mit den Zitaten?



  • Zudem: man kann immer nur warnen vor einer zu dogmatischen Auslegung von Regeln. Selbst unser Lead-Architect hat gestern mir gegenüber zugegeben, dass er manchmal im Rausch auch erst den eigentlichen Quellcode schreibt und erst danach den Unittest obwohl die Regel eigentlich besagt dass es anders herum sein soll. Wenn man nämlich erstmal im Flow ist, sollte man auch einfach durchziehen anstatt zu unterbrechen, weil irgendeine Regel sagt, dass man erst dieses oder jenes machen soll.

    Coden soll Spaß machen!



  • @Helmut-Jakoby sagte in Clean Code / Software Principles - Wo seid ihr??:

    PS. Wie funktioniert das eigentlich mit den Zitaten?

    Unter jedem Beitrag findest Du einen "Zitieren"-Link. Hilfreich ist es, den betreffenden Text vorher zu markieren.



  • Danke @daMicha ,
    lesen hätte geholfen 😖



  • @tbird sagte in Clean Code / Software Principles - Wo seid ihr??:

    @hustbaer sagte in Clean Code / Software Principles - Wo seid ihr??:

    Was sind denn die "gültigen" Coding Standards? Es gibt einige Dinge die schon sehr stark verbreitet sind, wie eben z.B. englische Bezeichner. Aber wer sagt dass das ein "gültiger" Standard sein soll? Und was genau heisst "gültig" in dem Zusammenhang überhaupt?

    Es gibt hier nicht die eine offizielle Stelle die vorschreibt welche Standards vorgeschrieben bzw. empfohlen sind.

    Es gibt sehr wohl allgemeingültige Prinzipien / Standards, die einzuhalten sind, unabhängig von den "firmeninternen" coding styles.

    Nein, gibt es nicht. Wenn du anderer Meinung bist, bitte nenn mir die Entität die vorgibt welche Prinzipien/Standards einzuhalten sind und die Grundlage ihrer Autorität.

    Dazu lese bitte das Buch "Clean Code" von Robert C. Martin oder lese dich in die SOLID Prinzipien ein.

    Ich glaube du hast nicht verstanden was ich dir sagen will. Ganz egal was in dem Buch drinnen steht: auf welcher Grundlage forderst du dass es als allgemeine Autorität anerkannt werden muss?

    Es mag dir so erscheinen dass bestimmte Dinge allgemeingültig sind. Oder gar dass das sogar "klar" ist, und sich daher jeder daran halten sollte. Bloss ist das nur deine Wahrnehmung bzw. Meinung. Und du wirst genügend andere Entwickler finden die das ganz anders sehen. Bzw. die vielleicht grundsätzlich zustimmen dass bestimmte Dinge allgemeingültig sind und das auch völlig klar ist - aber nicht mit dir übereinstimmen welche Dinge das sind.

    Für "Englisch als Sprache in der Programmierung" kannst du die mal die Ergebnisse dieser Google-Suche ansehen: https://www.google.com/search?q=lingua+franca+software+development

    Also ich persönlich halte es im Allgemeinen für einen Fehler etwas anderes als Englisch für Bezeichner in Programmen zu verwenden. Wobei es Ausnahmen gibt, z.B. wenn man Programme entwickelt die gezielt auf die Rechtslage eines Landes zugeschnitten sind. Oder wenn das Programm sich ausschliesslich mit einer Problemdomäne befasst die "lingua franca" eben nicht Englisch ist.

    Ansonsten stimme ich dir natürlich zu, dass abweichende Regelungen innerhalb der Firma getroffen werden können - sie sind aber dann nicht "optimal" im Sinne des Software Designs.

    Lol.

    1. Ich habe das wo du mir da zustimmst gar nicht behauptet.

    2. Auch hier ist wieder das Problem dass eben nicht klar ist was die "Basis" ist von der Abweichungen gemessen werden.

    3. Ich kann selbst wenn ich die ersten beiden Punkte ignorieren nicht zustimmen. Es gibt bei so gut wie jeder Richtlinie gute Gründe davon abzuweichen bzw. sie für ein bestimmtes Projekt vielleicht sogar mit einer quasi konträren Richtlinie zu ersetzen. Gute Richtlinien führen auch eine Liste an von bekannten, guten Gründen von der Richtlinie abzuweichen. Nur fehlt diese auch oft, und vor allem kann man nicht davon ausgehen dass sie vollständig ist.

    Wobei mir 3 hier gar nicht so wichtig ist. Der Punkt den ich primär vermitteln wollte ist 2.



  • @Quiche-Lorraine sagte in Clean Code / Software Principles - Wo seid ihr??:

    @hustbaer sagte in Clean Code / Software Principles - Wo seid ihr??:

    Was sind denn die "gültigen" Coding Standards?

    Ich kenne da den MISRA-C Standard.

    MISRA-C ist zwar ein Standard der AFAIK in bestimmten Bereichen vorgeschrieben ist - aber eben nur in bestimmten Bereichen. D.h. er ist definitiv nicht allgemeingültig.



  • @Columbo sagte in Clean Code / Software Principles - Wo seid ihr??:

    Es gibt hier nicht die eine offizielle Stelle die vorschreibt welche Standards vorgeschrieben bzw. empfohlen sind.

    Zuallererst darf man nicht vergessen, dass der durchaus gueltige C++ Standard selbst auf Englisch verfasst ist, und entsprechend auch die Standardbibliothek und alle keywords etc. englisch sind. Das ist eine normative Basis fuer jeden C++ Code.

    Ein weiterer grosser Faktor ist die Lesbarkeit/Verstaendlichkeit von Code fuer andere Programmierer. Programmierer im internationalen und auch interregionalen Jobmarkt haben Englisch eben als gemeinsamen Nenner. Wie man im Internet lesen kann, schreiben auch asiatische Firmen ihren Code auf Englisch (und kommentieren ihn groessenteils auch darin). Das wird sich auch hoechstwahrscheinlich niemals aendern.

    Natuerlich kann eine deutsche Firma ihren Code deutsch schreiben, aber das wird schon ziemlich unleserlich wirken, wenn man APIs/Bibliotheken etc. benutzt die alle auf Englisch sind. Die Sprache sickert eben von "oben" (Standard & wichtige Bibliotheken/APIs, POSIX etc.) herab. Sich dagegen zu stemmen hat wenig Sinn.

    Ob es jetzt eine gute Idee ist Englisch für Bezeichner zu verwenden oder nicht ist für das worum es mir ging völlig egal. Mir ging es darum, dass @tbird hier ein paar ziemlich eindeutig absolute Aussagen gemacht hat -- und ich auf Grund seines Schreibstils auch angenommen habe dass das keine Schlampigkeit/Bequemlichkeit war, sondern ernstgemeinter Dogmatismus. Und den wollte ich nicht unkommentiert lassen.

    In seiner Antwort wird das auch nochmal schön klar:

    Es gibt sehr wohl allgemeingültige Prinzipien / Standards, die einzuhalten sind, unabhängig von den "firmeninternen" coding styles.

    Viel eindeutiger dogmatisch und absolut kann man das kaum formulieren. Und in dieser Form ist die Aussage mMn. einfach nur Quatsch.

    Genau so Quatsch wie wenn ich behaupten würde es gäbe allgemeingültige Schönheitsideale oder einen globalen Konsens darüber ob wir zwecks Senkung der CO2 Emissionen in Kernkraft investieren sollten.


    z.T. Englisch: ich stimme deinen Argumenten grösstenteils zu. Ich rate auch immer wieder Englisch zu lernen wenn ich sehe dass Leuten z.B. deutsche Compiler-Fehlermeldungen posten oder explizit (nur) nach deutschen Büchern/Tutorials fragen.

    Ich bin nur der Meinung dass es kein Argument gibt aus dem man ableiten könnte dass jeder das so sehen muss. Also dass Englisch die lingua franca der Informatik ist bestreite ich nicht. Das heisst aber nicht automatisch dass es auch für jedes Projekt oder jede Firma am sinnvollsten ist alles in Englisch zu schreiben.

    Es gibt sogar ein halbwegs gutes Gegenargument: Es gibt immer noch viele Programmierer bzw. Leute denen man das Programmieren leicht beibringen könnte (weil sie intelligent genug sind und die Grundlagen der Logik verstehen), die aber nicht Englisch können. Und diese kann man nicht einsetzen, wenn man alles in Englisch schreibt. Das Set an englischen Fachbegriffen die in der Standard Library vorkommen ist nicht sehr gross - und nur diese zu lernen ist ein viel geringerer Aufwand als sämtliche Begriffe + Grammatik zu lernen die mach braucht um englischen Code inklusive Kommentaren in der jeweiligen Problemdomäne zu verstehen.

    Gerade für kleinere Firmen kann das durchaus wichtig sein. Kleine Firmen können oft keine konkurrenzfähigen Gehälter zahlen und sind auch oft für internationale Bewerber nicht interessant - z.B. weil sie zu viele Positionen (Projektleiter, Personalbüro etc.) mit Personen besetzt haben die nicht Englisch können. Und so kann es für solche Firmen eben Sinn machen wenn sie ihren Code in der Muttersprache des eigenen Landes schreiben, damit sie Programmierer einsetzen können die nicht Englisch können.

    Und daher kann ich einer dogmatischen Aussage wie "wer was anderes als Englisch für Code verwendet, macht eindeutlich was falsch" (sinngemäss) nicht zustimmen.



  • @tbird sagte in Clean Code / Software Principles - Wo seid ihr??:

    Es gibt Auftraggeber, die für ihre hausinterne Software ein Dokumentationssprache vorschreiben. Das beinhaltet dann manchmal auch Klassen-, Attribut-, Methoden- und Variablennamen. Insbesonders dann, wenn von einem Geschäftsprozess aus eine Software entwickelt wird und durchgängig von der Fachabteilung verstanden werden soll.

    Dann läuft in dieser Firma grunsätzlich etwas schief...

    Ich denke dir fehlt etwas die Erfahrung bzw. der Blick über den Tellerrand.

    Fast jede Firma braucht Software, nicht nur Softwarefirmen. Und ab einer bestimmten Grösse ist da quasi immer "eigene" Software dabei, sei's jetzt von hausinternen Programmierern entwickelt oder von externen Firmen. Und in vielen Firmen, speziell nicht-IT Firmen, gibt es halt auch genug Leute die nicht oder nicht gut Englisch können. Oft auch Abteilungsleiter/Projektleiter/Key User etc. Wenn die dann die Doku nicht verstehen können, weil sie in Englisch ist, dann hast du ein Problem.

    Das heisst nicht automatisch dass die Software unbedingt in der Landessprache geschrieben sein muss. Aber es kann durchaus die bessere Lösung sein. Denn das Gemisch zwischen dem Englisch der Programmiersprache/Standardlibrary und der Landessprache in der Doku hast du dann sowieso, notwendigerweise. Die Frage ist dann nur wo man am besten die Grenze zieht. Und darauf gibt es keine klare, allgemeingültige Antwort.


  • Mod

    @hustbaer sagte in Clean Code / Software Principles - Wo seid ihr??:

    Fast jede Firma braucht Software, nicht nur Softwarefirmen. Und ab einer bestimmten Grösse ist da quasi immer "eigene" Software dabei, sei's jetzt von hausinternen Programmierern entwickelt oder von externen Firmen. Und in vielen Firmen, speziell nicht-IT Firmen, gibt es halt auch genug Leute die nicht oder nicht gut Englisch können. Oft auch Abteilungsleiter/Projektleiter/Key User etc. Wenn die dann die Doku nicht verstehen können, weil sie in Englisch ist, dann hast du ein Problem.

    Ojeh, wir sind also in einer Firma, die groß genug ist, um ihre eigene Technik zu machen, aber die Programmierer und/oder Manager sind weder in der Lage, den neuesten Stand der Technik zu verfolgen, noch international zu kooperieren. Da ist die Einschätzung, dass in der Firma etwas grundsätzlich schief läuft, schon ganz angebracht. Programmierer die nur Deutsch können, kannst du vielleicht vor 30 Jahren rechtfertigen, wo die Welt noch nicht so groß und verknüpft war, und man mit einer einfachen Ausbildung schon als Fachexperte zählen konnte. Heute heißt das, dass so jemand nur Jürgen Wolf lesen kann, anstatt Stackoverflow, und alle Entwicklungen der letzten 5-15 Jahre sind auch unzugänglich. Ich bin sicher, für Management gilt ähnliches.

    Ich arbeite bei einer Firma, bei der tatsächlich auch deutsche Technikdokumentation herumgeistert (eben jene, die in den 1980ern geschrieben wurde), mit dem Resultat, dass man heute den Zusatzaufwand hineinstecken muss um ausländische Fachkräfte einzuführen. Das schlimsmte ist, das man da in den 1980ern denselben Aufwand umgekehrt betrieben hat, den das sind alles selbstausgedachte Übersetzungen (auch damals schon wurde alle neue Technik international auf Englisch dokumentiert…) und die interne Übersetzung, die man sich damals ausgedacht hat, ist quasi die Definition wie diese Begriffe auf Deutsch lauten. Von daher kann man auch niemanden anweisen, einfach eine Übersetzungsmaschine zu nutzen.

    Da ist es natürlich trotzdem vertretbar, weil man 1980 in der BRD nicht genug englischsprachige Ingenieure zu dem Thema finden konnte. Aber wenn du das heute noch machen musst, dann hat deine Firma ein Problem, ein großes.



  • @SeppJ sagte in Clean Code / Software Principles - Wo seid ihr??:

    Da ist es natürlich trotzdem vertretbar, weil man 1980 in der BRD nicht genug englischsprachige Ingenieure zu dem Thema finden konnte. Aber wenn du das heute noch machen musst, dann hat deine Firma ein Problem, ein großes.

    Wer sich bei überwiegend deutschsprachigen Mitarbeitern für eine englischsprachige Dokumentation entscheidet, wenn es dafür keine externen Gründe gibt, der entscheidet sich für eine schlechtere Dokumentation! Oder willst Du behaupten, Du wärst in der Lage Dich mit gleicher Qualität auf Englisch auszudrücken wie auf Deutsch? Es ist und bleibt eine Fremdsprache, und man erreicht niemals die gleiche Sprachkompetenz in einer Fremdsprache wie in der eigenen Muttersprache.



  • @SeppJ
    Vorweg: ich arbeite nicht in einer solchen Firma.

    Aber ich kenne ein paar Leute die das tun. Klar kann man da dann sagen "oh je, da läuft ja einiges falsch". Nur ändert das nix. Es ist halt einfach so. Und ein IT Leiter der strikt der Meinung ist "wir müssen jetzt alles Englisch" wird die Situation der Firma vermutlich nicht signifikant verbessern.

    in einer Firma, die groß genug ist, um ihre eigene Technik zu machen

    Nur damit wir uns nicht falsch verstehen: ich meinte da z.B. auch Firmen die sowas wie SAP oder Dynamics AX verwenden und da eigene Anpassungen/Erweiterungen drin/dran haben. Dazu muss die Firma nicht besonders gross sein. Je nach Branche reicht da ein Betrieb mit ein paar hundert Mitarbeitern.



  • @SeppJ sagte in Clean Code / Software Principles - Wo seid ihr??:

    Ojeh, wir sind also in einer Firma, die groß genug ist, um ihre eigene Technik zu machen, aber die Programmierer und/oder Manager sind weder in der Lage, den neuesten Stand der Technik zu verfolgen, noch international zu kooperieren. Da ist die Einschätzung, dass in der Firma etwas grundsätzlich schief läuft, schon ganz angebracht. Programmierer die nur Deutsch können, kannst du vielleicht vor 30 Jahren rechtfertigen, wo die Welt noch nicht so groß und verknüpft war, und man mit einer einfachen Ausbildung schon als Fachexperte zählen konnte. Heute heißt das, dass so jemand nur Jürgen Wolf lesen kann, anstatt Stackoverflow, und alle Entwicklungen der letzten 5-15 Jahre sind auch unzugänglich. Ich bin sicher, für Management gilt ähnliches.

    Nehmen wir mal an, eine Behörde will eigene Geschäftsprozesse digitalisieren. Die Geschäftsprozessbeteiligten (aus mehreren Ländern mit verschiedenen 1. und ggf. 2. Sprachen) sprechen einheitlich die Sprache der Behörde (in D wäre das deutsch, setzen die Behörden jedenfalls voraus).
    Die Geschäftsprozesse werden in der Behördensprache beschrieben, damit die Prozessbeteiligten diese verstehen können.
    Aus den Geschäftsprozessen werden z.B. UML-Aktivitätsdiagramme. Damit diese mit den zugrundeliegenden Geschäftsprozessen verglichen werden können, werden alle darin vorkommenden Artefakte wie z.B. Aktivitäten (ggf. Methoden von Klassen) auch in der Behördensprache abgefasst.
    Der Entwickler nutzt jetzt die für die "sichtbaren" Artefakte (Klassen, Methoden etc.) auch die Behördensprache. Kann natürlich jegliche anders sprachlichen Dinge z.B. aus Bibliotheken nutzen.
    Ich habe auch schon gesehen, dass auf eine englischsprachige API eine deutsche "draufgelegt" wurde.
    Wenn die Behörde ein Qualitätsmanagement betreibt, wird ein behördensprachlich sattelfester Mensch die Doku prüfen und ggf. sprachlich glattziehen.

    PS. Ich kann heutzutage alles aus dem Internet in fast jeder Sprache lesen! Translater und gesunde Interpretation.



  • @Helmut-Jakoby sagte in Clean Code / Software Principles - Wo seid ihr??:

    Ich kann heutzutage alles aus dem Internet in fast jeder Sprache lesen!

    Du glücklicher! Ich bleibe öfters mal an TLA's (z.B. MO, RCA, TBD,...) oder English von Indern, Japanern und manchmal von Schweizern hängen.


  • Mod

    @john-0 sagte in Clean Code / Software Principles - Wo seid ihr??:

    @SeppJ sagte in Clean Code / Software Principles - Wo seid ihr??:

    Da ist es natürlich trotzdem vertretbar, weil man 1980 in der BRD nicht genug englischsprachige Ingenieure zu dem Thema finden konnte. Aber wenn du das heute noch machen musst, dann hat deine Firma ein Problem, ein großes.

    Wer sich bei überwiegend deutschsprachigen Mitarbeitern für eine englischsprachige Dokumentation entscheidet, wenn es dafür keine externen Gründe gibt, der entscheidet sich für eine schlechtere Dokumentation! Oder willst Du behaupten, Du wärst in der Lage Dich mit gleicher Qualität auf Englisch auszudrücken wie auf Deutsch? Es ist und bleibt eine Fremdsprache, und man erreicht niemals die gleiche Sprachkompetenz in einer Fremdsprache wie in der eigenen Muttersprache.

    1. Ja, ich kann das. Dokumentation ist keine Poesie. Ich muss keine Ballade schreiben, die den Leser zu Tränen rührt. Wobei ich durchaus einsehe, dass ich das besser kann als andere.
    2. Das ist keine Ausrede. Der Nachteil, sich in einer Nischensprache festgefahren zu haben, ist zu gravierend.

    @hustbaer sagte in Clean Code / Software Principles - Wo seid ihr??:

    Aber ich kenne ein paar Leute die das tun. Klar kann man da dann sagen "oh je, da läuft ja einiges falsch". Nur ändert das nix. Es ist halt einfach so. Und ein IT Leiter der strikt der Meinung ist "wir müssen jetzt alles Englisch" wird die Situation der Firma vermutlich nicht signifikant verbessern.

    Dass das so gelebt wird, bestreitet wohl niemand. Aber dass das ein Zeichen dafür ist, dass in der Firma krass etwas schief läuft, doch bestreitest du doch wohl auch nicht? Eine Firma deren Experten kein Englisch sprechen, ist wie ein Restaurantkoch, der nur Sachen aus dem eigenen Garten benutzt. Er mag noch so talentiert sein, das Ergebnis wird nicht mithalten können mit der Konkurrenz, die sich aus aller Welt bedienen kann.

    @Helmut-Jakoby sagte in Clean Code / Software Principles - Wo seid ihr??:

    Der Entwickler nutzt jetzt die für die "sichtbaren" Artefakte (Klassen, Methoden etc.) auch die Behördensprache. Kann natürlich jegliche anders sprachlichen Dinge z.B. aus Bibliotheken nutzen.
    Ich habe auch schon gesehen, dass auf eine englischsprachige API eine deutsche "draufgelegt" wurde.
    Wenn die Behörde ein Qualitätsmanagement betreibt, wird ein behördensprachlich sattelfester Mensch die Doku prüfen und ggf. sprachlich glattziehen.

    Sind Behörden-IT-Projekte nicht berühmt für ihre überbordenden Kosten und ihr regelmäßiges Scheitern?


Anmelden zum Antworten