// Is there a selected item?
if (!string.IsNullOrEmpty(item))
{
// Show the edit elements
ccEdit.Visibility = Visibility.Visible;
}
else
{
// Hide the edit elements
ccEdit.Visibility = Visibility.Collapsed;
}
Je nachdem um was für eine Methode (evtl. EventHandler Methode) handelt, ist das sogar wirklich Sinnvoll. - Beispiel:
Ist in einem Buttn ClickHandler, der Button soll dafür sorgen, dass die Elemente angezeigt werden. Ist nichts in der Liste ausgewählt und es wird etwas angezeigt muss das Zwangsläufig ausgeblendet werden. - Und umgekehrt.
Wissen ist nicht alles. Man muss es auch anwenden können.
Moderationshinweis von herbivore
(23.07.2010 - 15:28)
Vor lauter Kommentaren zu den eigentlichen Coding Styles Horrors sieht man dieselben kaum noch. Das Thema des Threads ist auch nicht, zu jedem Horror eine bessere Lösung zu finden (das ist ohne Weiteres immer möglich, sonst wäre es ja kein Horror), sondern einfach die Leser an besonderes grausamen Konstruktionen teilhaben zu lassen. Bitte lasst daher den Horror unkommentiert.
Wenn man ein Spezifizierten ctor UND einen leeren anbieten will muss man den leeren auch angeben da durch den Spezifizierten der Default ctor überschrieben wird.
Also der //Constructor Kommentar ist wirklich Horror, ein //Nothing allerdings lesbarer als {} oder {;}. Allerdings spricht auch nix gegen // Explicit default constructor :)
Dieser Beitrag wurde 3 mal editiert, zum letzten Mal von fielding am .
Ich find beides keinen Horror... Lieber schreib ich da Constructor hin, als dass einer kommt der keine Ahnung von C# hat und meint "Unnötige Methode weg damit".
Wissen ist nicht alles. Man muss es auch anwenden können.
Moderationshinweis von herbivore
(02.08.2010 - 08:46)
Ich muss mich leider nochmal wiederholen und um Beachtung bitten: Vor lauter Kommentaren zu den eigentlichen Coding Styles Horrors sieht man dieselben kaum noch. Das Thema des Threads ist auch nicht, zu jedem Horror eine bessere Lösung zu finden (das ist ohne Weiteres immer möglich) oder ellenlang darüber zu diskutieren, welchen Horrorgrad der Code auf einer Skala von 0 bis 100 hat, sondern einfach andere besonderes grausamen Konstruktionen teilhaben zu lassen.
var res = (from b in begrgr
where
(from bb1 in begrgbez
where
!
(from bb2 in begrgbez
select new
{
bb2.Id_BegrGr2
}).Contains(new BegrGBez { Id_BegrGr1 = bb1.Id_BegrGr1 })
group bb1 by new
{
bb1.Id_BegrGr1
} into g
select new
{
Id_BegrGr1 = (System.Int16?)g.Key.Id_BegrGr1
}).Contains(new { b.Id_BegrGr })
select new
{
b.Id_BegrGr
}).Count();
Trotz dieses Code wurde die FooException nicht geworfen was einfach daran lag, dass XYZ nen recht komplexes Property ist welches beim null setzen bestimmte Aktionen ausführt und wirklich nur im Fehlerfall null im get zurückgibt. Hier wollte jemand wohl auf eine, als solche erkennbare, Funktion verzichten und hat ein Property dazu benutzt - set als Übergabeparameter und get als Rückgabewert ;)
Moderationshinweis von herbivore
(17.09.2010 - 09:35)
Beitrag hier eingefügt
Ich bin zufällig grad über folgende Seite gestolpert: Beste Kommentare
Evtl sind euch ja auch schon solche Perlen untergekommen.
Da sind schon einige Klassiker dabei:
Exception up = new Exception("Something is really wrong.");
throw up; //ha ha
/* This is O(scary), but seems quick enough in practice. */
#define TRUE FALSE //Happy debugging suckers
// I don't know why I need this, but it stops the people being upside-down
x = -x;
ICantBelieveImUsingAGoto:
// If you're reading this, that means you have been put in charge of my previous project.
// I am so, so sorry for you. God speed.
Wie habe ich erst letztens in einem Buch gelesen: Code soll für Veränderungen geschlossen, aber für Erweiterungen offen sein.
Wer weiss, vielleicht wollte der Entwickler sich ja kreativen Freiraum lassen für Enum.Maybe, Enum.Perhaps, Enum.DoNotKnowYet oder Enum.DoesNotMatter ;-)
See ya,
Michael
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von m.knigge am .
Debuggers don't remove Bugs, they only show them in Slow-Motion.
Wer weiss, vielleicht wollte der Entwickler sich ja kreativen Freiraum lassen für Enum.Maybe, Enum.Perhaps, Enum.DoNotKnowYet oder Enum.DoesNotMatter ;-)
Dann müsste er aber auch jedes Mal das YesNoEnum mit umbenennen. In YesNoMaybeEnum, YesNoMaybePerhapsEnum usw.
[/offtopic]