IM IN YR LOOP\n VISIBLE FOO\n IM OUTTA YR LOOP - Der Programmierer-Spamthread #2

Naja, mein Algorithmus ist ja billig eigentlich.

Einfach, weil das Thema hier drüben noch gar nicht angesprochen wurde:

Anhang 10694
Quelle: WillDrawForFood1 - Apple Memorial (deviantART)

Übrigens hat deviantART eine ganze Steve Jobs Tribute Aktion angeleiert, bei der schon einige sehr interessante Bilder entstanden sind.

Hrm, Steve Jobs war schon ein großer Mann. Keine Frage.
Hat zu den damaligen Zeiten die Zeichen der Zeit richtig gedeutet und richtig gehandelt um sich ein riesen Unternehmen zu erschaffen.
Definitiv beeindruckend.

Allerdings ist die Frage seit wann die Welt so Steve Jobs vergöttert? Ich meine, gut möglich das ich es verpasst habe.
Aber ich wüsste nicht das er dafür so viele "Jünger" hatte, die ihn vergöttert haben. Es kommt mir ein wenig so vor, als wäre
momentan der gleiche Effekt wie vorher bei Michael Jackson. Und ob man das so ernst nehmen kann ist eine andere Frage.

Zitat:

---

Zitat von makenshi

Hrm, Steve Jobs war schon ein großer Mann. Keine Frage.
Hat zu den damaligen Zeiten die Zeichen der Zeit richtig gedeutet und richtig gehandelt um sich ein riesen Unternehmen zu erschaffen.
Definitiv beeindruckend.

Allerdings ist die Frage seit wann die Welt so Steve Jobs vergöttert? Ich meine, gut möglich das ich es verpasst habe.
Aber ich wüsste nicht das er dafür so viele "Jünger" hatte, die ihn vergöttert haben. Es kommt mir ein wenig so vor, als wäre
momentan der gleiche Effekt wie vorher bei Michael Jackson. Und ob man das so ernst nehmen kann ist eine andere Frage.

---

Ganz einfach: Jeder Machead hat Respekt vor Steve. Seit ein paar Jahren sind Macs dermaßen erfolgreich, daß es jetzt VIELE Macheads gibt. Folglich ist Steve plötzlich äußerst respektiert.

Dazu kommt, daß auch die Wettbewerber zugeben müssen, daß Apple ein Innovationstreiber ist. Apple hat schon immer nach dem Motto "scheiß auf Abwärtskompatibilität, wir wollen das Beste" gearbeitet, mit dem Ergebnis, daß sie das Wachstum von Dingen wie USB, FireWire oder der graphischen Benutzeroberfläche gefördert haben. Davon, wie Apple mal eben diktiert hat, wie Gadgets heutzutage auszusehen haben muß ich gar nicht erst reden. Einiges davon geht auf Steves Mentalität zurück. (Man bedenke, daß OS X und iOS beide von NeXTStep abstammen, seinem Projekt, nachdem er bei Apple ausgestiegen war. OS X ist im Wesentlichen NeXTStep mit einem an Mac OS Classic angelehnten GUI.)

Und an welche Person denkt man, wenn man an eine Firma denkt? An den CEO. In den 90ern war Bill Gates der große Computerheld, obwohl er sich schon früh eher auf das Geschäftliche konzentriert hatte. Aber er war präsent. Steve Jobs war das Gesicht bei Apple, das uns demonstriert hat, wie cool die neuen Produkte aussehen und was sie auf dem Kasten haben. Sicher, es gab auch ein paar andere wichtige Leute da wie Jonathan Ive, aber Steve ist der, den alle kennen.

Ich hatte gestern mit TWS einen Disput über Variablenbenennung, er bevorzugt es in Java Variablen so zu nennen wie "a_cool_variable", aber Funktionen mit camelCase zu benennen wie "aCoolFunction()". Ich meinte zu ihm, dass es syntakisch viel besser aussehen würde, wenn beides im camelCase-Syntax wäre.

Was ist denn nun mehr verbreitet (oder besser)?

Im Sinne einer Kooperation muss man ja syntaktisch irgendwie übereinkommen.

Ich denke auch nicht, dass das jetzt was mit "Vergötterung" zu tun hat. Ich denke, bei Bill Gates und Linus Torvalds würden die Leute ähnlich reagieren. Die drei sind einfach die großen Gesichter der Branche, ohne die vieles, was wir heute für selbstverständlich halten, nicht in dieser Form existieren würde.

Edit:

Zitat:

---

Zitat von niR-kun

Ich hatte gestern mit TWS einen Disput über Variablenbenennung, er bevorzugt es in Java Variablen so zu nennen wie "a_cool_variable", aber Funktionen mit camelCase zu benennen wie "aCoolFunction()". Ich meinte zu ihm, dass es syntakisch viel besser aussehen würde, wenn beides im camelCase-Syntax wäre.

Was ist denn nun mehr verbreitet (oder besser)?

Im Sinne einer Kooperation muss man ja syntaktisch irgendwie übereinkommen.

---

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.

Ihr solltet euch bei euren Konventionen nicht zu sehr verkrampfen. Wichtig ist nur, dass der Code einheitlich aussieht.

