|
Nice ans well, but I expect some rcommendation any time now that will tell us to wear feathers on our heads and chant while dancing around the computer.
At least artificial intelligence already is superior to natural stupidity
|
|
|
|
|
The chant would be "Owe waa taw goo sigh M"? (Start slowly, pick up speed, enlightenment eventually comes.)
|
|
|
|
|
How about this test method:
AnalyseSchoolHistoryForConflicts_SchoolHistoryHasStartDateAndEndDateAndIncomingItemStartDateIsInbetween_DatesOverlapWarningAdded()
This is a unit test method. It says what it's testing, the scenario and the expected outcome.
|
|
|
|
|
You guys have obviously never written any objective C. The following method signature (without defined parameter names) is a legit initializer method from the Apple code base for the NSBitmapImageRep[^][] object. God only knows what some users have made.
initWithBitmapDataPlanes:pixelsWide:pixelsHigh:bitsPerSample:samplesPerPixel:hasAlpha:isPlanar:colorSpaceName:bitmapFormat:bytesPerRow:bitsPerPixel:
|
|
|
|
|
and that is why I prefer ISO standard C
|
|
|
|
|
What is actually so bad about this?
The length only?
If yes, then WTF? You are kvetching about length? Why?
If not, then fill it in here:
__________________________
|
|
|
|
|
The length is a WTF because it makes it unreadable.
|
|
|
|
|
Eh?
Unreadable in what sense?
I can read quite clearly, as well as understand the intent.
Long names are inherently self-documenting.
I sincerely do NOT understand your response.
To me, tersely abbreviated names are not only unreadable, but quite unnecessary in this day-and-age of auto-completion.
|
|
|
|
|
Considering the most common coding convention argues for 80-character lines, and given that only the method name contains 113 characters I would say yes, it is very unreadable.
Saludos!!
____Juan
|
|
|
|
|
The same reason that writing a 4 page essay in a comment in the lounge is unreadable. You have to parse a lot of text before you can begin to understand what the purpose is. Just get to the point, which I'm sure can be expressed in fewer than 15 words or however many are in that title.
|
|
|
|
|
Lolz. Apparently self-documenting code means that we never have to write commentary? Has there been a formal proof that camel case and embedded separators cover the full semantics of natural language?
|
|
|
|
|
In college, did you title your essays using the entire contents of the essays, or did you use something shorter?
Longer variables take longer for humans to read, they can lead to extra horizontal scrolling (the Devil!), they take longer to type, and they are not necessary.
INSWSAEJETGTMA...
Im_Not_Saying_We_Should_Abbreviate_Excessively_Just_Enough_To_Get_The_Meaning_Across...
// If you want to explain something more, put it in a comment above the variable declaration so it doesn't follow the variable around.
abbreviateAppropriately...
|
|
|
|
|
/** <summary>That should go here.</summary> */
[Description("Or perhaps here.")]
abbreviateAppropriately...
so it does follow the method around and is more localizable.
|
|
|
|
|
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.
|
|
|
|