Ich bevorzuge es, mich jeweils an die Konvention der Standardbibliothek der entsprechenden Sprache zu halten. Grade bei Java gibt es von Sun einen sehr ausführlichen Style Guide.
...
Ja. Allein schon, weil einige Sachen auch nicht gut übertragbar sind. Nehmen wir mal als Extrembeispiel Objective-C: Da hat man Aufrufe, die in etwa so aussehen:
Das ist sehr deskriptiv, aber nur deshalb lesbar, weil a) Name und Variablen vermengt sind und b) XCode in der Lage ist, das automatisch sinnvoll einzurücken. Daß man mehrere Zeilen für einen Aufruf hat, ist bei längeren Aufrufen absolut nicht ungewöhnlich.
Aber was, wenn wir solche Namen in C++ benutzen wollen?
Funktioniert gar nicht. Wir haben zwar drin, was die Variablen bedeuten, aber der Funktionsaufruf ist enorm lang und man müßte ohnehin abzählen, welches Wort zu welcher Variable gehört. Das sollte uns doch eher die IDE erklären und nicht der Variablenname. Für sowas gibt es Doxygen und Konsorten und jede IDE, die den Namen verdient, wird einem genau sagen können, welche Variable was ist.
Ich muß aber zugeben, daß ich mich bei einer Sprache absolut nicht daran halte, wie die Funktionen standardmäßig heißen: PHP. In PHP ist camelCase typisch für objektorientierten PHP-Code, während Unterstriche in der Regel in prozeduralen Funktionen zu finden sind. Da ich aber meine Codebase konsistent formatiert haben will, nehme ich überall camelCase.
Zitat von niR-kun
Das ist ja genau das Problem. Es wirkt für mich mit der Unterstrich-Konvention uneinheitlich und ist für mich schwer lesbar, weil ich mich an die unter Java typischen Namens-Konvention halte.
Aber auf Hinblick das nicht nur TWS und ich den Code lesen werden sondern auch andere.
...
"Einheitlich" bedeutet nicht, daß der Stil gleichförmig aussieht; es bedeutet, daß die Codebase einheitlich ist. Eine Variable sollte in Quelldatei A den selben Formatierungsregeln folgen wie in Quelldatei B und C. Denn man WIRD früher oder später mit jemand anderes Code arbeiten müssen und dann ist es einfacher, wenn man sich nicht erst in die Konvention einarbeiten muß.
Solchen Spaß habe ich auf der Arbeit. Ein von meinem Vorgänger geschriebenes Modul hat Datenklassen, die zusammen mit den Werten noch Metadaten für den (schlechten) Formulargenerator mitbringen. Das macht das Befüllen umständlich:
Wenn ich jetzt also mit Daten aus seinem System arbeite, muß ich daran denken, daß a) camelCase herrscht, aber Unterwerte von Objekten mit PascalCase geschrieben werden und b) Werte Objekte sind, die eine Variable für den eigentlichen Wert beinhalte. Freude.
(Ja, ich weiß, das könnte man mit magischen Gettern und Settern lösen, aber meine erste Handlung als Entwickler war, den Code meines Vorgängers komplett zu deprecaten. Irgendwann wird der ganze Ramsch komplett ersetzt und bis dahin halte ich mich mit strukturellen Änderungen zurück.)
Immerhin nicht Dart. Da ist 1 == false. In der aktuellen Version von Dart ist alles false bis auf das Boole'sche true.
Wenigstens ist ein Bug dazu offen; in Zukunft soll wohl alles true sein, das nicht null oder das Boole'sche false ist. Natürlich bedeutet das dann 0 == true.
Der Artikel ist ziemlicher Blödsinn. Diese Limits gibt es jetzt schon, zumindest für die API ohne Mapanzeige, also zum Beispiel für Koordinaten-Lookups. Bei dem Limit für die Maps gehe ich auch mal davon aus, dass das pro User und nicht pro Website ist. So gesehen ändert sich nicht viel. Bisher war es eben so, dass die Anfragen dann abgelehnt wurden, jetzt hat man die Möglichkeit, gegen Geld mehr zu bekommen.
Eigentlich hätt ich ja geglaubt, dass die shared_ptr eine syntaktisch hässliche aber trotzdem bessere alternative zu normalen pointern sind. Wegen so sachen wie enable_shared_from_this und anderem zeug wächst allerdings grad wieder mein wunsch, dass c++ doch endlich sterben möge.
Eigentlich hätt ich ja geglaubt, dass die shared_ptr eine syntaktisch hässliche aber trotzdem bessere alternative zu normalen pointern sind. Wegen so sachen wie enable_shared_from_this und anderem zeug wächst allerdings grad wieder mein wunsch, dass c++ doch endlich sterben möge.
...
Wir haben neulich in IRC eine Ansammlung von den schrecklichsten Jobs erstellt. Cobol-to-java hat gewonnen.
--
"When I was in college, there were certain words you couldn't say in front of a girl," "Now you can say them, but you can't say 'girl." - Tom Lehrer
Wir haben neulich in IRC eine Ansammlung von den schrecklichsten Jobs erstellt. Cobol-to-java hat gewonnen.
...
Ein bisschen Respekt, bitte! Cobol to Java Programmierer sind ein wichtiger Teil der Gesellschaft.
Fehln nur noch Leute die C und C++ durch was besseres ablösen. Javascript oder so.
Ein bisschen Respekt, bitte! Cobol to Java Programmierer sind ein wichtiger Teil der Gesellschaft.
Fehln nur noch Leute die C und C++ durch was besseres ablösen. Javascript oder so.
...
Fehlt nur noch etwas Besseres, als C und C++. Ich suche schon seit Jahren etwas besseres, mit Gesellschaftscharakter.
--
"When I was in college, there were certain words you couldn't say in front of a girl," "Now you can say them, but you can't say 'girl." - Tom Lehrer
ok, das ist echt schon nett O_o
Aber einen XML-Parser kann einen manchmal echt zur Weißglut bringen. Neulich hatte ich nen RSS Feed-Parser unter Java gebastelt.
Es ist nervig, dass hier die Daten nicht Elementar sind. Der <author>-Tag besitzt sowohl die E-Mail Adresse, als auch den Namen des Verfassers. Konnte man da nicht einfach zwei Tags draus machen? Stattdessen wird hier der <creator>-Tag aus dem "Dublin Core Metadata Element Set" verwendet, welcher noch eingebunden werden muss ...
Aus diesem Grund habe ich der Webentwicklung so weit es geht den Rücken zugekehrt. Ständig stößt man dort nur auf irgendwelche Flickenteppiche, die dann gesondert behandelt werden müssen.
Bill Gates ist der Teufel, denn korrekt heißt er William Henry Gates III. Wandelt man die Buchstaben seines Namens in ASCII- Werte um, erhält man folgendes: B 66 - I 73 - L 76 - L 76 - G 71 - A 65 - T 84 - E 69 - S 83 + 3 = 666. Die 666 ist die Ziffer und das Zeichen des Teufels.
ok, das ist echt schon nett O_o
Aber einen XML-Parser kann einen manchmal echt zur Weißglut bringen. Neulich hatte ich nen RSS Feed-Parser unter Java gebastelt.
Es ist nervig, dass hier die Daten nicht Elementar sind. Der <author>-Tag besitzt sowohl die E-Mail Adresse, als auch den Namen des Verfassers. Konnte man da nicht einfach zwei Tags draus machen? Stattdessen wird hier der <creator>-Tag aus dem "Dublin Core Metadata Element Set" verwendet, welcher noch eingebunden werden muss ...
Aus diesem Grund habe ich der Webentwicklung so weit es geht den Rücken zugekehrt. Ständig stößt man dort nur auf irgendwelche Flickenteppiche, die dann gesondert behandelt werden müssen.
...
Es hilft, wenn man sich von XML fern hält. Es ist schon erstunlich, wie viel sinnvoller auf einmal alles wird.
Das denke ich auch wobei es sich auch SUPER für Animationen eignet Zumindest kann ich damit viel leichter Animationen laden, Alternative wäre natürlich JSON, aber ich hab nen guten XML-Parser von daher geht das, ich mache ja damit nichts in Echtzeit.
Zum Daten-Austausch bevorzuge ich JSON ...
Es ist selbst in formatierter Form um die Hälfte kleiner als ein XML-Dokument ... und ist vor allem typisiert. Und wie ich finde häufig auch lesbarer als XML.
Ein krasses Beispiel was ich die tage gesehen habe ... SOLR (Eine Java-Web-Anwendung zum füttern eines Lucene Such Indexes):