AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Suchfunktion Ergebnis der Suchanfrage

Ergebnis der Suchanfrage


Datum des Suchindex: Heute, 11:47

Parameter dieser Suchanfrage:

Suche in Thema: Die "richtige" Sourcecode Formatierung?
Suche alle Beiträge, die von "jaenicke" geschrieben wurden
• Suchmethode: "Suche nach allen Begriffen"
• Nach Datum (firstpost) sortiert
• Zeige Treffer als Beiträge
Zeige 6 von insges. 6 Treffern
Suche benötigte 0.002s

Es liegen Ergebnisse in folgenden Bereichen vor:

  • Forum: Object-Pascal / Delphi-Language

    AW: Die "richtige" Sourcecode Formatierung?

      Delphi
      by jaenicke, 13. Aug 2016
    Dann sind wir uns ja einig, deshalb hatte ich im Beispiel auch den Konstruktor genommen. Bei Settern ist das sicher richtig, die ruft man ja in der Regel außerdem ohnehin nicht direkt auf. Mir ging es ja um die Hilfetexte, die beim Aufruf sagen welche Parameter nötig sind.

    In Delphi mault der Compiler nur, wenn du die Parameter als const deklarierst. Ansonsten darfst du auch problemlos dem...
  • Forum: Object-Pascal / Delphi-Language

    AW: Die "richtige" Sourcecode Formatierung?

      Delphi
      by jaenicke, 12. Aug 2016
    Dann musst du bei einem solchen Code aber jedesmal nachschauen was der Parameter bedeutet. Das ist finde ich die schlimmste Variante...
    Vor allem, wenn es mehr als einen Parameter gibt...
  • Forum: Object-Pascal / Delphi-Language

    AW: Die "richtige" Sourcecode Formatierung?

      Delphi
      by jaenicke, 12. Aug 2016
    Wie sieht denn deine Alternative für mein Beispiel aus?

    // EDIT:
    Das bezweifle ich auch nicht, aber da die delphieigenen Bezeichner zwangsläufig englisch sind, läuft es immer auf ein Mischmasch aus Deutsch und Englisch hinaus...
    Das macht den Code nicht übersichtlicher...

    Beispiel aus freier Wildbahn:
    if SchnellstartHaken.Checked or ZwangsstartAktiviert then
    begin
    StartenKnopf.Click;
  • Forum: Object-Pascal / Delphi-Language

    AW: Die "richtige" Sourcecode Formatierung?

      Delphi
      by jaenicke, 12. Aug 2016
    Das bezweifle ich. Ich habe ja das AOwner als Beispiel genannt. Da gibt es in der Klasse gleichzeitig noch Owner als Property. Und wenn man sich mal anschaut wo das noch auftauchte in älteren Quelltexten findest du noch weitere solche Fälle.

    Einen Fall wie den von dir genannten sehe ich hingegen nirgends. Worauf beziehst du dich denn da? Im RTL oder VCL Quelltext meine ich.

    Das heißt bei...
  • Forum: Object-Pascal / Delphi-Language

    AW: Die "richtige" Sourcecode Formatierung?

      Delphi
      by jaenicke, 12. Aug 2016
    Das mache ich auch so. Meistens als Delphi, 3rd-Party, Common (das sind unsere gemeinsamen Units für alle Projekte) und Project unterteilt. Wir benutzen auch Common als Namespace für diese gemeinsamen Units und einen projektspezifischen für die Units im Projekt. So kann dann eine Unit zum Beispiel heißen Common.Utils.StringTools.pas. Diese liegt dann im Verzeichnis common/utils im Repository. Und...
  • Forum: Object-Pascal / Delphi-Language

    AW: Die "richtige" Sourcecode Formatierung?

      Delphi
      by jaenicke, 9. Aug 2016
    Für mich sind bei der Formatierung wichtig:

    Zwingend per Codeformatter machbar (nur manuell formatieren können ist Blödsinn, das dauert viel zu lange, wenn ich fremden Quelltext einpflegen muss usw.)
    Weite Verbreitung der Formatierung, keine Sonderlocken
    Natürliches Schreiben: keine tausend unnötige Leerzeichen oder ähnliches
    Ein Befehl pro Zeile (damit man nicht erst die ganze Zeile...


URL zu dieser Suchanfrage:

https://www.delphipraxis.net/dp_search.php?do=usersearch&search_username=jaenicke&search_exact_username=1&search_sortby=dateline&search_resulttype=post&search_matchmode=0&searchthreadid=189924
Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 12:07 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz