• David Martensson (unregistered) in reply to Bob
    Bob:
    I don't get the COBOL reference. COBOL tends toward verbosity. Unless you're using the indicators...

    I would have thought that regular WTF readers would have grown out of the "language x is bad" mentality. There are few bad languages but many bad programmers. There's little correlation between the two. Apart from PHP.

    Cobol is, at least last I looked at it, very iterative and very verbose.

    The reference is not that cobol is a bad language but rather that it is more distant from modern OOL than normal English.

    In that respect a Cobol programmer might keep on using coding styles that you have to use in Cobol that are unnecessary cumbersome for other language.

    A new programmer do not have any old fashion styles.

  • exquisitus (unregistered) in reply to Bob

    I do not get the "regular WTF readers" reference. If you are a "WTF reader", how can you be regular?

  • (cs) in reply to exquisitus
    exquisitus:
    I do not get the "regular WTF readers" reference. If you are a "WTF reader", how can you be regular?

    Regular mean people who sign on daily like Cockthorpe and PedanticCurdleman.

  • (cs)

    I am looking at the code. It is obvious what the logic is:

    If the date is in the first half of the year, then the result is the current year, otherwise it is year + 1.

    The fact the code works is a WTF of the language, albeit that VB supports Excel where you type in text and it gets interpreted into dates or numbers. Now I can sort-of understand that in Excel but in a proper language I would expect type safety so a string doesn't suddenly convert to a number or a date.

    I don't mind variant types so you can do:

    x = 3; x = "foo";

    So first x was an int, then it becomes a string. Casts are also ok so

    x = "06/25/2010"; (with some locale setting that parses as American style)

    x = date(x) + 1;

    if that makes sense (although wouldn't it add a single day, not a year).

    however simply x = "06/25/2010"; x = x - 1;

    makes no sense, you cannot subtract 1 from a string. (Hey, in C or C++ that will compile assuming x is const char *... And x will be an invalid pointer after the subtraction)

    There is no real explanation to the unused variables that begin with 'n'

    Using n or i as a loop counter is not a WTF. Everybody knows that 'i' means array index and 'n' is often used as the pre-cached number of iterations you wish to do, so you don't have to do container.size() every iteration when it doesn't change.

    The algorithm used to implement is very WTF. There is no need to use a loop to calculate this. Just work out what the current year and current month are, and if the month is greater than 6, i.e. 7 or higher, add one to the year. That is the primary WTF, and it is difficult to know what obsessed this programmer to do anything else. There's probably a correct COBOL way of doing it too, and it isn't the way it's done in the code here.

    On the subject of PHP, my own personal feeling when I looked at the language and learnt how to use it is that it has its limitations, and ideally should be used only in small measures, as a layer between the main engine of your application and the end user.

    Validating user input? yes. Passing queries through to MySQL? - yes. As a main logic engine? No.

    Using programming languages out of their proper domain is a WTF.

    For me, the ideal model would be:

    • primary development engine written in C++.
    • Libraries written with C interface for integration purpose
    • Scripting language front-end that can interact with C interfaces. A lot of scripting languages can do that.

    For that you actually need to build your team properly, with both types of developers and good communication. Not necessarily one-fits-all unless it's a very small development team.

  • (cs) in reply to Bob
    Bob:
    I don't get the COBOL reference. COBOL tends toward verbosity. Unless you're using the indicators...

    I would have thought that regular WTF readers would have grown out of the "language x is bad" mentality. There are few bad languages but many bad programmers. There's little correlation between the two. Apart from PHP.

    Yeah but attitude when hiring is always:

    "have you used such and such... what experience do you hav with such and such..." and some test on the language syntax...

    Deciding between

    1. Very good programmer who hasn't used the language
    2. Mediocre programmer who has

    and no other option they will always choose the latter. After all the can "hit the ground running..."

    In the short term, (1) has a bit of a learning curve but in the long term (1) will be your better bet. If it's a short-term contract I can understand although even then I'd question your decision.

  • Jay (unregistered) in reply to Soviut
    Soviut:
    foo2:
    VB happily 'fixes' the types for you, and as expected is not a good idea. It will usually compile, and often fail when run.

    Isn't there a strict mode you can set that requires variables be explicitly typed?

    EDIT: Ah yes, Option Explicit is what it was called. It's been a long long while.

    Option Explicit forces you to define the variables; since VB creates the variables for you a typo meant you wound up with two variables (of Variant type) with similar names. There's an IDE option that automatically inserts that when you create a new module.

    That got added after using symbols to define the variables (A$, B& and all that) was deprecated.

    That doesn't stop the auto type casting stuff like "1" + 1

    A real WTF was the DEF stuff, that let you assign variable types based on their first letter, so "DefInt I" means all variables starting with I are integers. Our friend here could have added:

    DefStr S DefInt N DefDat D

    ...and skipped the Dim statements. What a time saver! And job security!

    Those are global, so much fun to be had; eg Fortran folk can have "DefInt I-K". I'd forgotten about that, and thankfully so has everyone else.

  • foo2 (unregistered) in reply to Cbuttius
    Cbuttius:
    Casts are also ok so

    x = "06/25/2010"; (with some locale setting that parses as American style

    No, auto casting is bad, leading to many WTF's. VB has DateValue() for that.

    Cbuttius:
    x = date(x) + 1;

    if that makes sense (although wouldn't it add a single day, not a year).

    VB does dates like everyone else, in its case "days since 1900" so that code adds a day. VB does have a DateAdd() function that should be used instead (not that many do).

    Cbuttius:
    however simply x = "06/25/2010"; x = x - 1;

    makes no sense, you cannot subtract 1 from a string.

    It makes sense when VB automatically casts the string literal for you (assuming X is defined as a Date).

    I'm not sure why you're unhappy with this, you seemed happy with the first two bits.

  • (cs) in reply to facilisis
    facilisis:
    Jim:
    RichP:
    Um no, you use i, j, k and sometimes m as generic counters.

    (cue religious war akin to camelCase versus name_with_underscore)

    in CS101 they taught me to use meaningful names. I have: counter, loopCounter, iter, count and a plethora of others... Of course, to avoid a massive increase in typing, I still use i and then find-replace all i's with count.

    on a totally unrelated note, I found some serious issues in a program I inherited the other day. I don't even know how it compiled for my predecessor:

    publcountc countnt macountn(vocountd)
    {
      for(count=0; count<1000; count++)
      {
        countf(count%5 == 0)
        {
          System.out.prcountntln(count + "counts Dcountvcountscountble by fcountve");
        }
      }
    }
    

    I don't see why some pissants mind single-char variables for controlling short loops. They are insignificant in terms of the purpose of the loop - why bloat the code with a mile-long variable, just so that you can avoid seeing "n" or "i" or whatever?

    Now, I can understand wanting something better than a bunch of different single-char loop-counters in nested loops, but otherwise - in a single-level loop - if you replace my i's with your dumb counter's, for no other apparent reason, expect them to be replaced back (for no other apparent reason).

    Rule of thumb: if your loop is small enough to comprehend its scope in a glance (i.e. it's indented neatly and can be seen in one small window in your editor) then using i etc. for loop counters is acceptable. Otherwise (i.e. it's a long loop and/or with possible multiple exits) you'd be advised to pick a descriptive name for your loop counter. If you can't think of one, then either (a) your code requires redesigning in order to make the loop structure more comprehensible, or (b) your brain cells are insufficiently powerful for you to operate effectively in your current career path.

    The other suggestion is that if you have a long loop, extract the contents into a separate method (or subroutine if you're using a 3GL) into which you pass the loop counter (if needed).

  • (cs) in reply to kbar
    kbar:
    If you grew up on Fortran everyone knows that I thru N are integers, everything else is a real.

    No, not a "real", a "float".

  • barry (unregistered) in reply to PiisAWheeL

    yep - but in this case they are not used for anything

  • Chris A (unregistered) in reply to Jay
    Jay:
    Soviut:
    foo2:
    VB happily 'fixes' the types for you, and as expected is not a good idea. It will usually compile, and often fail when run.

    Isn't there a strict mode you can set that requires variables be explicitly typed?

    EDIT: Ah yes, Option Explicit is what it was called. It's been a long long while.

    Option Explicit forces you to define the variables; since VB creates the variables for you a typo meant you wound up with two variables (of Variant type) with similar names. There's an IDE option that automatically inserts that when you create a new module.

    That got added after using symbols to define the variables (A$, B& and all that) was deprecated.

    That doesn't stop the auto type casting stuff like "1" + 1

    <snip>
    VB.NET also has an Option Strict directive which apparently prevents most implicit casts.
  • foo2 (unregistered) in reply to Some Jerk
    Some Jerk:
    '' VB6 Function FiscalYear(dateItem As Date) FiscalYear = IIF( dateItem.Month > 6, dateItem.Year +1, dateItem.Year ) end Function
    Close. VB6 dates aren't objects, so:

    FiscalYear = IIF( Month(dateItem) > 6, Year(dateItem)+1, Year(dateItem) )

    But yeah, still a one-liner.

  • (cs) in reply to hewey
    hewey:
    Is it just me, or are today's trolls more successful than usual?
    It's just you. Trolls here are always successful.
  • JJ (unregistered) in reply to Soviut
    Soviut:
    foo2:
    VB happily 'fixes' the types for you, and as expected is not a good idea. It will usually compile, and often fail when run.

    Isn't there a strict mode you can set that requires variables be explicitly typed?

    EDIT: Ah yes, Option Explicit is what it was called. It's been a long long while.

    No. Option Explicit requires that variables be explicitly declared. It does not enforce type strictness on them; VB6 never does that. Evil Type Correction is always a possibility.

  • JJ (unregistered) in reply to Cbuttius
    Cbuttius:
    however simply x = "06/25/2010"; x = x - 1;

    makes no sense, you cannot subtract 1 from a string.

    You have made an incorrect assumption. In the WTF code, strYear1 does not contain a date but rather a year (basically an integer). The following VB code works just fine:

    Dim x As String x = "2010" x = x - 1

    x now contains "2009". And yes, it's still a string.

  • JJ (unregistered) in reply to JJ
    JJ:
    Evil Type Correction
    Whoops! Evil Type Coercion. Correction is part of what ETC really stands for.
  • (cs) in reply to Soviut
    Soviut:
    Some Jerk:
    I don't care what language you are using... if the names of your variables are not either 1: meaningful, or 2: obvious based on direct usage, they are simply wrong. Also... yes, it is a bad practice to declare variables that you are not using. In most languages, memory is reserved for these variables... but more to the point, it is misleading.

    Agreed! It would be like a book having a table of contents that referred to chapters that didn't actually exist. It doesn't "break" the book, but it's certainly confusing to discover the mismatch. Or perhaps a more practical example would be finding extra parts after assembling your Ikea furniture, leaving you to wonder if they were necessary or not.

    I don't think I've ever assembled something from ikea and NOT had extra parts left over. I've even had things showup in the box that I'm sure did not go to whatever I was trying to assemble.

  • Jimbo (unregistered) in reply to Soviut
    Soviut:
    Jimbo:
    I often get on a hobby horse about inefficient code, and the usual response is "Who cares? We have shirtloads of resources these days". I find this attitude a bit scary - while our resources often can absorb a lot of inefficiency it's no excuse to produce crap. The system you desing for 10 users today might have 100 users tomorrow, and 1000 users next week. The only time you are allowed to write stuff inefficiently is when you are making an app for yourself that will only ever run on your desktop - and even then, why limit the number of programs you can have open at any given time?

    Remember the "triangle of requirements" (as I'm titling it just now). On each corner is marked "fast", "cheap" and "good" respectively. Now you have to pick a side. If you want it fast and cheap, it won't be good; If you want it fast and good, it won't be cheap, etc.

    Optimization is good, but only when it's valuable. For example, a script that's run once a month and takes 1 second to complete does not need a developer spending months, days, or even hours optimizing it, since the value on the return is negligible. When someone disregards an optimization pass on their software, it's usually because it isn't worth it.

    Optimization should be reactive. If a website only gets 5 visitors a day, it isn't valuable enough to warrant the optimization. However, if traffic increases to 50,000 visitors a day then the value of optimization increases and becomes worth pursuing. Software is never "done" and it's never perfect, so trying to pre-optimize often just leads to a lost of wasted time...far more than the optimizations would have saved.

    Maybe I'm playing Devil's Advocate a bit, but while I understand you don't always need the most optimally efficient code, my point is more that there are certain inefficiencies that can be avoided so easily that it would be stupid not to. In the OO world, this is things like limiting the number of Objects - if the first thing a method does is clone or create new Objects that are essentially the same as ones you've already got then you're probably doing it wrong. I agree, that it's stupid to spend a lot of time optimizing trivial scripts that rarely run, however I think your point on websites is a bit different. If you create a web page, surely you assume that millions will flock to it (even if you only get 5 visitors a day, google will do it's magic soon, right?). So too with any application that is anything beyond a simple tool to aid yourself. Sometimes, optimizations are incredibly complicated if made retrospectively, so it's always important to consider how wide reaching your app/website/whatever could be - this is part of the design phase.

    I also think there's a difference between efficiency and optimization (semantics, perhaps, but fairly important ones given the discussion). You can write efficient code that doesn't spuriously allocate memory because we can - and this can still be optimized. Optimization is the deliberate attempt to make the code as quick or efficient as possible - and possibly sacrificing clarity in the meantime. For example: Inefficient code for a bitfield:

    /* We essentially create a new String each time we modifiy it */
    String myBitField = new String("0000");
    

    Efficient code:

    /* We now use a single byte per bit - sub-optimal on most virtual machines (I think), but we have a fixed and relatively reasonable memory footprint */
    boolean myBitField[4] = {false, false, false, false};
    

    Optimized code:

    int bitField = 0;
    

    And we could probably optimize more....

  • Stack (unregistered) in reply to PiisAWheeL

    I think it's more notable that those extra variables aren't actually used in the function anyway

  • (cs) in reply to PiisAWheeL

    Funny that, I always use i,j,k ... throwback to my first program typed from a magazine into a Commodore PET in 1980.

  • Vlad (unregistered)

    Ignoring everything else, there's the wtf of this being a function, but the return value isn't set, instead it looks like the programmer used this code to set values of globals instead.

    If you're bothering to use a function, you should:

    myfunctionname=value

    then in the caller you might say:

    foo=myfunctionname(bar)

    But that's just this one issue.

  • Vlad (unregistered) in reply to Vlad

    My bad, I just noticed there in the middle where they actually do assign a returnvalue.

  • Gibbon1 (unregistered) in reply to hewey
    hewey:
    Is it just me, or are today's trolls more successful than usual?

    I'm been wondering if the original author of the code hasn't been trolling other programmers his whole career. As in, lets figure out the most inane way of doing this that is 100% correct but will make other programmers feel ill just to look at it. Double win if other programmers unable to help themselves try to 'improve' the code and break it in the process, then get spanked by management for their trouble.

    Occasionally I look at my own code my past self is trolling me.

  • Neil (unregistered) in reply to Soviut
    Soviut:
    foo2:
    VB happily 'fixes' the types for you, and as expected is not a good idea. It will usually compile, and often fail when run.
    Isn't there a strict mode you can set that requires variables be explicitly typed?

    EDIT: Ah yes, Option Explicit is what it was called. It's been a long long while.

    I didn't think that VB supported the long long type...

  • Neil (unregistered) in reply to Jim
    Jim:
    publcountc statcountc countnt macountn(Strcountng[] args)
    FTFY
  • Neil (unregistered) in reply to Jay
    Jay:
    Fortran folk can have "DefInt I-N".
    FTFY. [The default in Fortran was IMPLICIT REAL(A-H, O-Z), INTEGER(I-N).]
  • Gibbon1 (unregistered) in reply to Neil
    Neil:
    I didn't think that VB supported the long long type...

    VB does support the long while type with internationalization.

    Dim a As String

    a = "millennium"

    Print a + 1 'prints 1001

  • Jay (unregistered) in reply to Neil
    Neil:
    Jay:
    Fortran folk can have "DefInt I-N".
    FTFY. [The default in Fortran was IMPLICIT REAL(A-H, O-Z), INTEGER(I-N).]
    Well, you learn something new every day.

    So BASIC borrowed the idea of DEF from Fortran (it was probably a good idea at the time).

    Admittedly learning Fortran isn't that useful but anyway. Is that enough for a resume reference?

  • (cs)

    I once wrote a typesetting program in COBOL. Not trivial. Grace Murray Hopper (shame if you don't know her) once wrote a COBOL compiler... in COBOL.

    A tool is only has bad as the workman who uses it.

    The worst programming language is RPG (Report Program Generator). COBOL is fun compared to RPG. PHP is nirvana. Be grateful you never had to write RPG.

  • Ken (unregistered)

    So what is that something special that's on nearly every line? I don't see any periods ending each statement.

  • pantsman (unregistered)

    TRWTF is object-oriented languages.

  • Joe Celko (unregistered)

    I see this COBOL mindset in SQL all the time. We hae a DATE data type and we use tables (completed sets), but the noob is locked into strings and loops, so he uses code like this instead of a simple table constructor. And the date string format is NEVER the required ISO-8601! Hey, we used "mm/dd/yy" in 1950 and it was fine! Or was it "dd/mm/yy", I forget ..:)

  • Rüdiger (unregistered) in reply to PiisAWheeL

    Yeah, but usually a counter is declared only if you need it. That's not the case for nn, nnn and nnnn. They are just corpses - leftovers from former versions (or declared on reserve, which is not better).

    Another strange point is that he avoids parameters and uses global variables as an alternative, without any need.

    But the real hit is that the year is not directly read off from his testDate! Instead, he loops over at most 20 years to perform an interval check. Since most dates will be of the current or the past fiscal year, this is no performance issue. It is just weird. I sometimes encounter this kind of round-the-corner thinking, especially in date computations, and I always find it disturbing. I don't know whether it is related to the language where the programmer comes from. It can be a sort of mentality as well - a different brain structure.

  • TortoiseWrath (unregistered) in reply to Bob

    JavaScript?

    I am not spam

  • MikeyB (unregistered) in reply to Bob

    How do I upvote this?

  • Bob (unregistered) in reply to Bob

    PHP is fine

  • kolik (unregistered) in reply to Spewin Coffee

    APL and Prolog are not bad languages, they're just unconventional and in many ways more powerful than what your typical blub programmer (a.k.a., you) is used to. And you keep talking about the "correct" approach but that doesn't exist. There may be several approaches, each with advantages and disadvantages; a few of those approaches may be conventional, but that doesn't make them "correct." You sound pretty clueless yourself.

Leave a comment on “Globally Fiscal Year”

Log In or post as a guest

Replying to comment #:

« Return to Article