Codingstyle?

[drakon]

übrigens schrieb:

Konrad Rudolph schrieb:

Dasselbe ist aber der Fall, wenn man einen anderen Fehler-Mechanismus statt Ausnahmen verwendet. Das Problem wir dadurch dann sogar eher noch schwerer. Das Argument ist also gut, nur bezieht es sich auf eine ganz andere Behauptung, nämlich nicht „don't use exceptions“ sondern „don't modify existing code, if at all possible.“

Warum dasselbe und warum schwerer? Den returnwert einer Funnktion sieht man immer gleich, wogegen man bei exceptions nur hoffen kann, dass es im Kommentar steht oder man mus den ganzen Code der irgendwie aufgerufen werden kann durchschauen.

Und woher weisst du, was der Rückgabewert bedeutet?

[Konrad Rudolph]

übrigens schrieb:

Konrad Rudolph schrieb:

Dasselbe ist aber der Fall, wenn man einen anderen Fehler-Mechanismus statt Ausnahmen verwendet. Das Problem wir dadurch dann sogar eher noch schwerer. Das Argument ist also gut, nur bezieht es sich auf eine ganz andere Behauptung, nämlich nicht „don't use exceptions“ sondern „don't modify existing code, if at all possible.“

Warum dasselbe und warum schwerer? Den returnwert einer Funnktion sieht man immer gleich, wogegen man bei exceptions nur hoffen kann, dass es im Kommentar steht oder man mus den ganzen Code der irgendwie aufgerufen werden kann durchschauen.

Das ist irrelevant. Du musst als Aufrufer ja auch auf den Fehler reagieren. Ein einfaches if (retval != SUCCESS) return FAILURE; wird da wohl kaum ausreichen. Stattdessen muss sich der Aufrufer Gedanken darum machen, wie er den Rückgabewert behandelt, *welcher* Fehler aufgetreten ist und ob der Fehler an dieser Stelle behoben/ignoriert werden kann.

[Konrad Rudolph]

Meep Meep schrieb:

http://www.c-plusplus.net/forum/viewtopic-var-t-is-149932-and-highlight-is-meep+meep.html

ganz unten hab ich es beschrieben

Vielen Dank, das ist ein guter Tip. Da habe ich bei der Gelegenheit gleich auch mal size_t und ptrdiff_t eingetragen. Das ist zwar nicht korrekt, aber dafür konsistent mit dem VIM-Syntaxhighlighting und da ich eh meistens mit dem VIM arbeite, bietet sich das an.

[übrigens]

Konrad Rudolph schrieb:

übrigens schrieb:

Konrad Rudolph schrieb:

Dasselbe ist aber der Fall, wenn man einen anderen Fehler-Mechanismus statt Ausnahmen verwendet. Das Problem wir dadurch dann sogar eher noch schwerer. Das Argument ist also gut, nur bezieht es sich auf eine ganz andere Behauptung, nämlich nicht „don't use exceptions“ sondern „don't modify existing code, if at all possible.“

Warum dasselbe und warum schwerer? Den returnwert einer Funnktion sieht man immer gleich, wogegen man bei exceptions nur hoffen kann, dass es im Kommentar steht oder man mus den ganzen Code der irgendwie aufgerufen werden kann durchschauen.

Das ist irrelevant. Du musst als Aufrufer ja auch auf den Fehler reagieren. Ein einfaches if (retval != SUCCESS) return FAILURE; wird da wohl kaum ausreichen. Stattdessen muss sich der Aufrufer Gedanken darum machen, wie er den Rückgabewert behandelt, *welcher* Fehler aufgetreten ist und ob der Fehler an dieser Stelle behoben/ignoriert werden kann.

Wenn du um jeden Methodenaufruf ein try catch(...) machst, dann könnte es wirklich das selbe sein, aber dann hast du mit den Exceptions nicht viel mehr gewonnen als mit Returncodes. Wenn du mit den Exceptions richtig arbeiten würdest dann müsstest du auch folgendes beachten.

Given that Google's existing code is not exception-tolerant, the costs of using exceptions are somewhat greater than the costs in in a new project. The conversion process would be slow and error-prone.

Und da kannst du doch nicht behaupten, dass das dasselbe ist.

[Konrad Rudolph]

übrigens schrieb:

Konrad Rudolph schrieb:

