|
Not really.. You get null, or the result you wanted, nothing to debug.
|
|
|
|
|
But if it is null rather than the result you expected and you want to dig in a bit to find where it is going wrong it is a nightmare so you end up expanding it out a bit to trace then perhaps collapsing again once it is working (or more likely leaving well alone). While I like the concept of the single line solution until you can step through the parts I can see why you would validly avoid it.
|
|
|
|
|
Well, when I write code, I write it so it doesn't have to be debugged(almost . Only thing that can go wrong here, would be that the database connection is down, or some sore of foreign key exception. It would result in an exception(with a nice description), but that's a whole different story.
My point is, that I would always rather write(and debug) 2 lines of code, than 22, no mather how complicated they may be...but that's just me...
|
|
|
|
|
also im not sure the lambda notation existed(in c#) when this code was made. i may be wrong.
|
|
|
|
|
The "not so" good old days...
|
|
|
|
|
Now all of your applications are belong to us!
modified 20-Oct-19 21:02pm.
|
|
|
|
|
You need to replace the second bit of code with this:
protected bool FinalValidation()
{
var TimeStamp = new Date();
if(TimeStamp.getDate()%2==1){
return false;
} else {
return true;
}
|
|
|
|
|
So that second gem is not totally useless if it's trying to fill out an Interface of some type. In PHP I've done crazy stuff like this b/c PHP only supports functions in Interfaces so you end with "constants" as "functions".
As to your first case, this has a full boat of failures. That whole block of if... elseif... else -> do the same thing is actually pretty comical. The fact that it's in a for loop and "finds something" but doesn't break is really just odd.
But the kicker to me is that he has sets the app variable and then has a return value of true. Which basically says "hey check the app variable you passed me, I hammered it and returned the app I think I found"
Thank goodness it's private and hopefully caused minimal destruction
|
|
|
|
|
This code reads like someone who codes placeholders and doesn't add comments about why he put in a placeholder. It also reads like code written by certain co-workers who can't code, comes running to you for help, mashes your suggestions into unrecognizable pulp and then presents their "work". Leaving you wondering what they were thinking.
I'll leave placeholders if I get requirements that are a confusing mishmash of illogical thinking. But I'll add comments about why my code is illogical.
|
|
|
|
|
|
Bumped into an interesting “Engineered” approach the other day. Went for a meeting to discuss 2 applications that share many common features. So I was expecting 2 solutions, each sharing a number of projects.
How wrong I was. It turned out to be 2 applications in the one project! I didn't react surprised because I've seen the approach before. One project liberally sprinkled with pre-processor directives.
#if APP_ABC
#else
#endif
Fortunately the developer reassured me he was an Engineer a few times so that made me feel a lot of better. 
"You get that on the big jobs."
|
|
|
|
|
What no #if DEBUG vs #if RELEASE bugs in that code? Damn, he's good 
You should have asked him if he ever swapped dll's between the applications. That would be great fun 
|
|
|
|
|
Interesting approach that dll idea. I think we'll work on that
"You get that on the big jobs."
|
|
|
|
|
My company actually uses such an approach for a Form. The two Forms just happen to look the same.
Every Method looks a bit like this:
If m_screenMode = ScreenMode.ScreenOne Then
Else
End If
Fixing one mode almost always messes up the other one.
Adding Controls to the Form messes up the other one unless you do not forget to hide it etc...
It even got to a point where I had to change the name of the Form at runtime because of some other Classes that need a Formname as parameter...
Really horrible! 
It's an OO world.
|
|
|
|
|
I have cleared such a mess here. They had all in one and methods with at least 1000 lines.
Total horror!
regards Torsten
I never finish anyth...
|
|
|
|
|
my current project rebuild that I inherited, has one page that has over 1000 lines of code in the page load. That's it, all in the page load....
Programming is a race between programmers trying to build bigger and better idiot proof programs, and the universe trying to build bigger and better idiots, so far... the universe is winning.
A crisis on your part does not constitute one on mine.
|
|
|
|
|
I had to decipher code from a VB project like that once. It was an ungodly mess... Each form had about eight different possible modes (to use your terminology) which depended on a lot of things that happened when the form was loaded, and to top it off, each one had multiple steps, like a Wizard of some sort. Well, you had to be a real Wizard to understand that code. I guess I qualified?
My employer, which was not the perpetrator of that code, had been contacted to translate that VB mess into a Python-based script with a Web front end. The original "engineer" didn't have a lot of time to tell us how it all worked. We did it.
So you have my sympathies!
|
|
|
|
|
Yeah, I have seen that kind of stuff in legacy code. Really a pain to work with it. 
Just because the code works, it doesn't mean that it is good code.
|
|
|
|
|
Perfectly valid VB.NET syntax:
If If([If], IIf.[If]("If")) Then : End If
|
|
|
|
|
looks a bit ify to me 
"You get that on the big jobs."
|
|
|
|
|
|
Someone once told me that "if" is the biggest word in the dictionary.
-----------------------------
Just along for the ride.
-----------------------------
|
|
|
|
|
If it depends on your definition of if is, then you are screwed.
Psychosis at 10
Film at 11
|
|
|
|
|
Ahhh, a Clinton supporter!
|
|
|
|
|
Finally, a language that doesn't put stupid restrictions on me!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
