• (cs)

    Ah, the cut-n-paste twins. I know them well. I think they now work for the offshore consulting company we use...

  • (cs)

    bangs head on desk repeatedly ... How the heck do people like these make it?!! I'm spending years slowly climbing the ladder as if I've got a cinder block strapped to my ankle (more like getting kicked in the head by those above me on the ladder). They must be better at social engineering than programming.

  • (cs)
    I'm working on VB6 code written by a Dutch speaker and maintained by an Italian, with variables and comments in both languages. And no indentation whatsoever.

    troll! :)

  • Kevin B. (unregistered)

    And for those interested... 'IkOwnJou' translates to 'I Own You', without spaces ofcourse.

    Yeah, i wonder if he's still as full of himself when he reads this article...

  • atkretsch (unregistered)

    He was Dutch, right? Maybe the company kept the snack room stocked with Space Cookies.

  • (cs)

    Ahhhh... Dutch programming.

    Code and a pancake?

    Boolean and a blintz?

  • (cs)

    "Rather than use a database, all non-static information is crammed in thousands of text files scattered across subfolders of subfolders"

    Accessing the file system directly is clearly faster than creating a DB connection and THEN looking for your data. A database is nothing more than a glorified set of files!

  • java.util.WTFException (unregistered) in reply to atkretsch
    atkretsch:
    He was Dutch, right? Maybe the company kept the snack room stocked with Space Cookies.

    if only :(

    im a dutchy myself, and i can say that even though the company does keep me and my fellow workers well in terms of cookies, none of them have proven to be the magic kind.

    that varname though reminds me of this guy i worked with in college, we both had some wacky naming conventions, but his were decidedly more out there, i tended to prefer short incredibly cryptic stuff

  • Gedoon (unregistered)

    If they only had used something that made sense, like the ascii control character named UNIT SEPARATOR, 0x1F, instead of the sound of a guy falling from an aeroplane...

  • AdT (unregistered) in reply to akatherder
    akatherder:
    Accessing the file system directly is clearly faster than creating a DB connection and THEN looking for your data. A database is nothing more than a glorified set of files!

    Accessing the disk sectors directly is clearly faster than creating a file handle and THEN looking for your data. A file is nothing more than a glorified set of disk sectors!

  • Publius (unregistered)

    Oh jeez, I didn't know this would make front page, I would have edited to add a couple things I've discovered since then.

    The reason there are 70 "Exit Function" statements: they use it instead of "ElseIf" and "Else" (despite knowing how to use these elsewhere in the code).

    If True Then DoThis Exit Function End If If False Then DoThat Exit Function End If If ... [snip]

    To pass information between forms, the concept of scope eludes them. They make a hidden TextBox and stuff information in it for other forms to read.

  • (cs) in reply to Kevin B.
    Kevin B.:
    And for those interested... 'IkOwnJou' translates to 'I Own You', without spaces ofcourse.

    Drat, you beat me to it.

    Needs to be said with appropriate emphasis.

    I K'OWNED YOU!

  • Anonymous (unregistered)

    I died a little inside.

    Why haven't these people been vasectomized yet? This is all so horrible, even for VB "programmers".

  • TheLurker (unregistered)

    "They make a hidden TextBox and stuff information in it for other forms to read."

    Errm. How old is this application? It sounds horribly like it might be a VB3 port. My (admittedly unreliable) memory says that was the recommended (read: only) method of passing information between forms way back before VB got "object orientation" in VB4.

  • Publius (unregistered) in reply to TheLurker
    TheLurker:
    Errm. How _old_ is this application? It sounds horribly like it might be a VB3 port. My (admittedly unreliable) memory says that was the recommended (read: only) method of passing information between forms way back before VB got "object orientation" in VB4.

    No, it was started in VB6, probably around the same time .NET came out. I won't rule out that they might have been VB3 programmers originally.

  • (cs)

    Reminds me of two systems I've worked on. The first was written by a French contract programmer, who translated all the comments to Spanish when a new boss terminated his contract. At least he was a competent programmer and his C code was readable.

    At my current job I've had to do a ground up rewrite of a massive Java web application. The code was appalling enough - JDBC and Servlet code top to bottom with no attempt at separate layers for data access, business logic and presentation. However, this was made worse by my predecessors commenting style. Very little code was actually commented, and much of it that was turned out to be in French, despite the fact that the guy was English. The only explanation for both the tortuous code and French comments were his arrogance and the amount of LSD he took at university (this he'd confided to a colleague before he left). Oh yeah, and I've also found out he used the company credit card to order computer games on Amazon!

  • (cs) in reply to AdT
    AdT:
    akatherder:
    Accessing the file system directly is clearly faster than creating a DB connection and THEN looking for your data. A database is nothing more than a glorified set of files!

    Accessing the disk sectors directly is clearly faster than creating a file handle and THEN looking for your data. A file is nothing more than a glorified set of disk sectors!

    Sybase (version 12 at least, not sure about 15) still recommends that you do essentially this by putting your data on raw devices - in other words, no filesystem!

  • (cs) in reply to java.lang.Chris;

    That puts another piece in the puzzle. SpectateSwamp MUST be either Dutch or Italian.

    Perhaps this is the foundation for SSDS? Or maybe they were swampies and wanted to emulate the "index-less search"TM.

  • (cs) in reply to java.lang.Chris;
    java.lang.Chris;:
    Sybase (version 12 at least, not sure about 15) still recommends that you do essentially this by putting your data on raw devices - in other words, no filesystem!
    Pretty much any industry-grade DBMS will recommend that you do that, since it cuts out a layer that costs performance and offers no benefits for the DBMS or its user.
  • Anon (unregistered)
    I'm working on VB6 code written by a Dutch speaker and maintained by an Italian, with variables and comments in both languages. And no indentation whatsoever.

    When I read that on the front page, I thought it could probably stop right there.

  • (cs) in reply to brazzy
    brazzy:
    java.lang.Chris;:
    Sybase (version 12 at least, not sure about 15) still recommends that you do essentially this by putting your data on raw devices - in other words, no filesystem!
    Pretty much any industry-grade DBMS will recommend that you do that, since it cuts out a layer that costs performance and offers no benefits for the DBMS or its user.

    Using raw devices may eke out the last bit of performance, but it usually makes the sysadmin hate the DBA. As for Sybase, the inability to dynamically resize tables may make raw devices less of a headfuck, but I'm not aware of any new projects that are using it as the RDBMS. Basically, Sybase are fucked.

  • honk (unregistered) in reply to java.lang.Chris;
    java.lang.Chris;:
    Sybase (version 12 at least, not sure about 15) still recommends that you do essentially this by putting your data on raw devices - in other words, no filesystem!
    Oracle does this too (it's called ASM). But you know this, right?
  • Andrew (unregistered) in reply to akatherder
    akatherder:
    "Rather than use a database, all non-static information is crammed in thousands of text files scattered across subfolders of subfolders"

    Accessing the file system directly is clearly faster than creating a DB connection and THEN looking for your data. A database is nothing more than a glorified set of files!

    No, SQL database engines are not just "...a glorified set of files!". They organize data in relational tables. They provide logical search abilities: SELECT all relations WHERE these conditions are true.

    Sure, a database is (usually) stored in flat files. Maybe the files don't need SQL, but they must be organized somehow! Look-up the "Berkley DB" flat file database for comparison.

    Go back and read "Rutherford, Price, Atkinson, Strickland, and Associates" from last week. They used the database like "...a glorified set of files!", which was the WTF!

    CAPTCHA: ludus - I think this this is "thanks" in Latvian?!?

  • (cs) in reply to akatherder
    akatherder:
    "Rather than use a database, all non-static information is crammed in thousands of text files scattered across subfolders of subfolders"

    Accessing the file system directly is clearly faster than creating a DB connection and THEN looking for your data. A database is nothing more than a glorified set of files!

    In principle, it should be faster to access one big (database) file than a big number of small fiiles (see the time it takes to copy). But as usual: size matters, also.

  • SomeCoder (unregistered) in reply to Andrew
    Andrew:
    akatherder:
    "Rather than use a database, all non-static information is crammed in thousands of text files scattered across subfolders of subfolders"

    Accessing the file system directly is clearly faster than creating a DB connection and THEN looking for your data. A database is nothing more than a glorified set of files!

    No, SQL database engines are not just "...a glorified set of files!". They organize data in relational tables. They provide logical search abilities: SELECT all relations WHERE these conditions are true.

    Sure, a database is (usually) stored in flat files. Maybe the files don't need SQL, but they must be organized somehow! Look-up the "Berkley DB" flat file database for comparison.

    Go back and read "Rutherford, Price, Atkinson, Strickland, and Associates" from last week. They used the database like "...a glorified set of files!", which was the WTF!

    CAPTCHA: ludus - I think this this is "thanks" in Latvian?!?

    Sarcasm detector broken? :)

  • Joe (unregistered)

    So then how do you pass data from one form to another? Assuming each form is open.

    I'm guessing in the current iteration of VBA you would declare those variables as global and access them using the Forms collection? But the Forms collection lets you drill down to the forms' controls which is why people use hidden text boxes (ug!). You can't access global variables from one form to another can you?

    When a form opens another form, it can give it a free-form string of text as it's OpenArgs, but that's only for when it's opening the 2nd form. Once they're both open, how do you access each other's variables?

    Sorry, don't do much VBA anymore, but I'm curious how MS finally solved this issue.

  • (cs)

    Hey, why are you posting my codez?

    atkretsch:
    (...) that varname though reminds me of this guy i worked with in college, we both had some wacky naming conventions(...)
    Well, not cryptic, but if we were clueless for a variable name, it would be jeMoeder or something. :P
  • sweavo (unregistered)

    it's for EFFICIENCY

  • (cs) in reply to Joe
    Joe:
    So then how do you pass data from one form to another? Assuming each form is open.

    I'm guessing in the current iteration of VBA you would declare those variables as global and access them using the Forms collection? But the Forms collection lets you drill down to the forms' controls which is why people use hidden text boxes (ug!). You can't access global variables from one form to another can you?

    When a form opens another form, it can give it a free-form string of text as it's OpenArgs, but that's only for when it's opening the 2nd form. Once they're both open, how do you access each other's variables?

    Sorry, don't do much VBA anymore, but I'm curious how MS finally solved this issue.

    In the first place we are talking about VB not VBA. The difference is relatively small, just look at VBA like a ersion of VB that has special functions according to the program it has been written for (mostly MS Office). And since it is a programming language (yes, really!) there is such a thing that is called a Global variable which is accessible all the times even when there is no form present at all. Using hidden controls is mostly made on web forms which might have VBScript. But sometuimes it can be useful to read the content of a (non-hidden) control. Nothing speaks against that.

  • Joe (unregistered) in reply to Cloak
    Cloak:
    Joe:
    So then how do you pass data from one form to another? Assuming each form is open.

    I'm guessing in the current iteration of VBA you would declare those variables as global and access them using the Forms collection? But the Forms collection lets you drill down to the forms' controls which is why people use hidden text boxes (ug!). You can't access global variables from one form to another can you?

    When a form opens another form, it can give it a free-form string of text as it's OpenArgs, but that's only for when it's opening the 2nd form. Once they're both open, how do you access each other's variables?

    Sorry, don't do much VBA anymore, but I'm curious how MS finally solved this issue.

    In the first place we are talking about VB not VBA. The difference is relatively small, just look at VBA like a ersion of VB that has special functions according to the program it has been written for (mostly MS Office). And since it is a programming language (yes, really!) there is such a thing that is called a Global variable which is accessible all the times even when there is no form present at all. Using hidden controls is mostly made on web forms which might have VBScript. But sometuimes it can be useful to read the content of a (non-hidden) control. Nothing speaks against that.

    I oftentimes used to access data in visible controls in other forms. It might be a date the a user selected from a combo box, or a text box a user entered data into, etc. You're right. There are valid reasons for accessing data this way. I think one way is: [Forms]![frmAddress]![txtStreet] is an example of getting the text box control's value. However, that's still using the Forms collection.

    In other languages you can create public variables or (in Java at least) you can create getX() and setX() functions for accessing data. Not sure how well this is used in VBA. I don't see why the same thing couldn't be implemented in a VBA form in Access for example.

  • rd (unregistered) in reply to Kevin B.

    No, because YokPwndJim!

  • Stiggy (unregistered) in reply to Joe
    Joe:
    So then how do you pass data from one form to another? Assuming each form is open.

    I'm guessing in the current iteration of VBA you would declare those variables as global and access them using the Forms collection? But the Forms collection lets you drill down to the forms' controls which is why people use hidden text boxes (ug!). You can't access global variables from one form to another can you?

    When a form opens another form, it can give it a free-form string of text as it's OpenArgs, but that's only for when it's opening the 2nd form. Once they're both open, how do you access each other's variables?

    Sorry, don't do much VBA anymore, but I'm curious how MS finally solved this issue.

    Forms are just classes that happen to have a graphics surface. You can extend them with property get/let/set, methods and events as you see fit. The only slight complication (in Access at least) is getting a reliable reference to the form instance in the first place, since Access likes to handle its forms collection for you (badly).

  • Joe (unregistered) in reply to Stiggy
    Stiggy:
    Joe:
    So then how do you pass data from one form to another? Assuming each form is open.

    I'm guessing in the current iteration of VBA you would declare those variables as global and access them using the Forms collection? But the Forms collection lets you drill down to the forms' controls which is why people use hidden text boxes (ug!). You can't access global variables from one form to another can you?

    When a form opens another form, it can give it a free-form string of text as it's OpenArgs, but that's only for when it's opening the 2nd form. Once they're both open, how do you access each other's variables?

    Sorry, don't do much VBA anymore, but I'm curious how MS finally solved this issue.

    Forms are just classes that happen to have a graphics surface. You can extend them with property get/let/set, methods and events as you see fit. The only slight complication (in Access at least) is getting a reliable reference to the form instance in the first place, since Access likes to handle its forms collection for you (badly).

    Thanks. I'm familiar with the fact that forms are just classes. As such they have public/private methods and variables. And you should be able to instantiate each one as often as you'd like (so long as it's not static) and access each instance individually. However, in Access at least, you can't have multiple instances of any given form which can be a pain in the rare cases where you'd like to just that. Fortunately, that's almost never a good way to solve a given problem anyways.

    It's just that MS likes to fudge with convention and break with it for the sake of simplification for easier development in VBA. The COM is another example of this (sort of).

  • (cs) in reply to Joe
    Joe:
    Stiggy:
    Joe:
    So then how do you pass data from one form to another? Assuming each form is open.

    I'm guessing in the current iteration of VBA you would declare those variables as global and access them using the Forms collection? But the Forms collection lets you drill down to the forms' controls which is why people use hidden text boxes (ug!). You can't access global variables from one form to another can you?

    When a form opens another form, it can give it a free-form string of text as it's OpenArgs, but that's only for when it's opening the 2nd form. Once they're both open, how do you access each other's variables?

    Sorry, don't do much VBA anymore, but I'm curious how MS finally solved this issue.

    Forms are just classes that happen to have a graphics surface. You can extend them with property get/let/set, methods and events as you see fit. The only slight complication (in Access at least) is getting a reliable reference to the form instance in the first place, since Access likes to handle its forms collection for you (badly).

    Thanks. I'm familiar with the fact that forms are just classes. As such they have public/private methods and variables. And you should be able to instantiate each one as often as you'd like (so long as it's not static) and access each instance individually. However, in Access at least, you can't have multiple instances of any given form which can be a pain in the rare cases where you'd like to just that. Fortunately, that's almost never a good way to solve a given problem anyways.

    It's just that MS likes to fudge with convention and break with it for the sake of simplification for easier development in VBA. The COM is another example of this (sort of).

    "And you should be able to instantiate each one as often as you'd like"

    Dim f as MyForm Dim I as Long

    For I = 1 To 100 Set f = New MyForm Next

    Does this help?

  • (cs) in reply to Andrew
    Andrew:
    akatherder:
    "Rather than use a database, all non-static information is crammed in thousands of text files scattered across subfolders of subfolders"

    Accessing the file system directly is clearly faster than creating a DB connection and THEN looking for your data. A database is nothing more than a glorified set of files!

    No, SQL database engines are not just "...a glorified set of files!". They organize data in relational tables. They provide logical search abilities: SELECT all relations WHERE these conditions are true.

    Sure, a database is (usually) stored in flat files. Maybe the files don't need SQL, but they must be organized somehow! Look-up the "Berkley DB" flat file database for comparison.

    Go back and read "Rutherford, Price, Atkinson, Strickland, and Associates" from last week. They used the database like "...a glorified set of files!", which was the WTF!

    I understand why you feel that way. You have done nothing wrong. You were just taught a lie. Filesystems are the answer, by explicit design. I am right and the entire industry is wrong. Secure data access via the filesystem is the future of all databasifying.

  • Barf 4 Eva (unregistered) in reply to Andrew
    Andrew:
    akatherder:
    "Rather than use a database, all non-static information is crammed in thousands of text files scattered across subfolders of subfolders"

    Accessing the file system directly is clearly faster than creating a DB connection and THEN looking for your data. A database is nothing more than a glorified set of files!

    No, SQL database engines are not just "...a glorified set of files!". They organize data in relational tables. They provide logical search abilities: SELECT all relations WHERE these conditions are true.

    Sure, a database is (usually) stored in flat files. Maybe the files don't need SQL, but they must be organized somehow! Look-up the "Berkley DB" flat file database for comparison.

    Go back and read "Rutherford, Price, Atkinson, Strickland, and Associates" from last week. They used the database like "...a glorified set of files!", which was the WTF!

    CAPTCHA: ludus - I think this this is "thanks" in Latvian?!?

    ummm... I think he was being facetious. :P

  • (cs) in reply to honk
    honk:
    java.lang.Chris;:
    Sybase (version 12 at least, not sure about 15) still recommends that you do essentially this by putting your data on raw devices - in other words, no filesystem!
    Oracle does this too (it's called ASM). But you know this, right?

    Yes, once upon a time it was the one true way, as accessing the raw device was potentially faster than having files on a filesystem. I say potentially, because the OS filesystem code often turned out to be better written, better tested and better benchmarked than the code in the RDBMS that accessed the raw devices. When you add on the nightmare of dealing with disk problems using the either inadequate or non-existent vendor tools that came with the RDBMS, and it probably explains why I haven't met a DBA who advocates using raw devices in a long time.

  • Barf 4 Eva (unregistered) in reply to Barf 4 Eva

    doh, and almost forgot... I think Codd might of stated the MOST important feature of a database is how it stores data in relations, not necessarily just the relationships between them. Also, that each row (set) is defined as a tuple of atomic attributes. Establishing such rules resolves a multitude of issues that plagued the earlier non relational db systems. Don't quote me, cause I'm sure I'm missing something here... :P However, feel free to correct me.

  • david (unregistered) in reply to Publius
    Publius:
    To pass information between forms, the concept of scope eludes them. They make a hidden TextBox and stuff information in it for other forms to read.

    That is, they make a shared object and use it for shared data.

    Of course, looks broken to you if your one true language doesn't have a native object of that type - you automatically think of the effort, confusion, and overhead of creating a custom object of that type.

  • uberhacker (unregistered)

    I am surprised you actually took the time to clean this mess up. Anybody else would just have slammed the door and leave these madsters alone with their pile of pooh.

  • Monday (unregistered) in reply to akatherder

    Godverdomde Nederlanders, kunnen ze niks doen?!?

  • Stefan W. (unregistered) in reply to Kevin B.
    Kevin B.:
    And for those interested... 'IkOwnJou' translates to 'I Own You', without spaces ofcourse.

    Yeah, i wonder if he's still as full of himself when he reads this article...

    Well - or maybe "I know you" or just "Icon view".

  • GuitaristX (unregistered) in reply to Publius
    Publius:
    ... The reason there are 70 "Exit Function" statements: they use it instead of "ElseIf" and "Else" (despite knowing how to use these elsewhere in the code).

    If True Then DoThis Exit Function End If If False Then DoThat Exit Function End If If ... [snip]

    Part of the issue here is VB6's horrid syntax. You don't return values from Functions, you set the Function, as a variable, to the value you want to return, a la:

    Public Function Foo() As String
        Foo = "Hello World"
    End Function
    
    If you want to return out of a conditional or a loop, it requires two lines: one to set the "return" value, and another to bail out of the function. Maintaining VB6 apps in general tends to be painful for reasons like this; the syntax is conducive to poor maintainability.
  • Josh (unregistered) in reply to Publius

    If True Then DoThis Exit Function End If If False Then DoThat Exit Function End If If FILENOTFOUND Then UhOh Exit Function End If

  • SomeCoder (unregistered) in reply to GuitaristX
    GuitaristX:
    Publius:
    ... The reason there are 70 "Exit Function" statements: they use it instead of "ElseIf" and "Else" (despite knowing how to use these elsewhere in the code).

    If True Then DoThis Exit Function End If If False Then DoThat Exit Function End If If ... [snip]

    Part of the issue here is VB6's horrid syntax. You don't return values from Functions, you set the Function, as a variable, to the value you want to return, a la:

    Public Function Foo() As String
        Foo = "Hello World"
    End Function
    
    If you want to return out of a conditional or a loop, it requires two lines: one to set the "return" value, and another to bail out of the function. Maintaining VB6 apps in general tends to be painful for reasons like this; the syntax is conducive to poor maintainability.

    Gah! I had totally blocked this from my mind and you just reminded me of it! Thanks a lot!! :)

    Seriously though, this post is dead on. Multiple return points (whether they are good or not can be debated endlessly) is nasty to do in VB6.

  • (cs) in reply to SomeCoder
    SomeCoder:
    Seriously though, this post is dead on. Multiple return points (whether they are good or not can be debated endlessly) is nasty to do in VB6.

    It doesn't -need- multiple return points though. They're using "Exit Function" like an unconditional jump to the end of the function, because they don't know how to use "ElseIf" and "Else", or to create some kind of weird backwards logic. It's basically like this:

    [code] Public Function GetInfo()

    If Not WantsToGetInfo Then Exit Function End If If Not FileExists("filename") Then Exit Function End If If Not FileOpen("filename").Successful Then Exit Function End If If Readline = "dothis" Then DoThis Exit Function End If If Readline = "dothat" Then DoThat Exit Function End If ErrorMessage

    End Function

  • Buffer Overflow (unregistered)

    Heh, am I the only one who thought they were looking at buffer overflow exploit code when they saw a string filled with 'a's and a variable named ikownjou?

    And is k-own like k-cool (i.e. really old & lame)? Because it sure looks that way...

  • Didiman (unregistered) in reply to akatherder

    And writing code directly in binaryformat is clearly faster than using all this OO crap, right ?

  • zzp (unregistered)

    open mouths tries to speak I...I would understand it if you committed suicide.

    Sorry.

    Couldn't come up with something positive to say.

  • Dutch Uncle (unregistered)

    Ha ha, the joke is on the company. A company that would hire Dutch and Italian programmers has no future.

    By the way everyone : That captcha thing in your posts is retarded

Leave a comment on “ikownjou”

Log In or post as a guest

Replying to comment #174944:

« Return to Article