|
SettingDeviceList_ReAddingAPreviouslyDeletedDevice_MustAddDevicesToRuleDevicesWithIsDeletedFalseAndIsIncludedTrue
You genuiely think this is readable? I got bored half way through, though it is 1 am where I am.
Michael K Gray wrote: If not, then fill it in here:
Well in probability this is several methods and attributes:
public void ReAddRequiredDeletedDevice()
{
if(!Device.IsDeleted && Device.IsIncluded)
{
}
}
public void SetDeviceList()
{
ReAddRequiredDeletedDevice();
return;
}
|
|
|
|
|
I've used support software from a certain hardware manufacturer. I think their software was written by an intern. All of the names are of the form:
#define ACR1_ACR2_ACR3_..._ACRN 0x........ where each ACRi is a three or four letter acronym for a hardware signal or state. Some of the names are well over 100 characters long, and completely unreadable.
Software Zen: delete this;
|
|
|
|
|
Wow. Hurts just looking at it.
|
|
|
|
|
I thought I am the naming jerk 
|
|
|
|
|
That is not real! I can't believe
|
|
|
|
|
I remember some years ago seeing this from one developer
void CommunicationsBlockScheduler::PerformScheduleAndExecuteOfCommunicationBlocksOnAProportialAndPriorityBasis(..)
And another developer on the same team took the oposite approach With gems like this:
void rssr()
This was replicate spread sheet rows
|
|
|
|
|
I feel like laughing my arse off 
That's what you do when you:
a) don't know how to use an IDE
b) don't know what OOP stands for
In particular, things like this, among others, were at the origin of OOP creation. Back in the seventies, structured programming hit a wall. Among other things, when your C program grew to 70 KLOCs or so, it seems, you ran out of reasonable identifiers. OOP, providing encapsulation and nice mechanisms to avoid global/public data, got past this issue.
|
|
|
|
|
Today I have my code horror hanging on the wall, in form of a printout from the ceiling to the floor. It's from a Win CE application which had been sent to a customer totally untested. Of course it failed miserably. It's almost ironic, but reporting the error in a message box also fails, due to a missing resource assembly. There also is no logging or any other mechanism to record errors. In short: Nobody really knows what's going on, not even the criminal who wrote that program.
The good news: The form that produces the error only has three methods, PageLoad() and two others. PageLoad() is only a few lines long. Initialisation, nothing really problematic. The first of the two other methods also was quite short. No problems here.
And now method #3:
- 350 lines of best spaghetti code rolled in a loop. Whenever this is executed, it will then hang up the entire application until it is done.
- A total of 17 try/catch blocks. Most catch blocks are totally empty. There is no error handling. The errors are simply swept under the rug and the code goes on as if nothing happened. Only three try to at least show the error in a message box, but our friend also failed at doing that. A brief scan of the rest of the application's code revealed that this is one of his favorite practices.
- There are eight code sequences which appear redundantly in this spaghetti monster. They could easily have been refactored into methods, but that of course would have harmed this work of art.
- The least of the problems, but does anybody know what a pflohneos, a finach or a fidel is? Those are just some of the variable names and they don't make any sense in any language I know.
Edit: Here a tiny sample cut out of the spaghetti monster. It's easy to see what he tries to do, but I can only guess what the intentions behind all this are. There are no comments and the strange variable names don't help very much:
try
{
string pflohneos = pfl.Name.ToUpper().Replace(pflnamen, "");
string danapfl = Path.Combine(Konstanten.Flashdir, pflohneos);
MessageLabel.Text = String.Format(tt.Readwert("t1"), danapfl);
Refresh();
try
{
FileInfo finach = new FileInfo(danapfl);
if (finach != null)
{
finach.Attributes &= ~FileAttributes.ReadOnly;
}
}
catch
{
}
pfl.Attributes &= ~FileAttributes.ReadOnly;
pfl.CopyTo(danapfl, true);
pfl.Delete();
}
catch
{
}
This is really an insult to the customer. Good that they will never get to see this mess in all its glory. My recommendation is to quickly write another application and then tar and feather the guy who wrote this one.
At least artificial intelligence already is superior to natural stupidity
|
|
|
|
|
always an empty catch block remind me open manhole's in road, i feel uncomfortable, doesn't know why
|
|
|
|
|
This is more like a city with every manhole opened.Care to go for a walk?
At least artificial intelligence already is superior to natural stupidity
|
|
|
|
|
CDP1802 wrote: This is more like a city with every manhole opened.Care to go for a walk?
Blindfolded.
|
|
|
|
|
CDP1802 wrote: but does anybody know what a pflohneos, a finach or a fidel is?
Pfl ohne os, FileInfo nach, and a well known cuban dictator. 
|
|
|
|
|
You are right. As if DD's CCC had been turned into a convention for variable names 
Pf = Pfad (Path)
l = ???
ohne = without
os = operating system (Does that make any sense at all? Sounds just like 'Purple dog over the moon')
fi = file info
nach = after (after what, exactly)?
I have marked the printout on the wall with color markers and also added some notes. At that place I also wrote 'Castro?'
Ah, I got it! He's deleting files!
fi = file (please note that he has galantly switched to English now)
del = delete
Here's another good one: danapfl
dana = Dateiname (filename, first I thought he started to name things after his daughters)
pf = Pfad (path)
l = ???
What form of insanity is this and how is it treated?
At least artificial intelligence already is superior to natural stupidity
|
|
|
|
|
Is the nutcase an old git that learned programming when bytes were expensive? I'm thinking about classic unix folder names like 'USR' here.
It could be fun decrypting this, but I think I would need to see more of the spaghetti monster to have a fair chance.
|
|
|
|
|
He definitely is. Decoding his stuff is fun as long as the code gives you some hints to what is going on. Here he's messing around with files. By trying to kill running executables he also gives me the impression that this is supposed to be some kind of DIY deployment and updating mechanism. It really gets funny when it comes to updating the obviously running program itself.
If you really want to have a challenge, then you should look at how he works with relational data. First everything is 'imported'. That means a lot of files are copied from somewhere in the network into a folder of the mobile device. The stuff is not XML or CSV, of which he usually is very fond. It's some creation of his own with fixed record and field lengths. And then he does not actually import anything. The program searches through those files to find and display data and changes are made to copies in another folder. Those changes are then sent off into the network again once the device is docked.
That's what I call retro! A 'database' in the style of 1960 and a DIY DBMS that relies heavily on the file system and 'database files' which must be named after the primary keys of the content. All that in a mobile application that has been finished last week 
At least artificial intelligence already is superior to natural stupidity
|
|
|
|
|
I'm one of those old gits. Honestly, I don't see what the problem is with the code except for the variable names. The programmer set all the files to read-only as a precaution. Probably not necessary now with the fast drives and IO buses, but in the 90's, it would have been a good precaution.
As for the term spaghetti monster, the term doesn't fit the example. At no time does the code jump out of scope, unless the definition has changed to include bad variable naming.
|
|
|
|
|
Can't answer the part about spaghetti code or the other errors as I haven't seen more of the code than anyone else on the forum.
But empty catch blocks is a coding horror in my book. And those abbreviated variable names are just plainly unnecessary today.
|
|
|
|
|
Cryptic variable names would have been a prrogramming crime 20 years back too. It was the binaries where bytes were expensive, not the source code.
|
|
|
|
|
Florin Jurcovici wrote: Cryptic variable names would have been a prrogramming crime 20 years back too
Indeed, I was thinking more like 40-50 years back in time when harddrives were a novelty.
|
|
|
|
|
Maybe he's using a technique of a friend I used to program with. His style was that all variables names must be 8 characters long. He would take 8 divided by the number of words you would normally use to describe the function/variable name to arrive at the number of letters to use from each word.
So "Print Spooler" would become "PRINSPOO" (not so bad, but note all caps), but "Shipping Station Control Loop" would become "SHSTCOLO".
Maybe as you suspect "dana" means "date in name", so "finach" may be "File Name Change"?
Psychosis at 10
Film at 11
Those who do not remember the past, are doomed to repeat it.
Those who do not remember the past, cannot build upon it.
|
|
|
|
|
Dateiname = Datei Name = file name. Datei is German word for file.
|
|
|
|
|
The real horror is that mess should never have gone out the door and into the customer's hands. 
The customer needs to be given proper replacement ASAP and, of course the original programmer should not touch the replacement program. And tar and feathers is to good for the individual who wrote that mess. 
Just because the code works, it doesn't mean that it is good code.
|
|
|
|
|
That's what I have rcommended. It will not be sufficient to refactor a little, as my bosses hope. I have inherited all his projects from the last eight years. They all are such a mess. At least I'm honored that my bosses call me every time they think that all hope is lost
At least artificial intelligence already is superior to natural stupidity
|
|
|
|
|
Well, it is good to feel needed, but that is a really nasty mess to have to clean up.
Yes, bosses always want a quick, inexpensive fix, but I agree with you that there is no simple quick fix for this. 
Just because the code works, it doesn't mean that it is good code.
|
|
|
|
|
My guess is that there's a good chance that this mess got to be delivered because the customer is a cheapskate. That's what you get when you contract to script kiddies instead of serious, qualified and more expensive programmers. And when you insist on things to be delivered yesterday, but never have time to discuss the actual requirements with your service provider.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
