The Engineer (wears a cowboy hat)
-
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
//Do stuff for ABC application
#else
//Do stuff for XYZ application
#endifFortunately the developer reassured me he was an Engineer a few times so that made me feel a lot of better. :doh:
"You get that on the big jobs."
-
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
//Do stuff for ABC application
#else
//Do stuff for XYZ application
#endifFortunately the developer reassured me he was an Engineer a few times so that made me feel a lot of better. :doh:
"You get that on the big jobs."
-
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
//Do stuff for ABC application
#else
//Do stuff for XYZ application
#endifFortunately the developer reassured me he was an Engineer a few times so that made me feel a lot of better. :doh:
"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
' Do stuff.
Else
' Do other stuff.
End IfFixing 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! X|
It's an OO world.
-
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
' Do stuff.
Else
' Do other stuff.
End IfFixing 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! X|
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.
-
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
' Do stuff.
Else
' Do other stuff.
End IfFixing 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! X|
It's an OO world.
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!
-
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
' Do stuff.
Else
' Do other stuff.
End IfFixing 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! X|
It's an OO world.
-
What no #if DEBUG vs #if RELEASE bugs in that code? :doh: Damn, he's good ;P You should have asked him if he ever swapped dll's between the applications. That would be great fun :laugh:
