|
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:
|
|
|
|
|
TLDR. And spiff that up with some PRE code blocks why don't ya.
|
|
|
|
|
I suppose that's why overloads and inheritance come into play since most religions just override and modify the behavior of ones that came before.
I wasn't, now I am, then I won't be anymore.
|
|
|
|
|
Really... A univote for that without any comment. That's just cheesy.
I wasn't, now I am, then I won't be anymore.
|
|
|
|
|
You should add some object-oriented design.
Let us start with a HellType enumeration:
public enum HellType
{
Christian,
Muslim,
Chinese
}
Then we need an interface for the Hell:
public interface IHell
{
HellType HellType { get; }
}
Here, some methods should be declared for taking up, treating and removing sinners.
Perhaps we could also be interested in the Hell Staff (the devil and his helpers), a list of sinners already in hell, etc. Capacity is not a useful property, as it is always infinite.
Now we can come to a more important part: the HellFactory.
public class HellFactory
{
public IHell CreateHell(HellType hellType)
{
}
}
And here, theological problems arise. In all religions, there is only one instance of hell. Hence we must amend the interface with
IHell Instance { get; }
and also change our HellFactory
public IHell GetHell(HellType hellType)
{
}
We could also need a static constructor in some hells, as that hell does simply exist. Things become even worse when the only instance has to be created by the apprpriate god... To hell with such a hell!
|
|
|
|
|
And, as this is the hall of shame,
GOTO HELL;
___________________________________________
.\\axxx
(That's an 'M')
|
|
|
|
|
Do not believe in anything simply because you have heard it. Do not believe in anything simply because it is spoken and rumored by many. Do not believe in anything simply because it is found written in your religious books. Do not believe in anything merely on the authority of your teachers and elders. Do not believe in traditions because they have been handed down for many generations. But after observation and analysis, when you find that anything agrees with reason and is conducive to the good and benefit of one and all, then accept it and live up to it. The Buddha
|
|
|
|
|
On the subject of completelystupid programmers I one came accross this. Someone had told this idiot that literal cnstants (magic numbers) were "a bad thing", so the benighed fool hd produces a file containint the following:
#define ZERO 0
#define ONE 1
#define TWO 2
#define THREE 3
...
#define TEN_THOUSAND 10000
and included it in every source file.
And this is the absolute truth, no kidding.
|
|
|
|
|
While that is a coding horror, I would hate to read your code comments.
Adrian.Tawse wrote: completelystupid
Adrian.Tawse wrote: cnstants
Adrian.Tawse wrote: benighed
Adrian.Tawse wrote: hd
Adrian.Tawse wrote: containint
|
|
|
|
|
Give him a break... His profile says he is in the UK.... 
I wasn't, now I am, then I won't be anymore.
|
|
|
|
|
And after 4 years, that was the first time he's posted, so he's not yet aware of the abuse he'll receive for poor spelling. 
|
|
|
|
|
Mea culpa, mea culpa, mea maxima culpa. I was wearing the wrong glasses.
And now for a new snippet:
A software package was being put together for release and a colleague remarked of one item "Oh God, not that pile of sh*t". I asked why and he said that it corrupted floppies. Now this was before the days when the FAT file system was build into Unix. The utility attempted to write Unix files to a DOS FAT floppy. It did this by opening the device in RAW mode and read and wrote whole sectors, including the FAT table. When transferring text files it would read a sector’s worth of data, scan for \n, shift everything up one, and insert \r. This, of course, would result in buffer overflow. What followed the buffer in memory? You guessed it, the FAT table, which was duly written back to the floppy at the end; it took about ten seconds to notice the problem. I went to the Team Leader to say “You cannot possibly ship this; I can fix it in minutes”. His reply was that they had had a summer student in ad it had taken him all summer to do that, and on no account was I to touch a line; it was to ship exactly as is. “It is OK when used with newly formatted floppies, and the file is not too big” I am not sure who I was more amazed with, the summer student or the Team Leader.
|
|
|
|
|
That is organisationally crap on so many levels. 
Anna ![Rose | [Rose]](https://www.codeproject.com/script/Forums/Images/rose.gif)
Tech Blog | Visual Lint
"Why would anyone prefer to wield a weapon that takes both hands at once, when they could use a lighter (and obviously superior) weapon that allows you to wield multiple ones at a time, and thus supports multi-paradigm carnage?"
|
|
|
|
|
Worse things can be seen:
int ONE_HUNDRED = 100;
ONE_HUNDRED++;
|
|
|
|
|
If it's any consolation, I've seen FORTRAN compilers which which will allow the equivalent of the following:
public void inc(ref int i)
{
i *= 2;
}
...
Console.WriteLine(100);
inc(100);
Console.WriteLine(100);
...And would print:
100
200 And I had to find that in production code...
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
|
|
|
|
|
LOOOOL!! This is me while reading your post:    
Thanks for sharing such a pearl. 
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
