const string * == const string * const



  • @großbuchstaben
    Dass es null Informationsgehalt hat, ist mittlerweile wohl hoffentlich klar. Die Definition kann das top-level const nämlich auch weglassen, selbst wenn es in der Deklaration vorhanden war. Weil es eben wie schon mehrfach erwähnt wurde nicht mit zur Signatur gehört.

    großbuchstaben schrieb:

    seit wann entscheiden wir denn demokratisch, was ich lesbarer zu finden habe ? 😃

    Aber egal. Wer ein wirklich gutes Gegenargument (außer "alle machen aber X ...") hat, kann sich ja melden.

    Damit dass du selbst das top-level const auch bei der Deklaration dranschreibst, trainierst du dir bloss ab es auch anders schnell und ohne Anstrengung lesen zu können.
    Da der super-mega-überwiegende Grossteil allen Codes aber gerade kein top-level const verwendet, trainierst du dir also an den super-mega-überwiegende Grossteil allen Codes schlecht lesen zu können.

    Macht das Sinn?

    Nur wenn du Masochist bist, oder selten bis nie fremden Code liest. In beiden Fällen erübrigt sich mMn. die Diskussion.

    In allen anderen Fällen sollte das Argument "macht aber keiner so wie du" wesentlich schwerer wiegen als das Argument "ich finds aber so besser".

    Weil dein "besser" eben kein echter Vorteil ist. Wenn da kein "&" steht, ODER vor dem "&" ein const steht, ist klar, dass es kein Output-Parameter ist. Wenn man ein unbeschädigtes Sehzentrum hat, kann man das mit etwas Übung mit einem Blick erfassen.



  • ps:

    großbuchstaben schrieb:

    Aber die Entscheidung, in was für Sprachen ich programmiere, überläßt Du besser mir.

    Du überschätzt dich und die Qualität deine Einschätzung bestimmter Dinge ziemlich. Vielleicht solltest du bestimmte Entscheidungen lieber nicht selbst treffen, sondern dich nach anderen, erfahreneren und schlaueren Leuten richten.

    Aber hey. Ich muss mit grosser Wahrscheinlichkeit nie ein von dir geschriebenes Programm lesen oder gar warten. => Tu was du glaubst.



  • hustbaer schrieb:

    Du überschätzt dich und die Qualität deine Einschätzung bestimmter Dinge ziemlich. Vielleicht solltest du bestimmte Entscheidungen lieber nicht selbst treffen, sondern dich nach anderen, erfahreneren und schlaueren Leuten richten.

    wieso denn gleich persönlich werden?
    Unsicher geworden?

    hustbaer schrieb:

    Ich muss mit grosser Wahrscheinlichkeit nie ein von dir geschriebenes Programm lesen oder gar warten.

    mach dir keinen Kopf, wir haben im Augenblick ohnehin keinen Personalbedarf.


  • Mod

    wieso denn gleich persönlich werden?

    Du scheinst einfach nicht einsehen zu wollen, dass so gut wie jeder kompetente Entwickler dir nicht zustimmt. Genug Argumente wurden mittlerweile genannt.

    • Es ist laut allgemeinem Konsens weniger lesbar
    • Für den Caller vollkommen irrelevant
    • Für den Callee bei der Deklaration redundant und irrelevant

    Nexus schrieb:

    großbuchstaben, wärst du ernsthaft an einer Diskussion interessiert, hättest du mindestens eines meiner Argumente gelesen und wärst darauf eingegangen.

    Stattdessen pickst du dir den am einfachsten zu widerlegbaren Punkt "alle machen es" raus, reitest 2 Seiten darauf herum und lenkst mit "Demokratie" und anderem Blabla vom Thema ab.

    👍



  • Arcoth schrieb:

    Du scheinst einfach nicht einsehen zu wollen, dass so gut wie jeder kompetente Entwickler dir nicht zustimmt.

    und du scheinst nicht einsehen zu wollen, daß für mich der Geschmack der Mehrheit kein Kriterium ist. Und jetzt ? 😮



  • Ist Konsistenz mit Code anderer ein Kriterium für dich?



  • kommt drauf an. Ich passe mich gerne einem anderen Stil an, falls dieser nennenswerte Vorteile gegenüber meinem eigenen Stil hat, oder wenn er qua code style policy vorgegeben ist.

    Die Argumente "alle machen es so" oder "das const ist für den Compiler überflüssig" sind mir allerdings deutlich zu schlicht. Letztlich stehe ich für meinen Code gerade und kann jede stilistische Entscheidung wohlbegründen.

    ps. Ich habe einige Jahre lang TeX-Packages für den Produktiveinsatz programmiert (rohes TeX, nicht LaTeX) - da lernt man, sich bei jedem Makro genau zu überlegen, wie man es benennt, formatiert und kommentiert, und welchen Wert ein einheitlicher, wohlüberlegter code style hat - andernfalls wäre man schnell aufgeschmissen.



  • großbuchstaben schrieb:

    ps. Ich habe einige Jahre lang TeX-Packages für den Produktiveinsatz programmiert (rohes TeX, nicht LaTeX) - da lernt man, sich bei jedem Makro genau zu überlegen, wie man es benennt, formatiert und kommentiert, und welchen Wert ein einheitlicher, wohlüberlegter code style hat - andernfalls wäre man schnell aufgeschmissen.

    Ich habe einige Jahre in BASIC programmiert und habe da genau gelernt, daß Variablennamen maximal zwei Buchstaben haben dürfen. Bin jetzt nicht sicher, ob SeppJ glücklich wäre, wenn ich daraus ableiten würde, wie man in C++ programmieren sollte.
    So, Du hast also für Tex "programmiert". Und Du bist Dir sicher, daß Du den Tex-Stil in C++ einsetzen solltest. Ist Tex von C++ nicht noch weiter weg als BASIC?



  • die grundlegenden Tugenden guten Programmierstils

    ("programmer's intention", Kommentierung, "explizit ist besser als implizit", Modularisierung, "sprechende Bezeichner" usw) lassen sich auf fast jede Programmiersprache übertragen.

    Lektion 1, die mir meine Praxis in verschiedenen Programmiersprachen erteilt hat, war: "Mach' niemals etwas, bloß weil alle es machen".

    Und Lektion 2: Ich suche mir den Kreis meiner Lehrmeister sorgfältig aus. Poster mit -zigtausend Posts gehören übrigens für gewöhnlich nicht dazu.



  • Aber das Prinzip von Konsistenz ist dir schon klar, oder? Wir bleiben bei rot stehen und gehen bei grün los. Warum nicht andersrum? Rechtsverkehr oder Linksverkehr? Völlig egal, Hauptsache es ist einheitlich. Und wenn sich heraus stellt, dass man Blindenhunden leichter beibringen kann bei rot loszulaufen und damit die umgedrehten Farben besser sind macht es trotzdem keiner, das würde ein gigantisches Chaos verursachen.
    Mein Punkt ist, dass "Alle machen das so" ein gutes Argument ist. Dagegen muss man erstmal ankommen, was durchaus möglich ist, aber deine bisherigen Argumente reichen dafür nicht. Jetzt stellt sich die Frage, ob du den Anspruch hast andere zu überzeugen oder du lieber per Abkapseln das Konsistenzargument schwächst.

    PS: Wie gut dass es für mich keinen Beitragszähler gibt 😃



  • niemand muß sich umgewöhnen, wenn er ein Programm liest, in dem by-value Parameter ge-const-et sind. Genauso wenig, wie sich jemand umgewöhnen müßte, wenn an jeder Ampel ein Schild "bei rot gehen, bei grün stehenbleiben" angebracht wäre.

    leider wieder kein gutes Argument, nicht zu const'en. Aber vielleicht kommt ja noch ein erstes.



  • Korrektur des obigen Postings:

    Genauso wenig, wie sich jemand umgewöhnen müßte, wenn an jeder Ampel ein
    Schild "bei grün gehen, bei rot stehenbleiben" angebracht wäre.



  • großbuchstaben schrieb:

    leider wieder kein gutes Argument, nicht zu const'en. Aber vielleicht kommt ja noch ein erstes.

    Wie wärs mit einem simplen, wie schon von mir genannt: Ich will by-Value Parameter innerhalb der Funktion verändern.



  • großbuchstaben schrieb:

    Genauso wenig, wie sich jemand umgewöhnen müßte, wenn an jeder Ampel ein Schild "bei rot gehen, bei grün stehenbleiben" angebracht wäre.

    Als ob viele Menschen ein Schild lesen würden. In der Anfangszeit gäbe es wohl nicht wenige Tote. Du unterschätzt auch wie sehr wir Menschen Gewohnheitstiere sind. Wenn man sich etwas angewöhnt hat, ist es schwer wieder abzustellen. Dazu gehört auch schlechter Codestil.

    Man kann sich über das "const" bei by-value Parametern streiten, doch es gibt zumindest "weiche" Kriterien gegen das const an dieser Stelle. Die werden aber von dir schlicht ignoriert.

    • Es ist im Gegensatz zu Klammerung ein fast einheitlich üblicher Stil (Bei Klammerung gibt es dahingehend einige Stile, da kann man gut auswählen).
    • Unnötige Erhöhung der Lesekomplexität. Die Angabe hat keinen Mehrwert, warum noch ein Schlüsselwort zusätzlich schreiben?
    • Obwohl Kopie, kann ich diesen Wert lokal nicht verändern? (Warum?)

    Grundsätzlich bin ich der Ansicht das man unnötige Angaben, die keinerlei Mehrwert haben auch sein lassen sollte. Ein const hat an vielen Stellen einen Mehrwert, nur hier eben nicht.

    großbuchstaben schrieb:

    niemand muß sich umgewöhnen, wenn er ein Programm liest, in dem by-value Parameter ge-const-et sind.

    Es ist sehr ungewohnt ein Schlüsselwort zu sehen, das keinen Mehrwert liefert. Ich würde zumindest etwas länger beim Lesen bei der Parameterliste verharren. Und es ist ein ganz blödes Argument etwas nur deshalb nicht so zu machen, weil es andere machen. Es sollte auch einen guten Grund dafür geben. Und der ist hier nicht gegeben.



  • überzeugt mich alles nicht. Die "programmer's intention" klar auszudrücken ist zumindest mir wichtiger.


  • Mod

    großbuchstaben schrieb:

    Die "programmer's intention" klar auszudrücken ist zumindest mir wichtiger.

    Da musste ich echt schmunzeln, bei dem Gedanken dass in diesem Thread mindestens zwanzig mal angedeutet wurde dass dadurch keine Intention ausgedrückt wird, denn dem Caller ist es ~~sch***~~schnurzegal ob die Kopie verändert wird und in der Deklaration ist es dem Callee egal.



  • ja klar, einen Parameter nicht als Rückgabe verwenden zu wollen ist ja auch keine Intention 🙄



  • großbuchstaben schrieb:

    ja klar, einen Parameter nicht als Rückgabe verwenden zu wollen ist ja auch keine Intention 🙄

    Es ist ja nicht so, dass die Intention durch das fehlende const nicht ausgedrückt wird. Sie ist ja so oder so klar erkennbar.
    Ein const davor hinzuschreiben bringt lediglich eine bereits vorhandene Information nochmal zum Ausdruck, hat allerdings zur Folge, dass
    a) der Leser, der das nicht gewohnt ist - d.h. die Mehrheit, verwirrt ist.
    b) der Implementierer eingeschränkt ist, da er nicht kopieren kann, da er die Kopie nicht veändern kann.
    c) man unnötigerweise alle Funktionen ohne Outputparameter - d.h. die Mehrheit, mit komplett unnötigen Informationen vollklatscht, die die Zeilenlänge erhöhen, mehr zu tippen sind und den Lesefluss stören.



  • ad a) was ist an einem const verwirrend ?

    ad b) ???

    ad c) Bei mir nicht. Spätestens ab 3 Parameter bekommt bei mir jeder Parameter seine eigene Zeile, meistens schon ab 2.


  • Mod

    großbuchstaben schrieb:

    ad a) was ist an einem const verwirrend ?

    "Hey, Peter, meiner Freundin fehlt komischerweise ein Höschen. Schmeißt' mal ein Bier rüber?"
    <Peter schmeißt das Bier> "Ja und weiter?"
    "Nichts."
    "Äh, ok...?"
    Peter ist verwirrt. Wollte sein Freund ihm irgendetwas andeuten? Warum hat er das wohl gesagt? Denkt er, Peter klaut die Höschen seiner Freundin?

    Für den Rest des Abends bleibt das stehts in Peters Hinterkopf.
    ~
    Edit: Logik korrigiert.~


Anmelden zum Antworten