• NULLPTR (unregistered)

    #define nullptr 0xDEADBEEF
    #define NULL 1
    #define false true

  • (nodebb)

    First few paragraphs made me think somebody has leaked my code.

  • GuestMike (unregistered)

    I started programming in BASIC (Sinclair version), but at the school I learnt Pascal, C and 8086 assembler at the same time in different classes. Learning these language at the same time was useful to have clear what pointer are, and the interesting quirks of far and near pointers and so on.

    Learning procedural laguages I concour makes a bit difficult to switch to OO and functional ones...

  • Peter Wolff (unregistered)

    Generally, any comment that's more than, like, 20 lines long probably is a WTF

  • (nodebb)

    The basic thesis here, of people "damaged" by some language, or maybe even a langugae, is somewhat inflammatory, at least in terms of the way it's expressed, but it can occur between any pair of languages.

    Consider the "true" mark of a Real Programmer: he can write Fortran in any language. I'm only slightly joking here. I previously worked in a large organisation that had millions of lines of legacy Fortran code, and a substantial quantity of C code written in "Real Programmer" mode, with Fortranic string manipulations (space-padded fixed-size arrays without NUL terminators) in C, for example.

  • RLB (unregistered) in reply to Steve_The_Cynic

    The basic thesis here, of people "damaged" by some language, or maybe even a langugae, is somewhat inflammatory, at least in terms of the way it's expressed, but it can occur between any pair of languages.

    Yup. I've seen enough C code that is horribly inefficient, quite obviously because the programmer started his career in Python or some other hand-holding language with opaque containers, and never learned to think about what the machine actually does when you ask it to "fill this basket with these objects".

  • MiserableOldGit (unregistered) in reply to Steve_The_Cynic
    The basic thesis here, of people "damaged" by some language, or maybe even a langugae, is somewhat inflammatory, at least in terms of the way it's expressed, but it can occur between any pair of languages.

    Yep, agree, or perhaps a step further ... a certain mentality that learns how to solve a few business problems with "some code" and then just spends the rest of their career tweaking and cutting and pasting the same few dozen lines no matter what language or problem they are given. It usually never occurs to them (as their procedures creep up to thousands of lines) that others have seen the same problems and their are better solutions. On the flip side, I've seen coders like that introduced to those better techniques (most recently a semi-competent VBA/SQL person sent on a reg-ex course) and then churn out stuff in such a cack-handed way that they (and their end users) would have been better off before.

  • MiserableOldGit (unregistered)

    I once inherited a program written in VB 4 written by a C fanatic (who made no secret of his hatred of VB). In spite of hating the language he didn't seem to know what it didn't do.

    It looked to me like he'd gone ahead and written several thousand lines of code using concepts such as overloading and pointers and references before making any attempt to debug or run the thing. He then had gone through stapling workarounds all over the place to simulate the behaviour around his fundamentally inappropriate code. It was beyond unreadable.

    And this was a guy who could not be accused of lacking intelligence or programming proficiency, he'd demonstrated far more of both in getting his program to work (and it did, it was reasonably successful, commercially). Did make me wonder why the idiot development manager (who at a push could do a few lines of average C, and that's it) kept hiring solid C/C++ guys and shoving them in front of VB until they screamed and left.

  • George (unregistered)

    "Because if you come from one of those traumatized backgrounds, you might think output parameters is the most natural way to pass data around."

    Wow, when when PL/SQL get functions?

  • George (unregistered) in reply to George

    Umm, "when will"

  • Brian (unregistered)

    Yep, some of the worst code I've seen is very obviously C code shoehorned into C++ classes, as if the coder (I hesitate to use the word developer here) just really didn't get it that C++ may look like C, but OOP style and best-practices make it an entirely different beast.

  • (nodebb)

    OMG -- This explains my ex-boss' COBOLized JavaScript!

  • MiserableOldGit (unregistered) in reply to George
    Wow, when when PL/SQL get functions?

    Since version 7 , mid 90s. Although if they are anything like the ones in T-SQL you need to know what you are doing or you can create some real headaches for yourself.

    Having worked with T-SQL, PL-SQL and VB rather a lot over the years, yes, you can end up using output parameters for things but it never really felt "natural", just a bit better than dealing with bucket loads of weirdly named globals.

  • (nodebb)

    out parameters before in parameters in a function declaration is probably not a good sign either.

  • Andrew (unregistered) in reply to RLB

    Yes, it does seem that this critique works in both directions. Whatever language one learns first undoubtedly influences the thinking. If one does not strive for learning the way in the new or other language, it is to his peril. (figuratively of course, LOL)

    On a different note, I wonder if the Remy's critique of our parameter extends to Microsoft's libraries. This is no challenge. I wonder because, the first time I looked through them looking for solutions to code I was writing, I was struck by the enormous use of them.

  • (nodebb) in reply to MiserableOldGit

    Having worked with T-SQL, PL-SQL and VB rather a lot over the years, yes, you can end up using output parameters for things but it never really felt "natural", just a bit better than dealing with bucket loads of weirdly named globals.

    Those aren't the only two choices. Rational people would return a class or structure for a traditional function. Another modern option for the case of library code that modifies local data would be to implement it as an extension method.

  • (nodebb) in reply to Steve_The_Cynic

    Yeah, this damaged thesis is frankly nonsense. Maybe it's intended as a joke?

    My experience after coming from working in Python for 10 years to doing some C++ on Windows for a personal project was that while initially I found the out parameter concept strange I also quickly realised that it makes it much easier to reason about memory allocation, etc because it forces you to be explicit.

  • MiserableOldGit (unregistered) in reply to Jaime

    Oh yes although you can't always do that .... I seem to recall calling API functions (particularly the windows ones!) would force you into some very hookey coding. Trying to remember other reasons I might have been using output parameters (or the other eye-watering one, using paramarray) ... not succeeding. I did, but not often.

    Probably Remy's criticism stems from VB/VBA having parameters passed by reference by default. I never liked that, but then I don't recall anyone I worked with using it that way, I did see some guys get into a habit of copying parameters to local variables because they didn't realise there was a byval keyword. A WTF, but a well intentioned one.

  • Technical programmer (unregistered)

    The long procedure is somewhat indicative of BASIC -- the varieties without procedures. But the combination of unbroken procedures with terminating exceptions seems to suggest ASP classic -- Active Server Pages.

  • Some Ed (unregistered)

    I'm reminded of my last coworker whose projects mysteriously all devolved into chaos, for no reason management could decipher. Or, at least, no reason that management could decipher, until one day management happened to come across a block of their code.

    Now, just to be clear, our management was not, is not, in the habit of looking at our code. In fact, they go to great length to not look at our code. But, the thing is, when they received an email, which was entirely comprised of the gobbelty gook that this particular programmer wrote in, it was kind of thrust at them.

    Of course, a single email is easy to delete, but in this particular case, their mistake was a bit more careful than to let management get away that easy, and so management got about 5,000 emails like this. So they looked at one. And then sent him to me, because I was the guy who fixed code like that.

    I suggested a half dozen changes. Not because there weren't scores of things to fix, but because one makes incremental progress. They fixed a couple. I suggested a half dozen other changes. They fixed one. I suggested a dozen other changes. They asked if we could not. I said it was between them and management.

    Roughly one standard probationary period after his oops, he suddenly left to pursue other opportunities with no notice. Funny that.

  • 🤷 (unregistered)

    I once inherited C# code from someone who clearly learned programming in the C/C++ days, and didn't seem to want to learn new things. He constantly wrote functions that are already available in the framework. Like "IndexOf" and "LastIndexOf". He also implemented his own Substring method.

    What he clearly didn't learn (even though I am 100% sure C/C++ offers it) was how to break out of for-loops once a condition is satisfied. Instead, he'd much rather ran through millions of DataRows, even though the value he was looking for has already been found in row 10.

    I mean, the programs wheren't that huge of a WTF. They had a few quirks here and there and there where still chances for huge optimizations (ie, I trimmed down the time a monthly report ran from 4 hours to 30 minutes, because I actually knew how to use WHERE clauses in SQL, AND I knew how to use "break" statements). The code was maintainable and the programs ran pretty stable. But I am glad I did my own research on "how to do things" and "best practices" and didn't blindly follow the example set by the senior developer. It was my first job out of uni, after all.

  • (nodebb) in reply to MiserableOldGit

    I seem to recall calling API functions (particularly the windows ones!) would force you into some very hookey coding.

    This is a special case that gets a pass. Operating System API calls are designed to be called by many languages. They make absolutely no assumptions about memory handling. For example, if they need to return a string, they demand that you give them the buffer and you tell them how big the buffer is. Buffers are always passed by reference.

    The proper way to handle this is to create a small wrapper function that works well with your language and doesn't have all of the weird by-ref parameters that make it cumbersome to call. So, this shouldn't make your actual code look hokey, it should force you to create an interface layer than encapsulates all the hokeyness in a place completely separate from the usage.

  • (nodebb)

    I learned programming with APL. 40 years later I'm still baffled by the concept of iterating through arrays.

    It's like learning to drive on a BMW, then spending your life driving Ladas.

  • MiserableOldGit (unregistered) in reply to Jaime
    The proper way to handle this is to create a small wrapper function that works well with your language and doesn't have all of the weird by-ref parameters that make it cumbersome to call. So, this shouldn't make your actual code look hokey, it should force you to create an interface layer than encapsulates all the hokeyness in a place completely separate from the usage.

    Haha, yes indeed, and I think if you don't do that I don't imagine you'll ever get the damned thing working, hokey or not. Imagine trying to do message hooking in line in the code? I think you'd go insane.

    But this was an exercise in trying to work out why a VB coder would be in the habit of routinely using out parameters. So perhaps it's more that a novice one might look at the structure of those API calls and consider them good examples of best practise or something. That was the only example I could think of and you've demonstrated it's a poor one. I think I said somewhere already, I raised the point because I never met a VB coder who did make anything more than occasional use of out parameters, even though it was default behaviour. So it's back to Remy!

  • jmb (unregistered)

    It's code like this that makes code reviews essential. The code does not pass review until it's been refactored.

    I'm an old COBOL programmer (emphasize old). I started with VSAM, CICS, etc. I moved to VB6 in '98. .NET (C#) in 2005. One can move to modern technologies coming from a procedural background.

  • (nodebb) in reply to MiserableOldGit

    I raised the point because I never met a VB coder who did make anything more than occasional use of out parameters, even though it was default behaviour.

    ByRef is the default for backwards compatibility purposes - and that's the major reason for VB.Net's existence in the first place. I don't think anyone with any sense makes more than occasional use of out parameters, so it shouldn't be that surprising that VB coders behave the same.

    BTW, the "backwards compatibility" mentioned above is source-level, meaning that Microsoft wanted to go so far as to make sure that existing cut-and-pasted code worked as much as possible. VB was also used in non-compiled scenarios like ASP pages - which have a pretty easy upgrade path to ASP.Net. So, maintaining the same defaults in VB.Net was very important to their customer base.

  • MiserableOldGit (unregistered) in reply to Jaime

    Yeah get that, I'm a legacy coder primarily and rarely get to the heady heights of .net. I didn't realise (and I'm not sure I believe you) that that is why VB.net exists, although from my earlier encounters with that language I'll grant you that's one of the saner rationales. I date from the early days of VB and, for all it's crimes, that ByRef default thing was abusing scope such that anyone who knew how to code should have known better.

    We are still dealing with a very silent Remy, unless you are one of his troll accounts? Nah, yo rite beter.

  • K (unregistered) in reply to Brian

    Whether the criticism is fully valid depends a bit on the project history. Old projects may actually have started out as C projects and later slowly started migrating.

  • Trillian (unregistered) in reply to MiserableOldGit

    Marvin ?

  • Neveralull (unregistered) in reply to 🤷

    I ran into opposite - C# programmers who wrote C++ for the first time, and it looked suspiciously like C#. Example: using “this” when it is implicit, and not required.

  • Neveralull (unregistered)

    Worst example I’ve seen is when I attended a meeting of JOVIAL developers who were about to write C++ code for the first time, and they developed their own set of coding standards that prohibited the use of any capability that JOVIAL did not have. Example: no i++, you had to code i = i + 1; No overloading. And absolutely no mention of the “P” word ( Polymorphism).

  • (nodebb) in reply to Neveralull

    Example: no i++, you had to code i = i + 1;

    Both ESLint and JSLint have this as a built in rule. Douglas Crockford of JSLint gives his rationale as:

    The ++ increment and -- decrement operators have been known to contribute to bad code by encouraging excessive trickiness. They are second only to faulty architecture in enabling to viruses and other security menaces.

    Anyone who agrees with Crockford might actually not be as dumb as you think they are (but, no guarantees).

  • (nodebb) in reply to Neveralull

    I ran into opposite - C# programmers who wrote C++ for the first time, and it looked suspiciously like C#. Example: using “this” when it is implicit, and not required.

    Yeah, I was doing this for a while myself until I decided it looked "weird" and switched to not using this

  • WTFguy (unregistered)

    Parameters of the "out" flavor come from a simple need in a bygone era. Before those new-fangled "objects" and "classes" were invented, having a mechanism for a procedure to return a 2+length tuple of primitive types rather than just zero or one primitive type was enormously valuable.

    In modern parlance, the procedure return var, plus all the out vars collectively constitute a logical n-tuple or struct of results.

    Since the only tool they had back in the day was the procedure prototype and formal parameter list, somebody initially had the bright idea to pass in variables with dummy values which the procedure would fill with results. From the POV of the caller they were garbage before the call and read-only after. From the POV of the callee they were write-only.

    Soon enough language support was added so the caller still had to declare their logical tuple's member vars, but no longer had to uselessly initialize them before the call. Thus was the "out" parameter born.

    Look at the bright side: it was a better solution than the everything's-a-global which preceded them.

    Today they're an anachronism, at least in an OO environment. Of course we still see them in things like OS APIs both for historical reasons and because at that level (AFAIK) we're close enough to the metal that OO isn't really used. Yet.

  • MiserableOldGit (unregistered)

    Well yes, that's how I'd have summed it up, if I was a bit more eloquent and had a better grasp of coding history. But I'm still left wondering why Remy is suggesting this is some VB/COBOL/SQL coder's disease when, apart from VB since early on having shipped with this strange default of parameters passing ByRef, I never saw any (sane) coder exploiting that except when it was necessary/they'd painted themselves into a corner/were being a bit lazy. And that's even with lots of spaghetti code, global variables and hidden-forms-full-of-hidden-fields-of-system-data (vomit).

  • Barf4Eva (unregistered)

    Ohhhhh! You didn't hide the details well enough, I don't think... because this had a smell to it from one of the teams that works at our company on one of our many flagship clusterfucks. Let's see what I find. Thanks for making my evening entertaining!

  • asr (unregistered)

    "but to management's eyes, that's just a judgement call. There must be some other reason." I have had my share of terrible developers. Generally management have a sentence for it when you say something "no two developers write same code, you need to adapt." Telling management is seldom a good idea, just point to the commit which caused the problem or which needs to be rewritten when change is required. Mangers usually have no idea how important it is to write good maintainable code. They only know how to complain later.

  • (nodebb) in reply to Neveralull

    Although to be fair you do sometimes even require this-> in C++.

  • MiserableOldGit (unregistered) in reply to Trillian

    The diodes down my left hand side still haven't been replaced.

    I can't believe I had to click a box saying "I'm not a robot" in order to post that.

Leave a comment on “An Accident”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article