|
Long ago we did our best to write misleading code with help of the C preprocessor. Then Java came along and they celebrated the end of such malicious practices. C# has a preprocessor (as all directives beginning with '#' clearly show), but it is harder to use in a destructive way. Still, your example shows that it was not the preprocessor that was the root of all evil.
And from the clouds a mighty voice spoke:
"Smile and be happy, for it could come worse!"
And I smiled and was happy
And it came worse.
|
|
|
|
|
That's bad, but it can be worse:
namespace Dummy
{
public struct Int32
{
int val;
private Int32(int v)
{
val = v;
}
public static implicit operator Int32(int x)
{
return new Int32(x - 3);
}
public static implicit operator int(Int32 x)
{
return x.val;
}
public static Int32 operator *(Int32 a, Int32 b)
{
return new Int32(a.val * (b.val + 1));
}
}
}
|
|
|
|
|
+5 - That's just plain awful 
|
|
|
|
|
It isn't, as noted, but it also wouldn't matter if it were. Local variables of reference types also "have to" be initialized. That is, they must satisfy the Definite Assignment rules.
If it were a field in a struct/class or an array-element it wouldn't have to be initialized, but that is the case for any type; they're always set to default(type) in those cases.
|
|
|
|
|
int is a C# alias for the CLR type Int32, both refer to the same (value) type. You're thinking of Java's Integer and friends. And even with a reference class, you can't use a local variable before it's been explicitly assigned.
|
|
|
|
|
b10543748 wrote: a store procedure with +/- 2600 lines.
That's the real horror here. It gives me goose bumps just to think about it.
b10543748 wrote: Int32 contador;
contador = (Int32)0;
I think that deserves the hall of shame, just for the fact that the person that wrote this probably had no idea what he was doing. But, what if, historically this code looked like this:
Int32 contador;
contador = (Int32)3.2;
And then, for whatever reason it was change to 0 and the cast was just kept.
Or even:
long outroContador = paramX * 1000000L;
.
.
.
Int32 contador;
contador = (Int32)outroContador;
So, maybe, just maybe, it was just a matter of safety.
"To alcohol! The cause of, and solution to, all of life's problems" - Homer Simpson
|
|
|
|
|
b10543748 wrote: and a store procedure with +/- 2600 lines.
I assume you are talking SQL. I haven't counted lines, but I've had printouts of over 45 pages. Personally, if your sproc prints out more than 5 pages, you've screwed up the design. At least in an OLTP environment. (I've never said anything like that to my employer, I'll just think it.)
|
|
|
|
|
Our application uses SQL Server 2005 Express for a couple small data bases. I was adding logic to our migration app (moves the product from one machine to another) to backup the data bases. The simplest way to do this was to spawn SQLCMD to execute a backup command:
BACKUP DATABASE CPT TO DISK='C:\...\FILE.BAK' It worked fine at the command line, producing a nice backup file I could then include in the migration data. Spawning SQLCMD from my migration tool was another story however. The command created the backup file, which my app would then get an 'access denied' error. The file exists in the path I specified, and is the right size. Right-click, Properties, select the Security tab, and I get a message that I'm not allowed to view the security properties of the file unless I take ownership of it.
What. The. F***.
As closely as I can tell, when SQLCMD is run from a command window, it tells the SQL service to create the backup file with administrator access. If SQLCMD is run from another process, the SQL service creates the backup file under the account it's running under, usually Network Service. In other words, it creates a file for you that you can't use.
After much cursing, Googling, a brief foray into the MSDN, and stifling the urge to e-mail a pocket nuke to Redmond, I discovered the solution. If you create the backup file yourself (with zero length), SQL Server will go ahead and 'append' to the existing file, leaving the file ownership and security settings alone. Adding two lines of code, a call to CreateFile() and one to CloseHandle() fixed the problem.
What pisses me off about this is that, since they clearly know how to set the file ownership properly when the command is run interactively, why not do it all the time? Isn't is harder to screw this up than it is to do it right? 
Software Zen: delete this;
|
|
|
|
|
You are forgetting something: MS is "customer focussed". As in, MS likes to "foc" it's customers in the "uss" as much as it can...
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
|
|
|
|
|
The least they could do is take me out to dinner and a movie first.
Software Zen: delete this;
|
|
|
|
|
I'd rather not have them "foc" me in the "uss" and they can keep their dinner.
Ego non sum semper iustus tamen Ego sum nunquam nefas!
|
|
|
|
|
I think, there is no need for comment
private static void DoSplash()
{
SplashScreen sp = new SplashScreen();
sp.ShowDialog();
while (true)
{
Thread.Sleep(200);
}
}
|
|
|
|
|
|
|
That will definitely show a splash screen and make sure it stays around long enough for people to see it.  
Just because the code works, it doesn't mean that it is good code.
|
|
|
|
|
Ohhh... but that we don't know. We can't see what the other threads, if any, are doing with windows popping up... 
Time you enjoy wasting is not wasted time - Bertrand Russel
|
|
|
|
|
I hope they implemented a "Please wait" message box when the user is forced to interact with the screen and close it
"You get that on the big jobs."
|
|
|
|
|
Intuitive design, isn't it? You have to close the splash screen manually, and afterwards nothing happens, though the process still "lives" in TaskManager. Wonderful!
By the way, haven't you found further gems in the SplashScreen class, e.g. showing the main window of the application?
|
|
|
|
|
SplashScreen class does not contain any user code, only Visual Studio generated stuff (i.e. only constructor with InitializeComponent). This splash screen is launched in some sort of background thread and is terminated later by calling Thread.Abort. Surely it doesn't quite work. Splash screen hangs in front of main window until you move a mouse. I'm just too ignorant to understand deep logic which is embedded inside all that .
|
|
|
|
|
There's really not much logic in this one. Just a simple trap for next developer. The idea is, when the next developer spot the use of Thread.Abort and replace it with a Timer and Close(), the process will be caught in while loop.
[edit]Why would someone downvote that? Have a 5 to counter it.
Oxfords English < Official CCC Players Dictionary
Excuse me for my improper grammar and typos.
It's because English is my primary language, not my first language.
My first languages are C# and Java.
VB, ASP, JS, PHP and SQL are my second language.
Indonesian came as my third language.
My fourth language? I'm still creating it, I'll let you know when it's done! 
modified 21-Nov-11 5:49am.
|
|
|
|
|
So not only does it display a splash screen in a very bad way it also creates and displays a UI control on a non-UI thread. Classic.
|
|
|
|
|
Better one ...
private static void DoSplash()
{
Interaction.Shell(Application.StartupPath + "\\splashscreen.exe", AppWinStyle.MaximizedFocus, true, -1)
}
.. and God help us all 
|
|
|
|
|
AAAAAAAAARGH!
My colleague just told me that he has set up a document with a table of 20 columns to get a layout with 5 columns working. He claims it's "more flexible" 
regards Torsten
I never finish anyth...
|
|
|
|
|
Yeah, thats an "ARGH!" 
Just because the code works, it doesn't mean that it is good code.
|
|
|
|
|
In an excel sub I have to copy and paste a large chunk of data from one workbook to another.
On paste I need to close the workbook I copied from, and before I can it shows the message about a large amount of data on the clipboard.
My work around?
Selection.Copy
Windows("Testbed.xlsm").Activate
Range("A1").Select
ActiveSheet.Paste
Range("A1").Select
Selection.Copy
ActiveSheet.Paste
Windows("test.xlsm").Activate
ActiveWindow.Close
Those two lines of copy/paste in the middle save the day, but really ought to be consigned to the dustbin of depression.
------------------------------------
I will never again mention that I was the poster of the One Millionth Lounge Post, nor that it was complete drivel. Dalek Dave
CCC Link[ ^]
Trolls[ ^]
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