Du musst als Aufrufer ja auch auf den Fehler reagieren. Ein einfaches if (retval != SUCCESS) return FAILURE; wird da wohl kaum ausreichen. Stattdessen muss sich der Aufrufer Gedanken darum machen, wie er den Rückgabewert behandelt, *welcher* Fehler aufgetreten ist und ob der Fehler an dieser Stelle behoben/ignoriert werden kann.

Wenn du um jeden Methodenaufruf ein try catch(...) machst, dann könnte es wirklich das selbe sein, aber dann hast du mit den Exceptions nicht viel mehr gewonnen als mit Returncodes.

Ich schrieb doch gar nicht, dass man das „um jeden Methodenaufruf“ machen muss, aber *irgendwo* muss man es machen. Sonst bräuchte man ja auch bei Ausnahmen keine Ausnahmebehandlung zu schreiben, und genau das wird hier ja behauptet.

Given that Google's existing code is not exception-tolerant, the costs of using exceptions are somewhat greater than the costs in in a new project. The conversion process would be slow and error-prone.

Und da kannst du doch nicht behaupten, dass das dasselbe ist.

Für solche Fälle eignet sich ein Proxy, sagte ich doch bereits.

[Shade Of Mine]

Konrad Rudolph schrieb:

Moment mal. Den hast ja nun aber wirklich Du angefangen.

Ich habe dir lediglich die Wahrheit gesagt. Wenn dich das beleidigt, ist das nicht mein Problem.

Ästhetik /ist/ ein technischer Grund, wenn er die Lesbarkeit beeinflusst.

Nein, aesthetik ist subjektiv. und alles subjektive kann kein technischer grund sein. bestes beispiel hier waere python. manche lieben die syntax andere hassen sie. ergo: aesthetik ist subjektiv.

Das ist weder ein Argument für noch gegen 'and', aber es ist ein Argument. Du hingegen argumentierst nicht sondern stellst nur lustig Behauptungen auf („wurde als schlecht befunden“).

Mach die Augen auf, schau dich um. Wer verwendet die iso646 Bezeichner? Sutter, Meyers, Alexandrescu, Coplien,...? Nein, niemand. Ich kenne genau eine Person die das tut: dich.

Auch Microsoft sieht es genau wie ich, das hat dir der support ja gesagt.

Wer ist „man“? Du? Vielleicht? Andere? Wohl eher nicht.

Ich habe schon einen riesen haufen C++, C, PHP,... Code gelesen und nirgendwo wurde das verwendet. In PHP gibt es nur eine situation wo manchmal or verwendet wird:

$c = connect() or die();

Aber es geht sogar noch einen Schritt weiter: diese iso646 Bezeichner werden so selten verwendet, dass in den ganzen Codingguidelines es ist einmal erwaehnt wird dass man sie nicht verwenden soll.

Nein, wieso sollten sie? Die Sprachen sind ja auch ansonsten in Punkto Lesbarkeit ein einziges Fehldesign. Und sowohl Gosling als auch Hejlsberg scheinen sowieso einige sehr kranke Ansichten zur Programmierung zu vertreten. Die beiden als Autorität auf diesem Gebiet anzusehen habe ich schon lange aufgegeben.

Muss man dann eigentlich noch weiter Diskutieren? Du stehst komplett alleine da mit deiner Meinung und zwar komplett. Ich kenne niemanden der auch nur aehnlich denkt.

Vielleicht hast du natuerlich recht und alle anderen unrecht - das kann ich nicht beurteilen...

In jedem Fall wäre diese Argumentation aber idiotisch, da es genug andere Sprachen gibt, die nach C und C++ herausgekommen sind und die 'and' und 'or' unterstützen (und teilweise erheblich von der C-Syntax beeinflusst wurden).

Das ist leider voellig uninteressant: denn es ging darum ob and besser ist als && und die welt hat sich entschieden und nein gesagt. ist schwer zu aktzeptieren, ich weiss...

Oder eben genau andersherum, wie von mir argumentiert.

Ich kapiere allgemein nicht, wieso Du so krampfhaft versuchst, iso646 zu einem Sprachfeature zweiter Klasse zu degradieren. Ich muss überlesen haben, dass im Standard Wertigkeiten vergeben wurden. Oder Du interpretierst da einfach Deine persönlichen Wertigkeiten hinein. Von „ich mag 'and' nicht“ zu „'and' wurde für schlecht befunden“ ist es ein weiter Schritt.

Schau, das ist kindergarten. Ich habe nichts wertendes gesagt darueber was besser ist. Ich bin kein &&-fanboi oder sonstwas. Ich habe dir lediglich gesagt wie es in der grossen weiten welt aussieht. Aber wenn du Microsoft nicht glaubst glaubst du mir ja erst recht nicht.

uebrigens erkennt man wie wackelig du stehst daran, dass du das entscheidende argument komplett ignorierst: jeder kann hier heute und jetzt and statt && verwenden aber es macht niemand. es wird nichtmal darueber diskutiert ob man es machen sollte. es geht sogar soweit dass es nichtmal ein gewuenschtes feature ist dass compiler das unterstuetzen.

das ist sind alles fakten aus der weiten welt. da kannst du aggressiv werden soviel du willst, denn fakten kannst du anschreien solange du lust hast, sie werden sich nicht aendern.

das ist jetzt auch mein letzter post in dem thread, ich hoffe fuer dich dass du wenn du mal ruhiger bist es dir nochmal durch den kopf gehen laesst und einsiehst dass ich nichts bewertendes gesagt habe sondern nur fakten aufgezaehlt habe.

ps:
was die lesbarkeit einer sprache betrifft ist and <-> && total unbedeutend.

[übrigens]

Konrad Rudolph schrieb:

übrigens schrieb:

Konrad Rudolph schrieb:

Du musst als Aufrufer ja auch auf den Fehler reagieren. Ein einfaches if (retval != SUCCESS) return FAILURE; wird da wohl kaum ausreichen. Stattdessen muss sich der Aufrufer Gedanken darum machen, wie er den Rückgabewert behandelt, *welcher* Fehler aufgetreten ist und ob der Fehler an dieser Stelle behoben/ignoriert werden kann.

Wenn du um jeden Methodenaufruf ein try catch(...) machst, dann könnte es wirklich das selbe sein, aber dann hast du mit den Exceptions nicht viel mehr gewonnen als mit Returncodes.

Ich schrieb doch gar nicht, dass man das „um jeden Methodenaufruf“ machen muss, aber *irgendwo* muss man es machen. Sonst bräuchte man ja auch bei Ausnahmen keine Ausnahmebehandlung zu schreiben, und genau das wird hier ja behauptet.

Given that Google's existing code is not exception-tolerant, the costs of using exceptions are somewhat greater than the costs in in a new project. The conversion process would be slow and error-prone.

Und da kannst du doch nicht behaupten, dass das dasselbe ist.

Für solche Fälle eignet sich ein Proxy, sagte ich doch bereits.

Und was macht der Proxy anders als ein try catch(...) um jeden Methodenaufruf?

[Konrad Rudolph]

Shade Of Mine schrieb:

Konrad Rudolph schrieb:

Moment mal. Den hast ja nun aber wirklich Du angefangen.

Ich habe dir lediglich die Wahrheit gesagt. Wenn dich das beleidigt, ist das nicht mein Problem.

Toni, bitte schau Dir Deinen ersten Kommentar auf meine Aussage nochmal an. Der klingt wirklich einfach nur kindisch (damit meine ich weniger das explizite „Ätsch“ als vielmehr die komische Unterstellung, ich würde Sprachmittel „falsch“ benutzen).

bestes beispiel hier waere python. manche lieben die syntax andere hassen sie. ergo: aesthetik ist subjektiv.

Wo ist da eine Argumentation? Das ist ein Problem bei Deinem gesamten Text: es fehlt einfach eine Argumentation.

Das ist weder ein Argument für noch gegen 'and', aber es ist ein Argument. Du hingegen argumentierst nicht sondern stellst nur lustig Behauptungen auf („wurde als schlecht befunden“).

Mach die Augen auf, schau dich um. Wer verwendet die iso646 Bezeichner? Sutter, Meyers, Alexandrescu, Coplien,...? Nein, niemand. Ich kenne genau eine Person die das tut: dich.

Ich kenne mehrere, aber das ist irrelevant. Dein argumentum ad verecundiam ist eine klassische Argumentationsschwäche, und die durchzieht Deinen gesamten Text. Und genau *das* ist Kindergarten. Ich versuche hier von Anfang an, eine Argumentation aufzubauen, Du hingegen zappelst einfach nur mit Deinen Armen.

Nein, wieso sollten sie? Die Sprachen sind ja auch ansonsten in Punkto Lesbarkeit ein einziges Fehldesign. Und sowohl Gosling als auch Hejlsberg scheinen sowieso einige sehr kranke Ansichten zur Programmierung zu vertreten. Die beiden als Autorität auf diesem Gebiet anzusehen habe ich schon lange aufgegeben.

Muss man dann eigentlich noch weiter Diskutieren? Du stehst komplett alleine da mit deiner Meinung und zwar komplett. Ich kenne niemanden der auch nur aehnlich denkt.

Dann kennst Du eben nur einen sehr eingeschränkten Personenkreis. Dass ich mit dieser Meinung alleine stehen soll ist patenter Quatsch.

Vielleicht hast du natuerlich recht und alle anderen unrecht - das kann ich nicht beurteilen...

Es geht hier auch gar nicht um Recht oder Unrecht, sondern um eine saubere Argumentation. Immer noch.

uebrigens erkennt man wie wackelig du stehst daran, dass du das entscheidende argument komplett ignorierst: jeder kann hier heute und jetzt and statt && verwenden aber es macht niemand.

Lies doch mal, was ich schreibe. Ich habe das nicht ignoriert, sondern ich habe diese Argumentation bereits in meinem ersten Posting (bei Microsoft Connect) angesprochen und widerlegt.

das ist jetzt auch mein letzter post in dem thread, ich hoffe fuer dich dass du wenn du mal ruhiger bist es dir nochmal durch den kopf gehen laesst und einsiehst dass ich nichts bewertendes gesagt habe sondern nur fakten aufgezaehlt habe.

Sorry Tony, ich schätze Dich als C++-Mensch, aber mit Dir zu argumentieren ist wirklich unmöglich. Und das, was Du an „Fakten“ nennst, hat entweder nichts mit dem Thema zu tun oder ist eine Anekdote aus Deinem persönlichen Leben, die Du zu verallgemeinern versuchst.

Vielleicht nochmal ganz zum Schluss: Wenn ich Code für ein anderes Projekt schreibe, dann bin ich natürlich konsistent. Wenn andere Dort '&&' verwenden, dann tue ich das auch; alles andere wäre wirklich doof und ich glaube, darum gibt es auch gar keine Debatte. Aber das hat nichts mit dem Thema zu tun.

[Konrad Rudolph]

übrigens schrieb:

Konrad Rudolph schrieb:

übrigens schrieb:

Given that Google's existing code is not exception-tolerant, the costs of using exceptions are somewhat greater than the costs in in a new project. The conversion process would be slow and error-prone.

Und da kannst du doch nicht behaupten, dass das dasselbe ist.

Für solche Fälle eignet sich ein Proxy, sagte ich doch bereits.

Und was macht der Proxy anders als ein try catch(...) um jeden Methodenaufruf?

Nichts. Na und? Dieser Proxy wird ja nur für Googles veralteten Code verwendet. Aber die Bibliotheken werden ja auch noch anderswo eingesetzt, und dort braucht man dann keinen Proxy und könnte eine vernünftige Ausnahmebehandlung verwenden, wenn die Coding Guidelines dies nicht verhindern würden.

[hustbaer]

übrigens schrieb:

wenn man sich das mal durchliest, warum google keine Exceptions nimmt, dann ist ziemlich klar warum sie das machen, aber ich denke das hat keiner gemacht, der sich darüber aufregt.

Die Gründe sind eigentlich alle FUD.

[i_like_it]

Konrad Rudolph schrieb:

übrigens schrieb:

wenn man sich das mal durchliest, warum google keine Exceptions nimmt, dann ist ziemlich klar warum sie das machen, aber ich denke das hat keiner gemacht, der sich darüber aufregt.

Nicht wirklich. Der Grund klingt erst mal gut, ist aber eigentlich Quatsch. Es stimmt zwar, dass es enorm viel Aufwand bedeutet, wenn man ein 'throw' in existierenden Code einfügt, weil tatsächlich alle aufrufenden Funktionen aktualisiert werden müssen.

Dasselbe ist aber der Fall, wenn man einen anderen Fehler-Mechanismus statt Ausnahmen verwendet. Das Problem wir dadurch dann sogar eher noch schwerer. Das Argument ist also gut, nur bezieht es sich auf eine ganz andere Behauptung, nämlich nicht „don't use exceptions“ sondern „don't modify existing code, if at all possible.“

Wenn Google ihren OpenSource-Code auch in internen, Ausnahme-freien Projekten verwenden wollen, müssen sie eben einen Wrapper bauen. Das ist übliche Praxis und ich weiß nicht, wieso hier dagegen argumentiert wird.

Returncodes kann man ignorieren, Exceptions nicht ...

[sothis_]

i_like_it schrieb:

Returncodes kann man ignorieren, Exceptions nicht ...

und wie man das kann

[asc]

sothis_ schrieb:

i_like_it schrieb:

Returncodes kann man ignorieren, Exceptions nicht ...

und wie man das kann

Spätestens beim ersten Aufruf bemerkt man es, ignorierte Returncodes findet man in der Regel wesentlich schwerer...

[i_like_it]

sothis_ schrieb:

i_like_it schrieb:

Returncodes kann man ignorieren, Exceptions nicht ...

und wie man das kann

klar kann man es, aber man muss zumindestens ein try{}catch(...){;} drum machen, bei Returncodes brauchst du gar nichts machen ... dahingehend war ignorieren gemeint, klar ist dass ich nicht auf Exceptions reagieren brauch und sie in einem leeren catch-Block fangen kann.

[i_like_it]

i_like_it schrieb:

sothis_ schrieb:

i_like_it schrieb:

Returncodes kann man ignorieren, Exceptions nicht ...

und wie man das kann

klar kann man es, aber man muss zumindestens ein try{}catch(...){;} drum machen, bei Returncodes brauchst du gar nichts machen ... dahingehend war ignorieren gemeint, klar ist dass ich nicht auf Exceptions reagieren brauch und sie in einem leeren catch-Block fangen kann.

arg, zu schnell abgesendet

Ja ich weiss man muss nicht einmal try-catch aussen drum machen, solange kein Fehler / Exception auftritt passiert auch nichts, aber wenn eine Exception auftritt gibt es wenigstens ein terminate(), bei Errorcodes läuft das Programm weiter...

[sothis_]

das ist alles richtig, aber man kann es

[Strolch]

sothis_ schrieb:

das ist alles richtig, aber man kann es

Du wiederholst dich.

[sothis_]

Strolch schrieb:

sothis_ schrieb:

das ist alles richtig, aber man kann es

Du wiederholst dich.

wie meinen?

[Dravere]

i_like_it schrieb:

..., bei Errorcodes läuft das Programm weiter...

Und das empfindest du als sinnvoll? Es tritt ein Fehler auf, vielleicht fataler Fehler und das Programm läuft dann unkontrolliert weiter? Im Extremfall formatiert es halt die Festplatte, aber immerhin, das Programm ist weitergelaufen.

Bei einem unbehandelten Fehler, sollte das Programm sofort zum halten gezwungen werden, das ist das einzig richtige. Wenn es weiterlaufen würde, könnt es Schaden verursachen. Deshalb sind die Exceptions auch so gut, weil sie genau dieses Verhalten hervorrufen.

Desweiteren ist es praktisch bei den Exceptions, dass der Fehler extrem leicht auf einer anderen Ebene behandelt werden kann. Das geht mit Returncodes nur sehr mühsam oder es erfordert Anpassungen der eigenen Funktion, an denen der API.

Grüssli

[i_like_it]

Dravere schrieb:

i_like_it schrieb:

..., bei Errorcodes läuft das Programm weiter...

Und das empfindest du als sinnvoll? Es tritt ein Fehler auf, vielleicht fataler Fehler und das Programm läuft dann unkontrolliert weiter? Im Extremfall formatiert es halt die Festplatte, aber immerhin, das Programm ist weitergelaufen.

Bei einem unbehandelten Fehler, sollte das Programm sofort zum halten gezwungen werden, das ist das einzig richtige. Wenn es weiterlaufen würde, könnt es Schaden verursachen. Deshalb sind die Exceptions auch so gut, weil sie genau dieses Verhalten hervorrufen.

Desweiteren ist es praktisch bei den Exceptions, dass der Fehler extrem leicht auf einer anderen Ebene behandelt werden kann. Das geht mit Returncodes nur sehr mühsam oder es erfordert Anpassungen der eigenen Funktion, an denen der API.

Grüssli

das habe ich nicht behauptet ich bevorzuge selbst Exceptions, statt diesem krampfhaften

rv = irgendEineFunktion();
if(rv != RV_OK){...}

siehe auch:

i_like_it schrieb:

Returncodes kann man ignorieren, Exceptions nicht ...