|
I fail to see the great horror in your code... If you are posting in the Hall of Shame with a code snippet, should there not be at least one subtle horror in there? We are coming here to be amused, not educated...
(Nicely explained, by the way. I actually ran into a few senior developers in my time who did not understand this concept)
I wasn't, now I am, then I won't be anymore.
|
|
|
|
|
Indeed, I'm in a VB shop now and it seems that someone thinks reference types always have be passed byref .
|
|
|
|
|
Ain't that the truth...
Ironically, I have a couple QA's who I'm mentoring in C# for web automation testing that have a better grasp... They have never taken any courses... (They also write better code, but I'll pretend that is because of me)
I wasn't, now I am, then I won't be anymore.
|
|
|
|
|
Let's imagine that string.IsNullOrEmpty does not exist. Let's imagine that extension methods do not exist either. Let's imagine that a method like this might be useful. With all of these premises, I still think that someone should invent a computer which slapped anyone who wrote an "If" statement just to return the result of the condition evaluated by that "If". I have seen it countless times, and I still don't understand how they do not notice it.
|
|
|
|
|
If string.IsNullOrEmpty did not exist, I would create it in my source because it is a heavily used utility function, even if the the method only returns the results of an "if" evaluation.
My reasoning for this is that the usage of stringVariable.IsNullOrEmpty() is very clear as to what is being evaluated while if( stringVariable == null || stringVariable.Length == 0 ) is not as clear.
From a sustainability standpoint I would definitely create it.
As a note, I always add this utility to all solutions that do not have the support natively.
I wasn't, now I am, then I won't be anymore.
|
|
|
|
|
Yes, sure, but what I meant was more about the implementation itself:
public static bool IsNullOrEmpty(string str)
{
return str == null || str == "";
}
No need of an "if" statement since we are actually returning the result of the condition itself. This is what I meant.
|
|
|
|
|
But do you want to write the entire "if" statement in hundreds of places in a large solution, or one that can be issued a test-case for coverage and validation that will then be validated from intellisense. Any equality statement is dangerous in the old "str = null" vs "str == null" world and thus should be encapsulated into a testable case.
I wasn't, now I am, then I won't be anymore.
|
|
|
|
|
Marcus Kramer wrote: But do you want to write the entire "if" statement in hundreds of places in a large solution, or one that can be issued a test-case for coverage and validation that will then be validated from intellisense. Any equality statement is dangerous in the old "str = null" vs "str == null" world and thus should be encapsulated into a testable case.
Uh, what? Are you saying that the if statement should be encapsulated in a method rather than sprinkling the if statement over several places in the code? Erik never said otherwise. He just said that rather than using an if statement, a single return statement can be used (yes, inside a method).
|
|
|
|
|
I stand corrected. I misread that last post from Erik....
I wasn't, now I am, then I won't be anymore.
|
|
|
|
|
|
I can't see the problem...
return lst == null || lst.Count == 0;
Becouse if a class implements IList it must also implement ICollection.
|
|
|
|
|
Yes, but String isn't an IList -- but not to worry, I wrote... I wrote my own String class today.
|
|
|
|
|
Instrument = instrument.Accessor;
Accessor = GetAccessorForInstrument(instrument.Accessor);
Accessor.Instrument = instrument.Accessor;
Has anybody seen a more confusing piece of code???
|
|
|
|
|
Is this in a case sensitive language?
|
|
|
|
|
Yes, it is case-sensitive C#.
I forgot to mention that all "instrument" variables are of various "xxxAccessor" types, and all "accessor" variables are of "xxxInstrument" types, so the code is way way worse than it seems.
I swear, the variables are declared something like this:
aaaAccessor Instrument;
bbbInstrument Accessor;
cccAccessor instrument;
dddInstrument accessor;
Instrument = instrument.Accessor;
Accessor = GetAccessorForInstrument(instrument.Accessor);
Accessor.Instrument = instrument.Accessor;
I won't even mention there are also InstrumentFactory class, and AccessorFactory class, and InstrumentWrapper class, and AccessorWrapper class, and IInstrument interface, and IAccessor interface, and InstrumentHelper, and AccessorHelper, and ...
Do you think that deserves the Guinness book? I mean, this is probably the only program where not the values but THE MEANINGS of variables are being swapped all the time. This is not programming, this is meta-programming.
modified on Wednesday, December 29, 2010 4:31 PM
|
|
|
|
|
it's kind of an obfuscation-tactic!
After at least 10 lines you're totally confused and want to drain yourself in your coffee mug.
regards
Torsten
I never finish anyth...
|
|
|
|
|
Yeah, it is probably about job security. Everybody who has to work with his code will quit, and he will be forever the sole maintainer of that garbage.
What about XAML like this?
<Textbox Text="{Binding xxxViewModel.xxxModel.xxxData.xxxModel.DataContext.xxxUnderlying.xxxModel.xxxViewModel.Model....}" />
Yes, Binding paths with 8 dots and more !!!
modified on Friday, January 7, 2011 1:16 PM
|
|
|
|
|
I think something got lost in translation
|
|
|
|
|
What translation? I have to maintain and fix bugs in his code. It is all like that.
Variables have wrong names, and their meaning changes al the time. Variable named "exchange" may actually mean "exchange_code", "exchange_id", "IExchange", "ExchangeConfig". "string exchange" may be used to keep "exchange_id", "exchange_code", and later on "exchange_name"... "instrument" may be of type "IInstrumentWrapper", "Ric", "Occ", "IDataAccessor", or whatever, and "accessor" means exactly the same...
What about his unique approach to multi-threading?
GUI thread: Click
start background thread
do something
synchronous post to GUI Dispatcher
wait until GUI is done
do something
synchronous post to GUI Dispatcher
wait until GUI is done
do something
synchronous post to GUI Dispatcher
wait until GUI is done
do something
Thread synchronization? Done using bunch of boolean flags, so it is one big race condition waiting to happen.
There is no way to stop any background thread of course, so usually you have to use TaskManager to kill the application after you click "Close". Forget about memory leaks and such.
|
|
|
|
|
<code>
string EnableLogging = string.Empty;
string WSURL = string.Empty;
string TransformXSLPath = string.Empty;
....
try
{
EnableLogging = ConfigurationSettings.AppSettings["EnableLogging"].ToString();
}
catch( Exception ex )
{
EnableLogging = string.Empty;
}
try
{
WSURL = ConfigurationSettings.AppSettings["WSURL"].ToString();
}
catch( Exception ex )
{
WSURL = string.Empty;
}
try
{
TransformXSLPath = ConfigurationSettings.AppSettings["TransformXSLPath"].ToString();
}
catch( Exception ex )
{
TransformXSLPath = string.Empty;
}
....
</code>
like this for all variables that are read from config file.
|
|
|
|
|
Assuming this is C#... exception handling is probably not necessary (though better safe than sorry), ToString is not necessary on something that is already a string, the initial assignments are not necessary if they're going to get assigned in the catches, catching a particular exception is not necessary if the exception variable is not going to be used (there are some nuances to that, but for this example it seems unnecessary), and the repeated functionality is not encapsulated in a function. Maybe this would be more appropriate:
private string GetConfigSetting(string key)
{
string val;
try
{
val = ConfigurationSettings.AppSettings[key];
}
catch
{
val = string.Empty;
}
return val;
}
string EnableLogging = GetConfigSetting("EnableLogging");
string WSURL = GetConfigSetting("WSURL");
string TransformXSLPath = GetConfigSetting("TransformXSLPath");
Does that about do it, or was there something else you noticed that was horrific/shameful?
|
|
|
|
|
Agreed, no need of .ToString() as AppSettings[] will return string only.
But this line
EnableLogging = ConfigurationSettings.AppSettings["EnableLogging"].ToString();
will throw only Objectrefnotset exception since .ToString() is used and if the key is not found in the config file. I dont find a reason for any exception.
This should be the right way
if (ConfigurationSettings.AppSettings["EnableLogging"] != null ) <br />
EnableLogging = ConfigurationSettings.AppSettings["EnableLogging"]
or
EnableLogging = ConfigurationSettings.AppSettings["EnableLogging"] ?? string.Empty;
|
|
|
|
|
Yeah, I can't get it to throw an exception (even when I use an invalid key), though the MSDN documentation says an exception can be thrown. One more thing I noticed is that ConfigurationSettings.AppSettings is deprecated in favor of ConfigurationManager.AppSettings , though it may be fine if the code resides in an older version of the .Net Framework in which that was not yet deprecated.
|
|
|
|
|
I've been thinking lately about religion, it's something I don't understand and unfortunately(it really is unfortunate at some times) "God" gave me a brain to analyse, think and come to my own conclusions, not the ones written in "holy" books which have been edited/rewritten so many times by powerful people throughout history, let's not forget that not so long ago tickets to heaven were being sold(i guess they ran out of space nowadays :P )...
I consider anyone who follows anything blindly to be a fool, we have a brain and we should use it... Just because your parents, priests, friends, news, tv (so on...) say something, it doesn't make it true, they, just as anyone else, are human and can be wrong...
Now that I got that off my chest, I was wondering how hell would look like from a programming perspective.
I Googled hell, and ended up going into wikipedia, from which I quote "Revelation 20:10 (NIV) illustrates Hell as a "lake with burning sulfure" "
From this information, I see that there will be a lot of burning involved, therefore as a good programming habit, I create a method and call it "burn", the method is unclear, should it return anything? does it take any arguments? is it static(as in, a part of hell)? Lets simplify for now and say public void burn()
Now I'm curious about a way out, I read a bit more in wikipedia and found out that in
Christianity, I quote "As opposed to the concept of Purgatory, damnation to Hell is considered final and irreversible". Wow, that must suck!
Islam, I quote "The Qur'an also says that some of those who are damned to hell are not damned forever, but instead for an indefinite period of time" Hehe and all this time I thought that Christiniaty was about forgiveness...
Chinese and Japanese religions, I quote "The Chinese depiction of Hell doesn't necessarily mean a long time suffering for those who enter Hell, nor does it mean that person is bad. The Chinese view Hell as similar to a present day passport or immigration control station. In a Chinese funeral, they burn many Hell Bank Notes for the dead. With this Hell money, the dead person can bribe the ruler of Hell, and spend the rest of the money either in Hell or in Heaven." HAHAHAHAHAHAHAHA i looooooooove this!!!
In short, our main program should be like this,
Christianity, its an infinite loop, there's no way out! therefore:
while(true)
{
burn();
}
Islam, we need to specify a condition, since there "might" be a way out, therefore:
boolean forgiven = false;
while(forgiven == false)
{
suffer(); // wtvr happens in Islamic hells, in heaven they get to screw virgins, therefore i guess it's the opposite here...
begForgivness(); //beg for forgivness
}
In Japanese/Chinese hell, hehe well this one is a bit complex but i'll give it a shot!
double hell_bank_notes = 0; //some people are bastards and burn coins, even though they don't burn, we can't underestimate the chinese!
boolean go_to_hell = true; //we're assuming we're going straight to hell
if(isDead() == true && go_to_hell== true)
{
hell_bank_notes = getPocketMoney(); //hehe lets hope they burn alot of money at your funeral!
while(isBribed() == false && bankrupt() == false)
{
bribe(); //bribe gives a dollar at a time so that we dont get ripped off!
}
if(isBribed() == true)
{
heaven();
}
else //ur passport got rejected lol
{
hell();
}
}
Well thats the end of hell, now that we know how it looks like, we should find a way to hack it and break the system before it's too late :P
I've wasted 30 minutes of my life writing this so plz waste a couple of minutes to comment or else you'll end up burning in helllll buhahahahahaa lol!
|
|
|
|
|
Since there is more than one religion which states that you'll get to hell if you are not member of it, and there is more than one which states that you'll never get out of hell once you have entered it, I guess we can simplify the implementation a lot:
|
|
|
|
|