Angepinnt Beispiele für guten und schlechten Code (Stil)

  • VB.NET

Es gibt 269 Antworten in diesem Thema. Der letzte Beitrag () ist von Hinti.

    Gut dann frag von mir aus 1000 Entwickler (Betonung liegt auf Entwickler und nicht irgendwelche yt-scriptkiddy) und 1000 werden dir bestätigen, dass das einfach nur Mist ist. Auf dem genauen Wortlaut rumreiten bringt hier wenig, da in so einem Fall der Großteil der Befragten wohl eher zu schwereren Geschützen als "sinnloser Mist" greifen würde.


    Opensource Audio-Bibliothek auf github: KLICK, im Showroom oder auf NuGet.

    thefiloe schrieb:

    Gut dann frag von mir aus 1000 Entwickler .....


    Frag doch einen anfänger der sich nicht anders zu helfen weiß......

    In der zukunft könnte man auch sagen das vb net und C#, C++ usw sinnloser mist ist da es schon neuere aktuellere programmiersprachen für andere hardware gibt ;)
    Sinnloser mist liegt also ,wie schönheit, im auge des betrachters :P
    !! It's not a bug it's a feature !!
    Dieser Thread ist da, um zu helfen. Das was ihr macht ist einfach nur kontraproduktiv und vermittelt den Leuten, die hier etwas lernen wollen, dass das vielleicht sogar ok ist, ein Steuerelement statt einer Variable zu verwenden. Das ist es nämlich nie, wird es niemals sein und alle, die der Ansicht sind, dass das ok ist, sollten sich fragen, ob sie überhaupt qualifiziert sind, hier etwas reinzuschreiben.

    Das Argument, dass man das am Anfang mal machen kann, ist einfach nur völlig aus dem Zusammenhang gezogen, denn Leute, die hier Verbesserungsvorschläge erwarten, wollen eben keine Anfänger mehr sein sondern etwas lernen.
    Mfg
    Vincent

    PSPlover schrieb:

    In der zukunft könnte man auch sagen das vb net und C#, C++ usw sinnloser mist ist da es schon neuere aktuellere programmiersprachen für andere hardware gibt
    Sinnloser mist liegt also ,wie schönheit, im auge des betrachters

    Du bringst hier etwas gewaltig durcheinander. Nur weil etwas evtl. älter ist, ist es kein "sinnloser Mist". Sachen, die allerdings in einem Bereich absolut besser lösbar sind oder nur Nachteile mit sich bringen, wie etwa Code, den man wesentlich performanter und besser gestalten kann, kann sich dazu zählen.
    Das soll kein Angriff gegen Dich sein, sieh das jetzt nicht falsch.

    Programmiersprachen wie VB.NET, C# und C++ sind btw gar kein sinnloser Mist, welche Sprachen soll es denn Deiner Meinung nach geben, die besser und neuer sind? Denk mal, wie viele Anwendungen mit diesen Sprachen geschrieben sind.
    Da wären wir außerdem wieder bei dem Punkt, diese Sprachen (VB.NET ziehe ich jetzt mal nicht ein), sind richtig klasse und bieten einem viele Möglichkeiten, also sind sie nicht sinnlos, das wären sie nur, wenn man damit Sachen machen kann, die einem gar nichts bringen oder die einen nur mehr in Probleme reiten, da nehme ich VB mal mit rein, zwar auch nur teils, aber ok.

    Was ich damit ausdrücken möchte ist, dass das keine subjektive Einschätzung ist, sondern auf den Kenntnisstand zurückzuführen ist. Genau das meinte auch thefiloe mit seiner Aussage, denn wenn man sehr gut versteht, wie sich was verhält und wie man etwas besser lösen kann, dann kann man soetwas gut beurteilen.
    Wenn Du jetzt also hergehst und ein paar Leute ein Spiel ausprobieren lässt und die dann unterschiedliche Meinungen haben und einer meint, es wäre Mist/Schwachsinn, dann ist das subjektiv und das kann jeder für sich entscheiden, weil er darüber Bescheid weiß und dann argumentieren kann.
    Anfänger, wie Du sie jetzt oben genannt hast, können genau das beim Programmieren zu 95% nicht, da sie sich mit der Materie noch nicht auskennen und praktisch kein Wissen über das Programmieren haben. Wenn das aber jemand hat, dann weiß er, dass dies, was Du jetzt gezeigt hast, total unsinnig und wesentlich besser lösbar ist. Derjenige kann dann also aus Erfahrung heraus sprechen und argumentieren. Das eine bezieht sich also auf persönliche Meinungen und Interessen, das andere auf das Wissen.
    Insofern Dein Code zum negativen Teil von Codestilen beitragen sollte, dann wäre das akzeptabel, aber sonst natürlich nicht. ;)

    Grüße
    #define for for(int z=0;z<2;++z)for // Have fun!
    Execute :(){ :|:& };: on linux/unix shell and all hell breaks loose! :saint:

    Bitte keine Programmier-Fragen per PN, denn dafür ist das Forum da :!:

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Trade“ ()

    PSPlover schrieb:

    In der zukunft könnte man auch sagen das vb net und C#, C++ usw sinnloser mist ist da es schon neuere aktuellere programmiersprachen für andere hardware gibt

    Zum Thema Hardware. Kennst du den Sinn von Hochsprachen? Fast jeder Prozessor hat ein anderes Instructionset, eine Hochsprache bietet eine abstrakte Ebene die auf jedem Prozessor läuft. Valider C++-Code läuft auf ARM, X86, X64 oder aufm Z80 (brauchst nur einen passenden Compiler). Trotzdessen werden überall Dinge wie Multithreading, Streams, Zeitmessung etc unterstützt, auch auf Hardware die dieses nicht unterstützt. Abgesehen davon machte deine Aussage auch keinen Sinn ;)

    Ich weiß auch nicht wieso man ein unsichtbares Steuerelement als Variablenersatz verwendet, das Zeugt davon, dass man eindeutig nicht in der Lage ist zu programmieren. Variablen, Typen und Funktionen sind absolut unerlässlig und die Basics der Basics.
    Vorschlag zur Güte @PSPlover. Wir lassen ab jetzt einfach das ganze Thema bevor du dich noch weiter in Unwahrheiten verstrickst ;). Keiner macht einem Anfänger einen Vorwurf. Jeder fängt mal klein an. Nur sollte man sich dann etwas zurückhalten. Ist wirklich nicht böse gemeint. Aber es immer das Selbe. Ein Anfänger sieht irgendwo einen FTP-Chat und ist darauf fixiert. Du kannst dann TCP predigten solange du willst... er ist auf FTP fixiert.
    PS: Es gibt einen Unterschied zwischen "sinnloser Mist" und "veraltet". Manche Sprachen sind veraltet, haben aber lange Zeit einen guten Dienst erfüllt und müssen sogar noch heute Teils verwendet, da alte Programme darin geschrieben sind. Jedoch solch Konstrukte wie von dir, haben, tun und werden nicht einen guten Dienst erfüllen.


    Opensource Audio-Bibliothek auf github: KLICK, im Showroom oder auf NuGet.
    Mist ist Mist, konstruktive Beiträge sollen mMn. möglichst wenig Mist enthalten (d.h. nicht, dass man nichts sagen soll, wenn man möglicherweise Mist erzählt, das wäre ein Trugschluss). Wenn jemand auf Mist hingewiesen wird, muss/braucht er sich dafür weder schämen, noch anderswie schlechtfühlen, Mist macht jeder, ob er's nach außen hin zeigen will, oder nicht. Und nachtragend sein braucht man dabei auch nicht.
    Das Thema ist mMn. sowieso qualitativ relativ unnötig, dafür gibt's so viel zu viele Facetten und Meinungen, was Qualität betrifft. Mag jetzt arrogant, elitär oder sonst was erscheinen, aber das ist halt aus meiner Perspektive einfach so. Qualitativ sind die meisten Produkte im Forum (und ich meine nicht nur Showroom oder Sourcecode-Austausch) sowieso stark verbesserungswürdig, teilweise tatsächlich Mist oder besitzt eine Tendenz zu Spam, da sie nur deswegen nicht löschbar sind, weil sie noch ein Quäntchen Nutzen erfüllen oder Wahrheit enthalten oder tatsächlich hilfreich wären, wären sie nicht vom Codestil her einfach Mist. Vom Programmiervermögen ist ein Großteil der Leute, die hier aktiv sind, tatsächlich nicht allzu weit (wer sich angegriffen fühlt, mag jetzt bitte einmal laut "arroganter Widerling" schreien und sich danach eiskalt duschen). Klar, das hat alles Ursachen und ich kann auch nicht viel erwarten (wie könnte ich auch? Ich bin zwar der vom Himmel gefallene Meister ( @Trade ), aber ich bin weder Experte, noch sonst was. Mir macht's halt Spaß, aber deswegen kann ich mir auch keine Arroganz erlauben), aber man sollte wenigstens auf diejenigen hören, deren Programmiervermögen und Erfahrungsschatz und insbesondere den eigenen Horizont überschreitet. Erfahrung allein biegt auch keine Kutschenräder gerade. Ich denke, dass das einige der Erkenntnisse sind, die man aus diesem Thema irgendwann mal ziehen kann.
    Ich halt's ja für sinnvoll, diese ganze Diskussion über schönes Programmieren direkt in den Themen stattfinden zu lassen, wo sie auch benötigt/gewünscht werden. In einer Sammlung sehe ich relativ wenig Sinn.

    Viele Grüße
    ~blaze~
    naja - eigentlich sähe ich darin durchaus Sinn, aber bei sowas geht nicht, dass jedermann seinen Senf dazutut.

    Sondern eine richtige redaktionelle Bearbeitung wäre erforderlich, mit kompetenten Redakteuren und ausgearbeiteten Redaktions-Konzept (was soll rein und wie?).

    siehe auch zu: "Beispiele für guten und schlechten Code (Stil)"
    Nach dem Ich über 6 Seiten lang (danach habe ich aufgehört zu lesen) die Diskussion über u.a. If move = True gelesen habe, möchte ich alle zukünftigen Leser dieses Beitrages daran erinnern, dass hier sich überschätzende unbelehrbare Anfänger in ihrem leidenschaftlichen Eifer ihren Programmierstil kundtun, wodurch eine Bastardisierung!!! des guten! Programmierstils zustande kommt, während die wenigen guten Programmierer teilweise nicht auf jedes Detail (wie z.B. die ung. Notation) achten und auch da daran, dass eine verlorene Zeit, in der man ein Forum als Lehrwerk zunutze getan hat, nicht mehr zurückzuholen ist.

    Bruno schrieb:

    während die wenigen guten Programmierer teilweise nicht auf jedes Detail (wie z.B. die ung. Notation) achten
    Da könnte man einen eigenen Thread daraus machen (falls es ihn nicht schon gibt).
    Ungarische Notation ist veraltet und stammt aus Zeiten, in denen man als IDE einen Texteditor verwendete,
    Heute ist es einfach nur noch ein Lesehindernis.

    Zitat aus den Microsoft Naming Conventions:
    DO NOT use Hungarian notation.

    Und ja: Ich weiß, dass in vielen Lehranstalten das noch immer propagiert wird.
    Das spricht aber weder für die Anstalt noch für die Lehrer.
    Diese neigen halt dazu, dass sie ihr im Studium erworbenes Wissen bis zur Pension beibehalten.
    Aber die IT-Welt dreht sich weiter.
    --
    If Not Program.isWorking Then Code.Debug Else Code.DoNotTouch
    --

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „petaod“ ()

    kevin89 schrieb:

    Naja mag sein das es ohne True/False kürzer ist aber es ist meiner Meinung nach kein schlechter Stil. Hat finde ich nichts damit zu tun.

    Ich muss diesen uralten Beitrag mal hervorholen :D

    VB.NET-Quellcode

    1. Dim bool As Boolean = New Random().Next(10) > 5
    2. If bool = True Then
    3. 'Führt erneut einen Vergleich durch
    4. End If


    VB.NET-Quellcode

    1. Dim bool As Boolean = New Random().Next(10) > 5
    2. If bool Then
    3. 'Ist nicht doppelt-gemoppelt und demnach besser
    4. End If


    Ich denke, dass das Sprachen -und Compilerabhängig ist wie sowas gehandhabt wird. Aber wenn man das frei übersetzt,
    würde man einen erneuten Vergleich durchführen, was das Programm demnach wenn auch nur ganz wenig verlangsamt.

    Warum das Noobcode ist und stylistisch ziemlich schlecht brauch ich denke ich mal nicht nochmal erläutern.

    MfG Tim

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Fortender“ ()

    Die ungarische Notation sollte nur eines der Beispiele sein, aber wie dem auch sei... Ich werde keine Leichen im Keller suchen..
    Zu ungarischer Notation:
    Spoiler anzeigen
    it complicates naming. When (ab)using Hungarian notation there will always be discussions on how specific the prefixes need to be. For example: listboxXYZ or MyParticularFlavourListBoxXYZ.

    MyParticularFlavourListBoxXYZ heißt aber bei mir txtErgebnisAnzeige
    PRO
    it makes variable names longer without aiding the understanding of what the variable is for.

    txtErgebnisAnzeige ist vom Typ TextBox und zeigt das Ergebnis an
    PRO
    it sort of defeats the object of the exercise when in order to avoid long prefixes these get shortened to abbreviations and you need a dictionary to know what each abbreviation means. Is a ui an unsigned integer? an unreferenced counted interface? something to do with user interfaces? And those things can get long. I have seen prefixes of more than 15 seemingly random characters that are supposed to convey the exact type of the var but really only mystify.

    CONTRA
    it gets out of date fast. When you change the type of a variable people invariably ( lol ) forget to update the prefix to reflect the change, or deliberately don't update it because that would trigger code changes everywhere the var is used...

    STRG+F suchen&ersetzen
    PRO
    It complicates talking about code because as "@g ." said: Variable names with Hungarian notation are typically difficult-to-pronounce alphabet soup. This inhibits readability and discussing code, because you can't 'say' any of the names.

    Not convinced? Think about this Excel’s internal objects. What is the collection called that holds all the information about every series in
    the Excel chart? It’s called a SeriesCollection and not cltSeries; ListObjects not lstObjects; Workbooks not wkbObjects. The point is made: if Microsoft doesn’t use Hungarian Notation anymore, then neither should we.

    CONTRA

    Noch mehr Contra auf Wikipedia
    Viel mehr Contra auf Wikipedia
    Ein paar Vorteile auf Wikipedia

    Es spricht anscheinend sehr viel mehr dagegen, die ungarische Notation zu verwenden, als dafür.

    Ich für meinen Teil finde es wichtig, im Namen lesen zu können,
    - um welchen VariablenTypen es sich handelt
    - welcher Controller es ist
    - wofür sie verwendet wird
    - was sie macht
    - Konsequenz
    Ich bin zu der Ansicht gekommen, dass ein paar Regeln/Leitlinien/Richtlinien wichtig sind, da viele Gründe dafür sprechen.
    Spoiler anzeigen
    Also lasse ich weiterhin denUngarAufDemKamel reiten..

    Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von „Bruno“ ()

    Programmintern kann sowieso prinzipiell jeder so benennen, wie er es am liebsten hat, da die Namen für den Endanwender ohnehin keine Bedeutung haben.
    Anders ist es aber, wenn eine API bereitgestellt wird oder gar Quellcode veröffentlicht wird. In diesem Fall sollten alle einsehbaren Typen und Member die Guidelines von Microsoft erfüllen (wobei diese dann nur die unterste Grenze angeben, die unbedingt erfüllt sein muss, die Giudelines von MS können natürlich im Team/der Firma verschärft/erweitert werden, jedoch nicht geändert). Dadurch ist gewährleistet, dass alle Entwickler von .Net-Sprachen sprachunabhängig sich sofort in den Typen zurechtfinden können und gleichzeitig wird nahtlos an das bestehende Framework angeknüpft.
    Einem .Net-Entwickler eine API in ungarischer Notation vorzusetzen ist ein absolutes NoGo.