Zitat:

---

Zitat von Kyuu

Ihr solltet euch bei euren Konventionen nicht zu sehr verkrampfen. Wichtig ist nur, dass der Code einheitlich aussieht.

---

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.

Was Kyuu sagt reicht doch schon. Nur weil einer sagt: "Hey, ich brin Prof uns sage euch dass das so am Besten ist!" muss man sich nicht daran halten. Ich kenne auch Leute die fahren eine komplett andere Schiene mit sogenanntem CleanCode bei dem z.B. Methoden endlose Namen haben die genau beschreibt was alles in der Methode passiert und Methoden gleich ganz zerstückelt. Das ist jedem selbst überlassen.
Selbst bei Teamarbeit ist das nicht soooo wichtig, es sei denn man arbeitet zu zweit an einer Klasse. Dann sollte man sich vllt vorher auf einen Mittelweg einigen :)

Zitat:

---

Zitat von DFYX

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:

Code (Obj-C):

 
[GrowlApplicationBridge notifyWithTitle:@"Bei Artikel überboten"
							description:title
					   notificationName:@"Outbid"
							   iconData:nil
							   priority:1
							   isSticky:NO
						   clickContext:articleID];
 

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?

Code (C++):

 
GrowlApplicationBridge.notifyWithTitleDescriptionNameIconPriorityStickyContext("Bei Artikel überboten", title, "Outbid", null, 1, false, articleID);
 

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:

---

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:

Code (PHP):

 
$customer = new Customer();
 
// falsch
$customer->FirstName = "Walter";
 
// so wie der Code vom Vorgänger es macht
$customer->FirstName->Value = "Walter";
 
// so, wie es korrekt wäre
$customer->FirstName = new stdClass();
$customer->FirstName->Value = "Walter";
 
// Es geht auch ohne das explizite Instanzieren von FirstName, aber dann warnt
// PHP, weil ein Objekt implizit erzeugt wurde. Das ist idR. kein Problem, aber
// wir haben einen eigenen Fehlerhandler, der jedes Mal aufgerufen wird. Bei
// 1.500 Warnungen beim Erstellen der Kundenliste macht das ein fieses
// Performanceloch aus.
 

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.)

Ich habe mich etwas mit einem procedural sound generator gespielt.

L: (s=40000-t)*0+(u=t-12000)*0+(t<30000?(s*(s>>10))*sin((s>>9)-s*0.00001)*cos(((Math.round(s)%4444)>>10)+s*0.000001):(t<60000?((Math.round((t+3000)/3000)%2)==0?t*5:t*2):(t<240000?(t<70000?Math.pow(t,t/70000):((t<120000&&Math.round(u/1500)%2==0)?0:u*Math.round(u/1500)*1500)):(t<245000?Math.pow(t,(300000-t)/70000):((t>260000||(Math.round(t/5000)%2==0))?0:t*2))))) | R: (s=30000-t)*0+(u=t-12000)*0+(t<30000?(s*(s>>10))*sin((s>>9)-s*0.00001)*cos(((Math.round(s)%4444)>>10)+s*0.000001):(t<60000?((Math.round((t+3000)/3000)%2)==0?t*4:t*2):(t<240000?(t<70000?Math.pow(t,(200000-t)/110000):((t<120000&&Math.round(u/1500)%2==0)?0:u*Math.round((u+16*1500)/500)*500)):(t<245000?Math.pow(t,(270000-t)/70000):((t>260000||(Math.round(t/5000)%2==0))?0:t*6)))))

Strangest language feature

Zitat:

---

Zitat von Dipstick

In JavaScript:
'5' + 3 gives '53'
Whereas
'5' - 3 gives 2

---

Zitat:

---

JavaScript truth table:

Code:

---

''        ==  '0'          //false
0        ==  ''            //true
0        ==  '0'          //true
false    ==  'false'      //false
false    ==  '0'          //true
false    ==  undefined    //false
false    ==  null          //false
null      ==  undefined    //true
" \t\r\n" ==  0            //true

---

---

Die Beispiele für C und Java sind aber auch nicht schlecht.

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.

Perl:

Zitat:

---

$[ — change your array base from 0-based to 1-based to 42-based: WHEEE!

---

... bitte, nicht wirklich....

Ich kopiere jetzt mal schamlos von fefe:

Zitat:

---

Standard des Tages: Das "Extensible Configuration Checklist Description Format". Ja, Checklisten. As in
[ ] Müll rausgebracht
[ ] Geschirr abgewaschen

---

Man bemerke: das Dokument hat 80 Seiten.

Die Google Maps API wird ab 2012 nicht mehr kostenlos sein.

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.

Zitat:

---

Zitat von nudelsalat

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. :D

Zitat:

---

Zitat von Mog

Wir haben neulich in IRC eine Ansammlung von den schrecklichsten Jobs erstellt. Cobol-to-java hat gewonnen. :D

---

Ein bisschen Respekt, bitte! Cobol to Java Programmierer sind ein wichtiger Teil der Gesellschaft. :O
Fehln nur noch Leute die C und C++ durch was besseres ablösen. Javascript oder so. :D