Ist es sinnvoll mit Regionen zu arbeiten ?

  • VB.NET

Es gibt 15 Antworten in diesem Thema. Der letzte Beitrag () ist von Patrick1993.

    Ist es sinnvoll mit Regionen zu arbeiten ?

    Hallo Leute,
    Wie der Titel schon sagt wollte ich mal fragen ob es Sinnvoll ist in größeren Programmen die mehrere funktionen haben mit Regionen zu arbeiten anstatt die ganzen Codes zu kommentieren.

    Freue mich auf Antworten

    MFG
    Patrick

    Edit by Manschula: Thema aus dem OffTopic-Bereich verschoben

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

    Ich würde sagen das kann man nicht allgemein gültig sagen, das musst du für dich selbst entscheiden. Sinnvoll ist es denke ich schon aber ich würde nicht sagen entweder Regions oder Kommentare sondern eher "und", da die beiden eigentlich nichts miteinander zu tun haben.

    Trotz alledem musst du selbst entscheiden ob es für dich Sinn macht oder nicht.
    lg.

    LucaWelker

    LucaWelker schrieb:

    ich würde nicht sagen entweder Regions oder Kommentare sondern eher "und"


    Also beides nutzen ok mehr wollte ich garnicht wissen.

    Mir ging es nur darum den ganzen Code ein wenig Visuel zu verbessern das nicht 3km Grüne Kommentare da rum fliegen und das ich den Code in diverse Bereiche unterteilen kann was ich natürlich auch mit Kommentaren machen kann doch ich finde mit regionen sieht es meiner ansicht nach besser aus

    ich würde auch sagen "und"!

    regionen unterteilen ja ganze codeblöcke die eine bestimmte funktion wahrnehmen (z.B. das Speichern/Laden von eigenen Klassen, Auswerten von Messdaten, auszuführende Events, Variablendeklarationen, Properties, etc).
    kommentare kommentieren alles mögliche, sie beschreiben, was in einem Codeblock passiert und weisen auf besonerheiten hin (und das kann die alleinige "überschrift" in form einer region ja nicht) oder sagen was in einem codeabschnitt passiert wenn der code relativ komplex ist (=> Speichert das Projekt in eine Datei; etc)

    Ich erkläre mal klein aber fein warum ich frage
    Ich bin ein Programm am basteln das einige Funktionen hat.
    Und da mir mit der zeit beim Grünenkommentare lesen die Augen weh tun, wollte ich die funktioenen an sich ein wenig Aufbessern indem ich z.b. in der funktion lesen lasse und dann halt über die funktion schreibe was in der funktion an sich gemacht wird bzw wofür die funktion sein soll.

    Aber ich habe aus den bis jetzt eingegangenen Antworten genug Infos und meine Frage ist mehr als oft Beantwortet worden.

    Patrick1993 schrieb:

    Und da mir mit der zeit beim Grünenkommentare lesen die Augen weh tun


    Kannst du doch ändern :huh:

    Extras > Optionen > Schriftarten und Farben
    „Was daraus gefolgert werden kann ist, dass jeder intelligentere User sein Geld lieber für Bier ausgibt, um einen schönen Rausch zu haben, und nicht dieses Ranzprodukt.“

    -Auszug aus einer Unterhaltung über das iPhone und dessen Vermarktung.

    Statt der Regionen kannst Du auch Deinen Quellcode auf mehrere Files verteilen, was mir persönlich besser gefällt:
    Dieser Inhalt in mehreren Files und schon hast Du Ordnung

    VB.NET-Quellcode

    1. Partial Class Class1
    2. ' bla
    3. End Class
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    Hi
    Regions machen schon Sinn, wenn man sie richtig verwendet. Durch Regionen kann man den Code in Abschnitte gliedern, die zusammenhängende Funktionen erfüllen. Da man teilweise Klassen hat, die mehrere tausend Zeilen haben, aber von Funktionen häufig ähnliche Aufgaben erfüllt werden (z.B. durch Optimierungen für bestimmte Fälle) oder aber Funktionen, die einen bestimmten Zweck erfüllen und wiederum ganz andere Funktionen, die nichts mit den anderen zu tun haben, macht es Sinn, sowas in Regionen zu unterteilen. (Es gibt natürlich auch andere Fälle.) Es macht meiner Meinung nach keinen Sinn, den Code in Methoden, Eigenschaften, Events usw. zu unterteilen. Was ich des öfteren mal mache, ist, statische Methoden in Regions zu fassen, da ich dadurch verhindere, dass ich aus Versehen nicht-statische Methoden zwischenrein setze. Da macht es aber häufig auch Sinn, sie in eine partielle Klasse auszulagern.

    Gruß
    ~blaze~

    ~blaze~ schrieb:

    Da macht es aber häufig auch Sinn, sie in eine partielle Klasse auszulagern.

    Insbesondere, weil man denen auch klingende Namen geben kann:
    Class1.Installation.vb
    Class1.Kommunikation.vb
    class1.Finish.vb
    und solch. :thumbsup:
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    Patrick1993 schrieb:

    Zitat von »LucaWelker«
    ich würde nicht sagen entweder Regions oder Kommentare sondern eher "und"
    Theoretisch richtig wäre "oder". "Und" ist zwar aussagekräftiger, schließt aber Fälle, wo man keine Regions bzw. Kommentare benutzen sollte, aus.

    Ich glaube ich bleibe vorerst bei meinen Kommentaren bis das Programm wachsen tut

    Patrick1993 schrieb:

    Ich glaube ich bleibe vorerst bei meinen Kommentaren bis das Programm wachsen tut

    Sieh dir mal folgendes "Programm" an:
    Beispielcode

    VB.NET-Quellcode

    1. Imports System.ComponentModel
    3. Public Class KatalogObjektVM
    4. Implements INotifyPropertyChanged
    6. #Region "IPNC"
    7. Public Event PropertyChanged(sender As Object, e As System.ComponentModel.PropertyChangedEventArgs) Implements System.ComponentModel.INotifyPropertyChanged.PropertyChanged
    8. #End Region
    10. #Region "Properties"
    12. Private _filenamethumb As String
    13. Property FileNameThumb As String
    14. Set(value As String)
    15. _filenamethumb = value
    16. RaiseEvent PropertyChanged(Me,
    17. New PropertyChangedEventArgs("FileNameThumb"))
    18. End Set
    19. Get
    20. Return _filenamethumb
    21. End Get
    22. End Property
    24. Private _filenamePDF As String
    25. Property FileNamePDF As String
    26. Set(value As String)
    27. _filenamePDF = value
    28. RaiseEvent PropertyChanged(Me,
    29. New PropertyChangedEventArgs("FileNamePDF"))
    31. End Set
    32. Get
    33. Return _filenamePDF
    34. End Get
    35. End Property
    37. Private _description As String
    38. Property Description As String
    39. Set(value As String)
    40. _description = value
    41. RaiseEvent PropertyChanged(Me,
    42. New PropertyChangedEventArgs("Description"))
    44. End Set
    45. Get
    46. Return _description
    47. End Get
    48. End Property
    50. Private _title As String
    51. Property Title As String
    52. Set(value As String)
    53. _title = value
    54. RaiseEvent PropertyChanged(Me,
    55. New PropertyChangedEventArgs("Title"))
    56. End Set
    57. Get
    58. Return _title
    59. End Get
    60. End Property
    62. Private _keywords As New List(Of String)
    63. Property Keywords As List(Of String)
    64. Set(value As List(Of String))
    65. _keywords = value
    66. RaiseEvent PropertyChanged(Me,
    67. New PropertyChangedEventArgs("Keywords"))
    68. End Set
    69. Get
    70. Return _keywords
    71. End Get
    72. End Property
    74. #End Region
    76. End Class

    Dies sind nur fünf Properties und ein Event. Das hier macht ein Programmierer in der Früh vor dem Zähneputzen, so mickrig ist das.
    Sind hier Regions sinnvoll oder nicht? Ich meine, ja...

    Ich hab schon immer mit Kommentaren gearbeitet woltle nun auch mal wissen was der unterschied zwischen A und B ist da ich ihn nun kenne hat sich das Thema erledigt

Facebook
Telefonspende