|
Well, that was the biggest bunch of tripe spouted as an erudite document that I've read since college. That's worth the hall of shame all by itself.
It's stored as images when HTML text would be much more readable, manageable, and condensed in storage costs to boot.
This guy is using circular logic to justify not supporting the GOTO command, which I found ironic.
They copyrighted something that anyone should be ashamed to claim as their own.
Spell-checkers have been around forever, I'd have thought a professor might have found one by now.
I have to admit that I started hating GOTOs several decades ago when I read one tome without a single comment in it and as near as I could tell about a third of the code was dead code. I'm predisposed to like a document that advocates this concept and I didn't see one valid argument given.
Says it produces errors, which I've seen firsthand, but doesn't explain why they are produced.
The only reason you'd need to re-read it, is if you are searching (again) for its logic.
I kind of liked the original poster posting it like it is a document worth reading, but puts it in the hall of shame. Eliminating GOTO statements deserves a well written document. That wasn't it.
|
|
|
|
|
Well, that "tripe" was written by Dr. Dijkstra who is considered to be the father of programming languages and much of the framework of what we call computer science today. If you actually read the beginning it was also written in 1968, on a typewriter. You ever seen one, child? There is no spell checker on an IBM Selectric.
I also have seen developers today utilize GOTO: in C# which makes me shudder!
|
|
|
|
|
Just started working on some objective C code today and been giggling quite a bit. I thought I'd post this little gem.
NSString *dateCompletedTitle = [[NSString alloc] initWithFormat:@"%@", NSLocalizedString(@"PDFCompletedKey", @"")];
Creating a string to return a localized string that's formatted as a string by creating another string. Even better, the application only supports one language, English.
And if you did localize it to support a number of languages, the translator would have no idea of what PDFCompletedKey was as there is no comment.
Life's too short to refactor this project.
"You get that on the big jobs."
|
|
|
|
|
One of the gems I keep finding in a (former) coworker's code:
CString string;
string.Format(_T("some text")); CString::Format() does 'C' printf() style formatting. Why go through all that just to initialize a string to a constant value?
For the non-MFC folks in the audience:
CString string(_T("some text")); is the preferred way to do this.
Software Zen: delete this;
|
|
|
|
|
There's a slight memory management issue at work here though.
If using iOS ref counting (not ARC), the variable you're showing is retained, whereas the localized string answer would be autoreleased.
So it's a fancy way of doing [NSLocalizedString(...) copy].
'As programmers go, I'm fairly social. Which still means I'm a borderline sociopath by normal standards.' Jeff Atwood
'I'm French! Why do you think I've got this outrrrrageous accent?' Monty Python and the Holy Grail
|
|
|
|
|
Honestly, no matter how bad or well written it is, all objective C code looks like a coding horror to me. But I suppose this looks worse then most.
|
|
|
|
|
SELECT MONTH + MONTH(DATEADD(qq,-1,DATEADD(qq,DATEDIFF(qq,0,@Today),0))) - 1
FROM table1 t JOIN (SELECT TOP 3 row_number() over (ORDER BY fieldA) as MONTH FROM AnyTable) B on 1 = 1
The first MONTH is actually the aliased field name from B. Why alias a field using the same name as a built-in function? Very confusing to follow. Although, unfortunately, it does actually work.
On the plus side, joining to AnyTable using Top 3 Row_Number() is a clever way to guarantee 3 rows. Guess I could also put this in the Clever Code but it was written by the same dev.
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
ryanb31 wrote: Although, unfortunately, it does actually work
Its an unfortunate issue that you posted the code saying unfortunately its work.
Did you loose your job because of this unfortunate event?
|
|
|
|
|
Unfortunately, he didn't lose the unfortunate job.
|
|
|
|
|
It's bad practice to name something using the same name as a built in function, even if it does work.
|
|
|
|
|
The bad practice is failing to write the statement explicitly.
Why change MONTH when it's meant to be 'month'?
The shame is not using "SELECT B.[MONTH] + MONTH..."
Yet, even that is minor.
|
|
|
|
|
One of our legacy reporting applications written in VB6 and using Crystal Reports recently started experiencing random crashes on the customer end when opening reports. The problem never occured in the development environment, or in any of the test environments we use. As mentioned, crashes were random, and were happening regardless of the report. This is what I found in the General Declarations of the Reports form:
Dim app As CRAXDRT.Application
Why is this even possible?. I changed it to
Dim CRApp As CRAXDRT.Application
and replaced where needed...problem resolved. Anyone see how this might cause random crashes?
"Go forth into the source" - Neal Morse
|
|
|
|
|
Perhaps there was a global variable called "app" already, and declaring another "app" variable at form level was causing code in the form that was trying to reference the global variable to reference the local one instead?
Or maybe your app is just crap! :P
|
|
|
|
|
Well he did say it was using Crystal Reports already.
Chris Meech
I am Canadian. [heard in a local bar]
In theory there is no difference between theory and practice. In practice there is. [Yogi Berra]
posting about Crystal Reports here is like discussing gay marriage on a catholic church’s website.[Nishant Sivakumar]
|
|
|
|
|
Which I why I called it CRApp! Self-documenting code!
"Go forth into the source" - Neal Morse
|
|
|
|
|
kmoorevs wrote: Anyone see how this might cause random crashes?
No, certainly a variable name won't cause that.
|
|
|
|
|
You are correct. One of the affected customers is running a new version with the object renamed. Due to the randomness of it, it appeared to have solved the problem, however, the problem has resurfaced. I'm actually glad the variable/object name was not the culprit...it would've violated scope as I understand it. Luckily, in the last build, I put in a simple trace log so that I now know the method causing the fault. (I can see exactly where CRApp is CRApping out!) Still, there are some variable names (like app) that one should avoid.
"Go forth into the source" - Neal Morse
|
|
|
|
|
Did they try rebooting/reinstalling previous version first? Maybe the file was corrupted.
"You get that on the big jobs."
|
|
|
|
|
Tried that a long while back, but the problem persists...changing the variable name was not the answer. Starting to smell like dll hell, but even that puzzles me, since it seems so random. Anyway, I know this is the wrong forum for troubleshooting. Thanks
"Go forth into the source" - Neal Morse
|
|
|
|
|
Way, way back when I first started programming in VB6 (about eight years ago, haven't touched it since!) I seem to recall there was a global variable that VB6 defined as "App"
Examples: App.PrevInstance, App.Title, App.HelpFile
It's possible that, somewhere without even knowing it, your application was referring to a variable on the VB6 App object (which wouldn't exist in your redefinition of the app variable, remember VB6 is case insensitive).
Being a .NET developer today, the fact that your app was done in VB6 is one thing that clued me in on this issue: the global App variable does not exist in VB.NET.
|
|
|
|
|
Exactly! (and thanks for posting!) I was wondering how I could even declare app as a Crystal Report Application object to begin with. Turns out it works fine and was not the cause of our problems. The problem was corrected by using late binding on the Crystal App object.
"Go forth into the source" - Neal Morse
|
|
|
|
|
Inspired by the goto comments in the lounge today...
Msny years ago a co-worker showed me his first program after we had banned the use of goto statements at our company.
His program had a main loop like:
If var = 1 gosub 100
If var = 2 gosub 200
and so on..
and inside each subroutine before leaving, it would set var to whatever it needed to be next.
An abstracted goto !
This is back in the days before OO and events. This was procedural type code and in this case.. a goto would have been clearly easier to understand.
|
|
|
|
|
That's why I always get scared when such rules are preached religiously and then applied at all cost. I often write code for old 8 bit computers or microcontrollers and calling functions for everything will result in a slow processor working more on the stack than the actual task. Using goto or branching instructions in assembly then will make more of the two most valuable resources, CPU and memory. Thinking and making most of the resources at your disposal is more important than blindly following rules.
I'm invincible, I can't be vinced
|
|
|
|
|
Agreed.
I really don't understand the goto hate, although I've never worked in an environment where it was an issue. There are times when goto makes sense even in modern programming techniques.
|
|
|
|
|
I can understand it.
There are indeed times when goto makes sense. The problem is that it is taught to people who do not have the experience to understand when those times are, so use it when a "proper" alternative would be more work.
Blame the teachers! I do...
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
|
|
|
|