• Jay (unregistered) in reply to evilspoons
    evilspoons:
    EXACTLY. A rewrite should only look at requirements, not the hideous old implementation. Throw that code into a vault and only take it out if you install the rewrite and they go "heyyy it doesn't work like it used to". Then you go "well, why did you give me invalid requirements?". Only THEN do you take out the old program and try to see how it behaved, add those to the requirements, and then lock it in a dark place again.

    You're assuming here that the requirements document is complete, accurate, and up-to-date.

    Yes, in a perfect world the requirements document would have started out describing the requirements 100% accurately, and every change made to the system since would have begun by updating the requirements document.

    But in a perfect world, the code would be clear, concise, and bug-free.

    So, hmm, as the code apparently has problems, it would seem that we are NOT living in a perfect world. So why do you assume that there even is a requirements document? Never mind supposing that it is worth the time it would take to dust off the cover and peel the molding pages apart?

  • RBoy (unregistered) in reply to Darth Iterator
    Darth Iterator:
    I have iterated your methods pray I don't iterate them any further.

    Have you?

  • Jay (unregistered)

    Maybe I'm getting jaded, but this code doesn't look all that bad to me. I think I pretty well understood it on a first reading. The IF's are all nicely laid out one after the other. As others have noted, even with nothing to go on but this one function, it's pretty obvious that this is from a program to manage loading of a Dash 8 aircraft.

    Yes, the function name is stupid. I'm not sure if the variables with names like "Frame500" are referring to field number 500 on an input frame object, in which case that's a really dumb name, or if this is Dash 8 airframe style 500, etc, in which case they would be very good names. "pax" is pretty obviously an abbreviation of "passengers", and "loadtot" et al aren't that tough to guess.

    All told I'd say this is a moderately well written module. If this is the worst you have to deal with, you don't want to apply for a job at my company.

  • Anon (unregistered) in reply to frits
    frits:
    Anon:
    ... a VCR ...

    What's that?

    It's like an 8-track for video images. Except that it only has one track.

  • (cs) in reply to Anon
    Anon:
    frits:
    Anon:
    ... a VCR ...

    What's that?

    It's like an 8-track for video images. Except that it only has one track.

    Oh. Like a kinetoscope?

  • LB (unregistered) in reply to Yardik
    Yardik:
    Mark:
    ... and that means you'd better make sure you understand what the legacy system does (not just what somenoe says it's "supposed to" do).
    ... If you're a responsible and well-adjusted person you work with the business to recreate the requirements from the original code as you go, not try to 'stick it to em'.
    Exactly. By the time someone needs to go back and completely re-write an old legacy system, chances are the original specs either don't exist or are so hopelessly outdated that they may as well not exist. The developer's first task (which is usually by far the hardest task in such a job) is to sort through all the old code and map out what exactly it's doing, then write up a complete description of it, including all the odd little idiosyncrasies which may be bugs or may be special rules. You can't expect the users to give you good specs. You need to give them this descriptive spec of what the legacy app does. Then you can find out from them which parts of it are desired and need to be reproduced, and which parts are not desired. That's where you get your spec for the new version.
  • Basically Visualize This (unregistered)
      If Frame500 = 1 And pax > 37 Then
    should be
      If Frame500 = iOne And pax > iThirtySeven Then
    and
      Else
      End If
    should be shortened to a single line to save space.
  • Ralph (unregistered)

    Our marketdroids are always begging for the app to be "more engaging" and "responsive to the user", so let's put those empty else clauses to work shall we?

      If totalload1 > 2000 Then
         MsgBox "OVERWEIGHT Fwd Shelf ", vbOKOnly
      Else
         MsgBox "Good job on the Fwd Shelf! ", vbOKOnly
      End If
      If ttshelf > 1000 Then
         MsgBox "OVERWEIGHT Aft Shelf ", vbOKOnly
      Else
         MsgBox "You got the Aft Shelf right too! ", vbOKOnly
      End If

    Add in a bunch more self-esteem-building affirmations, together with the requisite number of cartoons and colorful animations to keep that short attention span refocused, and I think we're good!

    Besides, we all know the more times we make the user click to finish their task, the less they perceive the slowness of the system.

  • jkupski (unregistered) in reply to Drak
    Drak:
    Nice.. VB6 in aircraft software. Maybe, hopefully, it's simulator software.

    (Assuming the Dash 8 involved is in fact the de Havilland Dash 8 (see http://en.wikipedia.org/wiki/Bombardier_Dash_8))

    It looks like it's a check of the weight and balance limits of the aircraft (for those who've never been exposed to this kind of thing, the center of gravity of an aircraft must not be too far forward, nor too far aft, else you end up with something that isn't controllable). Really, I don't think there's anything wrong with VB6 here--these are fairly simple calculations, and I'd like to think that the ATP in command of the aircraft has already done his own work, and the computer is just a second pair of "eyes" on the process (though if it were written by someone, you know, competent, it would be much better).

  • Chris (unregistered) in reply to brazzy

    Exactly. If you want to do a re-write of an archaic, crazy app like this, you almost definitely don't want it to run like the current app, at least in significant edge cases.

  • Jochen Ritzel (unregistered)

    Consider, for example, Command 696: a method named that simply because Command1 through Command695 were already taken.

    I lol'd.

  • Bill This (unregistered) in reply to jkupski
    jkupski:
    (... the center of gravity of an aircraft must not be too far forward, nor too far aft, else you end up with something that isn't controllable). Really, I don't think there's anything wrong with VB6 here
    Yeah, because an uncontrollable aircraft is not such a big deal.

    We've been telling you for a quarter century: you can't rely on MS-based software. Not when it really matters. And, with the possible exception of luser desktops, it usually matters.

    When 154 people die because an "ancillary" system was running WinBlows (http://www.networkworld.com/news/2010/082310-trojan-blamed-for-spanish-air.html?hpg1=bn) it's time to start lining people up for execution. And I don't mean the multithreaded kind either. Seriously! It's either premeditated murder or capital negligence. No more Mr. Nice Guy!

  • Mom (unregistered)
    Private Sub Command696_Click()
      On Error GoTo Err_Command696_Click
    Duh!
  • (cs) in reply to Kuba
    Kuba:
    I'd be very careful. This seems to be a ground-based tool that manages airplane load and weight distribution. Probably it does other things, too, but Dash 8 is a plane made by Bombardier, PAX are passengers, etc. Maybe the submitter just doesn't have a clue, but the logic for this application is pretty much given by the manufacturer and airline operation manuals. I don't know this particular application, and I have nothing to do with airline industry, but I presume if I could figure it out in one minute, the submitter better ask themselves "should I be doing the job"?

    Yes, the application is a WTF, because many such frontline apps are on life support since day one, and all fixes/modifications are done with flames under your feet, and the industry is chronically short of money, yada yada.

    But methinks TDWTF is that the submitter seems somehow confused -- he shouldn't be.

    If I were rewriting this thing, I'd want to get my hands on whatever manual that DeHaviland puts out on cargo loading for this aircraft. A chat with someone who is condemned to use the existing version would also help...

  • anonymous (unregistered) in reply to Drak
    Drak:
    Nice.. VB6 in aircraft software. Maybe, hopefully, it's simulator software.

    (Assuming the Dash 8 involved is in fact the de Havilland Dash 8 (see http://en.wikipedia.org/wiki/Bombardier_Dash_8))

    Actually, it's from here (link removed due to stupid Akismet, the company name is Flyera). TRWTF is using your real name on a TDWTF submission.

  • M (unregistered) in reply to justsomedude
    justsomedude:
    On that note, VB has a bad wrap less becuase of the language, and more because of its accesibility. People who don't know much about good practices or developing for maintainability are more commonly using VB, but that doesn't mean the language itself is a WTF or that good code can't be written with it. Same goes for MS Access, used right, and within the limits of what it is designed for, it's a decent little app for small scall and quick turnarounds; the problem isn't the platform, it's the accessibility to poor developers.

    I really wanted to believe this. But I've been maintaining an app written in ASP and Access, and I can categorically say, they are terrible.

  • (cs) in reply to Gary
    Gary:
    ONLY IFF = ONLY (IF AND ONLY IF).

    Happy to help. My fees are reasonable. Let's go to the ATM machine, punch in your PIN number, and withdraw a shiny quarter.

    Remind me never to take you to the La Brea tar pits.

  • Anon (unregistered) in reply to frits
    frits:
    Anon:
    frits:
    Anon:
    ... a VCR ...

    What's that?

    It's like an 8-track for video images. Except that it only has one track.

    Oh. Like a kinetoscope?

    Yes, except, get this, it hooks up to your TV! No flickering light shining through acetate film!

  • justbeez (unregistered)

    If "nor never" = always Then MsgBox "FAIL !!!!!", vbOKOnly Else End If

  • dolor (unregistered)

    I for one am glad that I never had to debug software in the long-lost language of the Romans.

  • Ben (unregistered) in reply to Ken B.
    Ken B.:
    Gary:
    I am flying on a Dash-8 tomorrow. Ugh.
    Is it the 37-seater, or the roomier 29-seater? And does it have a SECTION D? (And don't forget to check if the AFT CARGO COMPARTMENT IS EMPTY!!!!)

    The answers are 37-seater, no, FILE NOT FOUND.

  • Ben (unregistered)
    Consider, for example, Command 696: a method named that simply because Command1 through Command695 were already taken.

    Thanks to MS Access's obfuscation wizard!

  • frits (unregistered)

    Actually this code works great on embedded file systems with no file system.

  • LB (unregistered) in reply to Ben
    Ben:
    Ken B.:
    Is it the 37-seater, or the roomier 29-seater? And does it have a SECTION D? (And don't forget to check if the AFT CARGO COMPARTMENT IS EMPTY!!!!)
    The answers are 37-seater, no, FILE NOT FOUND.
    So long as it's not CARGO NOT FOUND.
  • Larry (unregistered)

    TRWTF is yet another language without a while loop.

  • JJ (unregistered) in reply to TomatoQueen
    TomatoQueen:
    wtf:
    Mr Gangreen:
    DaveAronson:
    Kimvais:
    http://en.wikipedia.org/wiki/Bombardier_Dash_8#Incidents_and_accidents
    Too bad there is apparently no anchor #Hints_and_allegations.

    I don't find that stuff amusing anymore...

    The real WTF is the angels in the architecture. What were they thinking? Everyone knows that leads to an endless loop...

    Spinning in infinity.

    Hey, hallelujah!

  • only once (unregistered) in reply to Jay
    Jay:
    evilspoons:
    EXACTLY. A rewrite should only look at requirements, not the hideous old implementation. Throw that code into a vault and only take it out if you install the rewrite and they go "heyyy it doesn't work like it used to". Then you go "well, why did you give me invalid requirements?". Only THEN do you take out the old program and try to see how it behaved, add those to the requirements, and then lock it in a dark place again.

    You're assuming here that the requirements document is complete, accurate, and up-to-date.

    Yes, in a perfect world the requirements document would have started out describing the requirements 100% accurately, and every change made to the system since would have begun by updating the requirements document.

    But in a perfect world, the code would be clear, concise, and bug-free.

    So, hmm, as the code apparently has problems, it would seem that we are NOT living in a perfect world. So why do you assume that there even is a requirements document? Never mind supposing that it is worth the time it would take to dust off the cover and peel the molding pages apart?

    I think evilspoons was indicating that you should gather new requirements ( at least that is how I read it.

    However, gather new requirements is never easy. Gathering "updated" requirements is almost always impossible. User's will invariably say "Just make it work like the old one did". They do not want to spend hours in meeting, talking about the way they work. If you try to explain that you cannot make sense of what the old software was doing, then they do not trust you. And I would have to say they are partly correct. If you cannot trace old code, even if it leads to a dead branch ( never drops in this loop ), then I would not entirely trust you either.

  • (cs) in reply to Aaron
    Aaron:
    "frame500 = 1" and "frame500 = 2". Pretty sure you didn't mean to assign a value here.

    Assuming that's Java rather than some crazy hybrid language invented just to troll TDWTF forums (which wouldn't actually surprise me), that's not an assignment, that's a compile-time error. Unlike C, Java requires you to compare assignments involving non-boolean values to 0 explicitly if you want to use them in an if condition.

  • only once (unregistered) in reply to Chris
    Chris:
    Exactly. If you want to do a re-write of an archaic, crazy app like this, you almost definitely *don't* want it to run like the current app, at least in significant edge cases.
    Yes. you don't want it "run" like the existing software, but you do want to maintain any logic ( business rules ) that should be maintained. And herein lies the basic problem with re-factoring. So many people say that you should not look at the existing code , and start from scratch. Wrong. You are basically going to have to look at the existing code to get the basis for the requirements. Like many people have stated, rarely are you going to find a requirement doc that matches existing code. You document WHAT it does, but forget HOW it does it ( the refactoring part ). Go over any anomalies you ( think ) you have found with the users, question everything, and re-write from those new specs. Separate the business logic from the programming logic.
  • Morry (unregistered)

    I love it when people come in and want to rewrite Airline apps. That noice I hear when their enthusiasm pops is truly heart warming.

  • Been There (unregistered)

    I think everybody's missing something. Sure, it happens to be in VBA ... which is slightly suspicious in and of itself. The main points to note are:

    • 696 functions called Command1 .. Command 696

    • No function parameters; just globals

    • Every "if" lovingly paired with an "else"

    Doesn't that sound like generated code to you? It does to me. I strongly suspect there is some godawful "design" document thrown together in an Excel spreadsheet, with a bonkers in-house code generator, behind this.

    Still, at least that way there's a design...

  • Mark (unregistered) in reply to Been There
    Been There:
    Doesn't that sound like generated code to you?

    Nope. I guess it would if I weren't familiar with VB; but actually it sounds like lazy VB programming - which is to say, most of the VB programming I've seen.

    When you design a form in VB, it provides a default name for each control. The default name is the type of control followed by a sequence number. Many programmers don't bother to change the default name, even though you almost always should. The method names are derived from the control name. (This snippet is showing the code behind a command button, btw.)

    VB also is designed to be usable by people who probably never learned the reasons that globals are inferior to parameter-passing; most beginners I know would rather use globals (for exactly the reasons they should want to avoid them).

    The obsessive use of Else just looks like an idiosyncratic coding style to me.

  • Skip (unregistered)

    Maybe this is the real reason Qantas (or more accurately Qantaslink) grounded 5 of its Dash 8 fleet..... The landing gear can't handle it when the AFT compartment is not empty

    http://au.news.yahoo.com/a/-/latest/7800735/qantas-grounds-planes-flights-cancelled/

  • Brian Manahan (unregistered) in reply to Bill This
    Bill This:
    Yeah, because an uncontrollable aircraft is not such a big deal.

    We've been telling you for a quarter century: you can't rely on MS-based software. Not when it really matters. And, with the possible exception of luser desktops, it usually matters.

    When 154 people die because an "ancillary" system was running WinBlows (http://www.networkworld.com/news/2010/082310-trojan-blamed-for-spanish-air.html?hpg1=bn) it's time to start lining people up for execution. And I don't mean the multithreaded kind either. Seriously! It's either premeditated murder or capital negligence. No more Mr. Nice Guy!

    The article you posted didn't even mention the OS. Fail.

  • immitto (unregistered) in reply to Been There
    Been There:
    I think everybody's missing something. Sure, it happens to be in VBA ... which is slightly suspicious in and of itself. The main points to note are:
    • 696 functions called Command1 .. Command 696

    • No function parameters; just globals

    • Every "if" lovingly paired with an "else"

    Doesn't that sound like generated code to you? It does to me. I strongly suspect there is some godawful "design" document thrown together in an Excel spreadsheet, with a bonkers in-house code generator, behind this.

    Still, at least that way there's a design...

    No it sounds more like the default names that VB & VBA give to everything. "Command###" is the default name for command buttons, so I kinda feel sorry for anyone who has to support an app that contains 696 buttons. ESPECIALLY if it's in Access. And if the original programmer kept the default button names, you just know he probably also kept the default names for EVERYTHING: Form1, Form2, Form3, Text1, Text2, Text3, etc.

    Trust me... I've been there, done that -- and ran away screaming! Truly a "legacy code" nightmare.

  • steve (unregistered)

    The code may not be pretty, but I'd leave it alone. I guarantee that the users care more about the behavior of the app (however screwy) remaining the same than they do about it being "improved". And they don't care at all about the elegance of the code.

    Not only that, it's almost a certainty that this app encodes some complex set of business rules that the author will miss when he rewrites it. And nobody wants to be the guy who broke the mission-critical cargo loading app.

    If the engineer who submitted this wants to make a real difference, he'd spend his time writing a robust set of automated tests for the existing code.

  • (cs) in reply to immitto
    immitto:
    Been There:
    I think everybody's missing something. Sure, it happens to be in VBA ... which is slightly suspicious in and of itself. The main points to note are:
    • 696 functions called Command1 .. Command 696

    • No function parameters; just globals

    • Every "if" lovingly paired with an "else"

    Doesn't that sound like generated code to you? It does to me. I strongly suspect there is some godawful "design" document thrown together in an Excel spreadsheet, with a bonkers in-house code generator, behind this.

    Still, at least that way there's a design...

    No it sounds more like the default names that VB & VBA give to everything. "Command###" is the default name for command buttons, so I kinda feel sorry for anyone who has to support an app that contains 696 buttons. ESPECIALLY if it's in Access. And if the original programmer kept the default button names, you just know he probably also kept the default names for EVERYTHING: Form1, Form2, Form3, Text1, Text2, Text3, etc.

    Trust me... I've been there, done that -- and ran away screaming! Truly a "legacy code" nightmare.

    Unfortunately, people never seem to realize that (a) the names are defaults and (b) it's a really good idea to change them to something that makes sense. I ran into this when updating factory test software written in M$ Visual C++ V6. {shudder}

  • Doozerboy (unregistered) in reply to LB
    LB:
    The developer's first task (which is usually by far the hardest task in such a job) is to sort through all the old code and map out what exactly it's doing, then write up a complete description of it, including all the odd little idiosyncrasies which may be bugs or may be special rules.

    Exactly. I once spent 2 months unpicking a previous contractors mess, carefully mapping out what each method did, and called.

    Ye gods, it was awful and one day i might even write it up for here, macros nested within macros (It was An Access project BTW), helpfully hidden queries, every single (non-macro) line of code in the Main form code behind, functions in textboxes on the form. The front end was over 300 MB in size, and took 10 minutes to load, due to bunch of Dlookups, that were 99% useless to the user. The beautiful thing about that project was that i had to race against time as the back-end was rapidly approaching Access's 2GB file size limit.

  • (cs) in reply to Aaron
    Aaron:
    The Nerve:
    Fixed?
      if (frame500 = 1 && totalloadsecd > 0) {
         JOptionPane.showMessageDialog((Frame) null, "DASH 8 WITHOUT SECTION D ", vbOKOnly  
      }
      if (frame500 = 2 && totalloadsecd > 2150) {
         JOptionPane.showMessageDialog((Frame) null, "OVERWEIGHT SECTION D ", vbOKOnly  
      }
    

    "frame500 = 1" and "frame500 = 2". Pretty sure you didn't mean to assign a value here.

    In VB and VBA the same operator is used for both. You have to look at the whole statement to determine what the expression actually means.

  • Bill This (unregistered) in reply to Brian Manahan
    Brian Manahan:
    Bill This:
    Yeah, because an uncontrollable aircraft is not such a big deal.

    We've been telling you for a quarter century: you can't rely on MS-based software. Not when it really matters. And, with the possible exception of luser desktops, it usually matters.

    When 154 people die because an "ancillary" system was running WinBlows (http://www.networkworld.com/news/2010/082310-trojan-blamed-for-spanish-air.html?hpg1=bn) it's time to start lining people up for execution. And I don't mean the multithreaded kind either. Seriously! It's either premeditated murder or capital negligence. No more Mr. Nice Guy!

    The article you posted didn't even mention the OS. Fail.
    And the possibilities are...?? How much do you wanna bet? I mean really, do you think there's one chance in a thousand that it is anything BUT WinBlows? Yeah, sure, other systems could hypothetically get eaten by a trojan, but back in real life, the ones dropping like flies every day are always WinBlows. And you know that, or you have no business hanging around an IT site.

  • Dirge (unregistered) in reply to evilspoons
    evilspoons:
    EXACTLY. A rewrite should only look at requirements, not the hideous old implementation. Throw that code into a vault and only take it out if you install the rewrite and they go "heyyy it doesn't work like it used to". Then you go "well, why did you give me invalid requirements?". Only THEN do you take out the old program and try to see how it behaved, add those to the requirements, and then lock it in a dark place again.

    Yes, you're right. People who do development related to systems that can kill people when they malfunction (like aircraft) should definitely play the petty-amateur-lawyer, it's-not-in-the-requirements blame game instead of doing the job right the first time. It's endearing and makes them lots of friends.

  • (cs) in reply to Bill This
    Bill This:
    Brian Manahan:
    Bill This:
    Yeah, because an uncontrollable aircraft is not such a big deal.

    We've been telling you for a quarter century: you can't rely on MS-based software. Not when it really matters. And, with the possible exception of luser desktops, it usually matters.

    When 154 people die because an "ancillary" system was running WinBlows (http://www.networkworld.com/news/2010/082310-trojan-blamed-for-spanish-air.html?hpg1=bn) it's time to start lining people up for execution. And I don't mean the multithreaded kind either. Seriously! It's either premeditated murder or capital negligence. No more Mr. Nice Guy!

    The article you posted didn't even mention the OS. Fail.
    And the possibilities are...?? How much do you wanna bet? I mean really, do you think there's one chance in a thousand that it is anything BUT WinBlows? Yeah, sure, other systems could hypothetically get eaten by a trojan, but back in real life, the ones dropping like flies every day are always WinBlows. And you know that, or you have no business hanging around an IT site.

    You said Winblows on TDWTF, which means you're either a troll or a spoof. You made me laugh, so I call spoof. What do I win?

  • (cs) in reply to justsomedude
    justsomedude:
    Yardik:
    Umm.. Where is the WTF? Badly written, perhaps... Lacking easy maintainability, sure... But a WTF? Not really. I've seen worse, daily.. for most of my career. If the function was being recursively called with a static integer and a case statement to decide which if statement to check.. now that would be a WTF.
    ...snip...
    

    Now that would be a WTF. Excuse any syntactical errors, I haven't written any VB in a looooong time.

    -Yard

    Agreed, planned to say the same thing. This is ugly as hell and it certainly shows that the devloper wasn't your best and brightest, but it isn't really a WTF.

    On that note, VB has a bad wrap less becuase of the language, and more because of its accesibility. People who don't know much about good practices or developing for maintainability are more commonly using VB, but that doesn't mean the language itself is a WTF or that good code can't be written with it. Same goes for MS Access, used right, and within the limits of what it is designed for, it's a decent little app for small scall and quick turnarounds; the problem isn't the platform, it's the accessibility to poor developers.

    No, the problem is supercilious cliquey programmers who think a hammer is a spoon, and feel threatened by it. You might as well criticise Polyfilla (Spackle) because you don't need to be a master plasterer to smooth over a crack with it. 98% of all VB/VBA code -- official statistics from my bum -- is used in places where if VB did not exist, there would be no automation, rather than a better written piece of code.

  • Jongo (unregistered) in reply to Bill This
    Bill This:
    jkupski:
    (... the center of gravity of an aircraft must not be too far forward, nor too far aft, else you end up with something that isn't controllable). Really, I don't think there's anything wrong with VB6 here
    Yeah, because an uncontrollable aircraft is not such a big deal.

    We've been telling you for a quarter century: you can't rely on MS-based software. Not when it really matters. And, with the possible exception of luser desktops, it usually matters.

    When 154 people die because an "ancillary" system was running WinBlows (http://www.networkworld.com/news/2010/082310-trojan-blamed-for-spanish-air.html?hpg1=bn) it's time to start lining people up for execution. And I don't mean the multithreaded kind either. Seriously! It's either premeditated murder or capital negligence. No more Mr. Nice Guy!

    You seem to miss the point..... As thousands have said before me, the code appears to be a ground based sanity check, totally independent of software in the actual plane. A discrepancy in weights might cause some delays while airline staff argued over the best course of action, but that's it. VB is not being used in anything even remotely critical here....

  • Jongo (unregistered) in reply to Bill This
    Bill This:
    jkupski:
    (... the center of gravity of an aircraft must not be too far forward, nor too far aft, else you end up with something that isn't controllable). Really, I don't think there's anything wrong with VB6 here
    Yeah, because an uncontrollable aircraft is not such a big deal.

    We've been telling you for a quarter century: you can't rely on MS-based software. Not when it really matters. And, with the possible exception of luser desktops, it usually matters.

    When 154 people die because an "ancillary" system was running WinBlows (http://www.networkworld.com/news/2010/082310-trojan-blamed-for-spanish-air.html?hpg1=bn) it's time to start lining people up for execution. And I don't mean the multithreaded kind either. Seriously! It's either premeditated murder or capital negligence. No more Mr. Nice Guy!

  • Erik (unregistered) in reply to Jay

    You don't think having 696+ functions named like that is a problem??

    On one of the few .NET projects I've worked on, our idiot contractor kept naming components the same way, we had things like: SqlCommand1 SqlCommand2 Button4 Label5

    I told him continuously not to name components that way, but he would not listen. Finally I used the 'jerk' method and started using flammatory function names like: RidiculouslyNamedComponentNumber4095 WhoKnowsWhatThisDoesNumber4992 SomeKindOfCommand2

    I only had to name about 3 methods like that before he finally got a clue & started using descriptive names.

  • Simon (unregistered)

    I bet he'd run into more problems rewriting Command 66, which causes the software to hunt down and kill all the Jedi.

  • clisse (unregistered) in reply to Kuba

    Totally agree. Yes the code is wtf. But, as pointed out, the logics seems pretty easy to understand for anybody who has an idea of how a commercial aircraft works. Chances are one will fail as a programmer if he does not understand the domain of the client for which he is working. It has nothing to do with computer science or patterns or language. You have to understand your client's domain before you can hope to serve him well. That's a perfect example.

  • fgsfds (unregistered)

    What's scary is that this software appears to be related to aircraft...

    starts digging a bunker to protect against falling planes

  • junior (unregistered) in reply to Mark
    Mark:

    The default name is the type of control followed by a sequence number. Many programmers don't bother to change the default name, even though you almost always should.

    That's procedural programming - not visual programming.

    Why would you want to change the default name? DUH, so that you recognise what it means when you read the code.

    Why would you want to read the code? DUH, because in your prgramming environment it's not trivially linked to a visual organisational paridigm.

    Over 40 years I've seen that XXXX programmers think YYYY is bad XXXX code (insert what ever you love and hate). You like Pascal? FORTRAN is badly written Pascal. You like C/C++/Java/Python? That VBA code is just badly written C/C++/Java/Python.

    He didn't even release his objects. His code is toooo verbose/not verbose enough. It's write-only. He used line labels. He used exceptions. He used a COMMON block.

    BLAAAAA.

    In some languages, it is critically important to use a disciplined naming convention. And in other languages a disciplined naming convention is enforced by the syntax: you don't need any discipline.

    And in Access VBA a disciplined naming convention was important for impressing ignorant naive inexperienced programmers who where expert at only one mode of thinking.

    Apart from that, not so much.

Leave a comment on “Command 696”

Log In or post as a guest

Replying to comment #:

« Return to Article