The Daily WTF

Power Off

SideWinder schrieb:

Dann wäre der Siegeszug von .NET wenigstens gewiss. Wieso soll ich etwas explizit hinschreiben wenn es implizit sowieso klar ist

Eben weil es bei C zu Missverstaendnissen kommen kann. Ein C++ oder Java Programmierer bekommt die Aufgabe, eine C-Library zu entwickeln (z.B. fuer JNI usw.) und wundert sich ueber die Ergebnisse. Ausserdem werden in einigen Umgebungen immer noch K&R-C-Compiler verwendet.

Das Normungskommitte hat fuer 2003er ISO C++ Standard die Abkehr vom C89 Standard beschlossen, und erfordert jetzt, dass C++ Programme mindestens dem C90 Standard folgen (siehe z.B. Annex C.2).

Power Off schrieb:

Das Normungskommitte hat fuer 2003er ISO C++ Standard die Abkehr vom C89 Standard beschlossen, und erfordert jetzt, dass C++ Programme mindestens dem C90 Standard folgen (siehe z.B. Annex C.2).

ISO C++ von 2003? C90?

Walli

Power Off schrieb:

Seit es erlaubt ist, schreibe ich immer "void" fuer leere Parameterlisten in C++. Das sagt ganz klar: Keine Parameter.

Sicher, und das ist auch viel einfacher als es gleich wegzulassen.

volkard

Power Off schrieb:

Ausserdem werden in einigen Umgebungen immer noch K&R-C-Compiler verwendet.

das argument zieht nicht. du müßtest auch templates meiden, weil es in c keine gibt.

Power Off

Walli schrieb:

Sicher, und das ist auch viel einfacher als es gleich wegzulassen.

Fuer mich (und fuer andere sicher auch) ist es eine Verbesserung der Lesbarkeit. *schulterzuck*

Power Off schrieb:

Walli schrieb:

Sicher, und das ist auch viel einfacher als es gleich wegzulassen.

Fuer mich (und fuer andere sicher auch) ist es eine Verbesserung der Lesbarkeit. *schulterzuck*

ja ne is klar...

SideWinder

Power Off schrieb:

Walli schrieb:

Sicher, und das ist auch viel einfacher als es gleich wegzulassen.

Fuer mich (und fuer andere sicher auch) ist es eine Verbesserung der Lesbarkeit. *schulterzuck*

Ist für dich auch BEGIN/END lesbarer als {, }? Eventuell wechselst du besser zu Pascal

MfG SideWinder

Power Off

SideWinder schrieb:

Ist für dich auch BEGIN/END lesbarer als {, }? Eventuell wechselst du besser zu Pascal

Pascal kann ich auch, aber das war kein Grund fuer mich,

#define BEGIN {
#define END }

in jedes Programm zu schreiben!

SideWinder

Wäre aber wesentlich einfacher zu lesen. Ganz bestimmt

MfG SideWinder

DEvent

ohman ihr habt problem. Steitet euch um solche Kleinigkeiten, wohl nichts besseres zu tun ?

Kann doch jeder schreiben wie er will, ob mit oder ohne void.

groovemaster

volkard schrieb:

Power Off schrieb:

Das nennt sich: Gekennzeichneter Boolescher Ausdruck.

das nennt sich Gekennzeichneter Müll.

ROFLMAO

Power Off schrieb:

Umgekehrt ist's viel schlimmer: Ein C++ Programmierer meint, C zu koennen, weil er ja C++ kann, und schreibt dann sowas

Keiner hat behauptet, dass C und C++ die gleiche Sprache ist. Wann lernen die Leute endlich mal, beide Sprachen strikter zu trennen.

Power Off schrieb:

Guck doch selber, hier ein paar Stichworte: AT&T 2.0 Standard, AT&T 3.0 Standard, CFront, alles prae-ANSI/ISO C++.

LOL. Bitte nur aktuelle ISO C++ Quellen.

Mir ist es übrgens egal, ob jemand 'foo()' oder 'foo(void)' schreibt. Da aber beides identisch ist, sehe ich nicht ein, warum ich mir mit Fall 2 zusätzlich Arbeit machen soll. Zudem finde ich, dass Fall 1 lesbarer ist. Tja, so verschieden sind halt die Geschmäcker...

Wegen dem "? true : false" nochmal...
Ich hab Power Off bei The Daily WTF gesehen.
http://www.thedailywtf.com/forums/45596/ShowPost.aspx

And speaking of pointless code, John pulled this line of triply-redundant code from a Java production system that could be fairly easily simplified to ";".
isActive = (isActive == true) ? true : false;

Für mehr lesbaren Code und so.

Er hat sich schon auf Seite 4 dazu geäußert.

Sgt. Nukem

Hier kommen noch'n paar gute:

Then of course there's Jared M who was surprised to see how his former coworker (with "over 15 years experience in the industry") negated numbers ...
if (trx.Amount < 0)
    trx.Amount = Math.Abs(trx.Amount);
else
    trx.Amount = Convert.ToDouble("-" + trx.Amount.ToString());

It seems everyone has their own way of finding a way to avoid multiplying numbers by -1. Shaun Katona's colleague demonstrates another YAWN (Yet Another Way to Negate) ...
int makeNegative( int n )
{
  int num;
  num = n - ( 2 * n );
  return num;
}

Response.Write LCase("SUBMIT ORDER")

IF (current_num - prev_num = current_num) THEN

Sovok

Sgt. Nukem schrieb:

It seems everyone has their own way of finding a way to avoid multiplying numbers by -1. Shaun Katona's colleague demonstrates another YAWN (Yet Another Way to Negate) ...
int makeNegative( int n )
{
  int num;
  num = n - ( 2 * n );
  return num;
}

öhm mit -1 multipliziern?
was hat er denn gegen

int makeNegative( int n )
{
  return -n;
}

SideWinder

*plonk* *schild an sovok überreich*

MfG SideWinder

imhotep

Sovok schrieb:

int makeNegative( int n )
{
  return -n;
}

Ein schönes Beispiel für übermässiges Refactoring.

Um richtig zu machen müsste man noch auf 0 testen

int makeNegative( int n )
{
  int num = 0;
  if (n<0) num = abs(n);
  else {
    if (n>0) num = ( 0 - 1 ) * abs(n);
    else {
      if (n == 0) num = 0;
    }
  }
  return num;
}

JBeni

IF (current_num - prev_num = current_num) THEN

Was soll daran schlecht sein? Wenn es um floats geht, ist das eine nette Methode rauszufinden, ob "prev_num" im Vergleich zu "current_num" nicht etwas gar klein ist

DEvent

JBeni schrieb:

IF (current_num - prev_num = current_num) THEN
Was soll daran schlecht sein? Wenn es um floats geht, ist das eine nette Methode rauszufinden, ob "prev_num" im Vergleich zu "current_num" nicht etwas gar klein ist

irre ich mich oder kann man den code ersetzen durch

if ( prev_num == 0 ) ...

groovemaster

JBeni schrieb:

Was soll daran schlecht sein?

Weil man dann gleich prüfen kann, ob prev_num gleich 0 ist.

JBeni schrieb:

Wenn es um floats geht, ist das eine nette Methode rauszufinden, ob "prev_num" im Vergleich zu "current_num" nicht etwas gar klein ist

Wenn du damit die Genauigkeit von Gleitkommazahlen meinst, dann macht man das aber anders und nicht mit Vergleich auf Gleichheit.