• David (unregistered) in reply to iMalc

    Re: iMalc

    I've encountered a situation where [a binary string] was undoubtedly the best choice.

    This whole subthread vaguely disturbs me.

    Let me reiterate the original point: there is never a good reason for your program to contain "11001101".

    Firstly: whats wrong with "int i = 0xCD;"? Or "int i = 0xCD; // 11001101 binary", if you think that people reading the program might not know what "0xCD" means - assuming there is a context in which somebody might reasonably be editing a program containing the presumably critical binary number "11001101" but somehow not know that its just 0xCD.

    Secondly: if you write "const char *s="11001101";", what do you think happens when you try to chop it, or splice bits? The underlying machine operations are exactly the same as if you had written "const uint8 *a = {1,1,0,0,1,1,0,1};" and performed the corresponding array operations; moreover, the latter is more readable, since it makes it clear that the intent is to create an array of values and not a string (there was a time when you would, as a programmer, have been expected to know the difference).

    Some things are done for a reason: critical optimization, where the code just has to run fast, and everything else (including human-readability) is secondary; critical maintainability, where the code just has to be readable and minimally error-prone, and everything else (including run-time performance) is secondary; and so on.

    And other things are done for no reason other than that the person coding them is utterly effing incompetent. I would argue, IMVHO, that implementing something in a given way because it lets you abuse a feature of the particular language youre using in order to avoid reading the language ior standard library reference, falls into this latter category. And if you have done it that way because the language youve chosen doesnt let you do it the straightforward way - well, that would only make it worse, wouldnt it? (Hint: an idiotic decision to use an inappropriate language is no less idiotic because the programmer did not make it personally.)

    Specifically, then: using strings to represent binary numbers is an abortive attempt at syntactic sugar that makes the program less comprehensible to both humans and computers.

    TL;DR: when one is confronted with code that is clearly Just Plain Bad, with no redeeming qualities whatsoever, one calls it as such.

  • Locke (unregistered) in reply to Aaron
    Aaron:
    OzPeter:
    The sample strings are 82 bits long. I did a cursory search on google and I can't see any popular DB (MSSQL, MySQL or Orace) that supports 96 bit integers. So storing the result in a varchar column isn't totally in the realms of stupidity. The alternatives would have been to split the value up into multiple columns, which then creates the issue of trying to ensure that the columns are assembled in the correct order when you are doing a query.

    Of course I bet that there may have been another way to encode the information so you didn't have to jump through all of these hoops.

    May have been? How about a fixed-point decimal column? Or even two integer columns (one 64-bit and one 32-bit)?

    Also, there's no such product as "MSSQL". Or "Orace" for that matter.

    Or perhaps a binary column (BLOB, IMAGE, w/e)? There is no excuse for storing 82 bits of data using 82 bytes of storage.

  • jverd (unregistered) in reply to Procedural
    Procedural:
    Mike:
    I stopped reading halfway down. If I had a job that involved this code, my next words would be "I quit".

    Ah, the generic throwaway comment; how appreciated.

    Two things:

    1. Hmmm, no you wouldn't; I'm sure it sounds great to say it at the brewery with the boys (or muttering on the sofa at night in front of the telly), but in reality, no you wouldn't.

    2. If you did you wouldn't be worth employing anyway; this code needs refactoring. Do you not consider refactoring part of your job ? Do you only take jobs to fix and improve code that is already good ? Perhaps you can't reengineer your way out of a few lines of code ? What good are you to a project then ?

    I propose that we relabel all the "I'd quit" posters that pollute every single darn story as incompetent and lazy prima donnas. Take up gardening or something.

    If I were assigned to maintain that code, then:

    If I had enough savings to live for 3 months, I would quit on the spot.

    If I did not have that savings, I would immediately use as much vacation as I could, and very aggressively look for a new job.

    "Do you not consider refactoring part of your job ?" is a total strawman. Just because refactoring is part of my job, that doesn't mean I can't put limits on what kinds of refactoring (or any other task that's "part of my job") that I'm willing to do.

    And no, the fact that somebody would walk away from a total shit job does not make them not worth employing.

  • jverd (unregistered) in reply to (A different) Mike
    (A different) Mike:
    Procedural:
    Mike:
    I stopped reading halfway down. If I had a job that involved this code, my next words would be "I quit".

    Ah, the generic throwaway comment; how appreciated.

    Two things:

    1. Hmmm, no you wouldn't; I'm sure it sounds great to say it at the brewery with the boys (or muttering on the sofa at night in front of the telly), but in reality, no you wouldn't.

    2. If you did you wouldn't be worth employing anyway; this code needs refactoring. Do you not consider refactoring part of your job ? Do you only take jobs to fix and improve code that is already good ? Perhaps you can't reengineer your way out of a few lines of code ? What good are you to a project then ?

    I propose that we relabel all the "I'd quit" posters that pollute every single darn story as incompetent and lazy prima donnas. Take up gardening or something.

    At least the original poster only wasted 2 seconds of our lives with his comment. That's a lot less time than I wasted reading your overwrought and totally unnecessary over-analysis of it. Just something for you to consider next time you're thinking of rebutting a useless comment with a considerably longer useless comment.

    Right. Because this site is all about productivity and providing useful information.

  • MrT (unregistered) in reply to highphilosopher
    highphilosopher:
    Anon:
    I think some day I heard that TRWTF was PHP...

    You can write some pretty elegant code in PHP. The real problem is that it has such a low learning curve that almost any idiot with a keyboard can write code in PHP.

    No er... actually you can not. Unless you don't use system functions at all but this would be very simple code. Names and patterns are just too convoluted to make clean and elegant code possible.

  • Mark J. (unregistered) in reply to Procedural
    Procedural:
    Mike:
    I stopped reading halfway down. If I had a job that involved this code, my next words would be "I quit".

    Ah, the generic throwaway comment; how appreciated.

    Two things:

    1. Hmmm, no you wouldn't; I'm sure it sounds great to say it at the brewery with the boys (or muttering on the sofa at night in front of the telly), but in reality, no you wouldn't.

    2. If you did you wouldn't be worth employing anyway; this code needs refactoring. Do you not consider refactoring part of your job ? Do you only take jobs to fix and improve code that is already good ? Perhaps you can't reengineer your way out of a few lines of code ? What good are you to a project then ?

    I propose that we relabel all the "I'd quit" posters that pollute every single darn story as incompetent and lazy prima donnas. Take up gardening or something.

    This code doesn't just need refactoring - it needs an enema!

  • (cs) in reply to Procedural
    Procedural:
    2. If you did you wouldn't be worth employing anyway; this code needs refactoring. Do you not consider refactoring part of your job ? Do you only take jobs to fix and improve code that is already good ? Perhaps you can't reengineer your way out of a few lines of code ? What good are you to a project then ?

    I propose that we relabel all the "I'd quit" posters that pollute every single darn story as incompetent and lazy prima donnas. Take up gardening or something.

    It depends.

    If one is assigned to refactor that code, then, certainly, refactoring it is within the scope of the employment.

    If one is assigned to rewrite that functionality, that is certainly within the scope of employment.

    In either situation, or in the case where I was to do one or the other, based upon my expert opinion which was a better plan, I would not have a real issue with it.

    I'd personally not have a problem with it if I were allowed to refactor it - but it had to be on my time. If I'm going to be working with this thing regularly, there's a quality of work environment aspect that would, IMHO, be worth a couple of weekends of refactoring work. (I've done it before - and I expect to do it again.)

    If, on the other hand, I was required to maintain that code without gratuitous refactoring, I would consider my options.

    If I was required to maintain that code, and maintain its current style (no refactoring each section I'm required to update), I would probably actively seek alternative employment.

    There are people who are far less cautious than me who would simply quit - and I wouldn't complain about it, if they were not allowed to fix the problem on company time.

    Now, those who would actually quit over just having to interact, however briefly, with said code, like the grandparent poster indicated - I agree with you on his claimed prima donna status.

  • (cs) in reply to MrT
    MrT:
    highphilosopher:
    Anon:
    I think some day I heard that TRWTF was PHP...

    You can write some pretty elegant code in PHP. The real problem is that it has such a low learning curve that almost any idiot with a keyboard can write code in PHP.

    No er... actually you can not. Unless you don't use system functions at all but this would be very simple code. Names and patterns are just too convoluted to make clean and elegant code possible.

    I seem to recall having worked with PHP version 3 code which did a fair amount of LDAP interactions without resorting to any system calls. At the time, it looked like we could actually get it to look somewhat elegant if we upgraded to using PHP 4.

    However, after doing a cost-benefit analysis, and factoring in that the team was entirely composed of Perl programmers, who had only picked up PHP for this particular job (since the PHP guy had left), we chose to go with Perl instead. Only people who've had regrets about that choice are the people who've since tried to get us to replace the pages with ASP, ASP.NET, or Java code - they've all been shot down because our Perl pages have no visible issues, and generally respond several times faster than any of the ASP, ASP.NET, and JSP pages elsewhere in the company.

    So, I guess, take my first paragraph with the grain of salt that this comes from someone who feels it's possible to make Perl code look elegant and clean - but it's also from someone who takes the time to learn how to actually use the languages he works with, rather than just abusing the shell scripting hooks present.

  • Procedural (unregistered) in reply to tgape
    tgape:
    Procedural:
    2. If you did you wouldn't be worth employing anyway; this code needs refactoring. Do you not consider refactoring part of your job ? Do you only take jobs to fix and improve code that is already good ? Perhaps you can't reengineer your way out of a few lines of code ? What good are you to a project then ?

    I propose that we relabel all the "I'd quit" posters that pollute every single darn story as incompetent and lazy prima donnas. Take up gardening or something.

    It depends.

    If one is assigned to refactor that code, then, certainly, refactoring it is within the scope of the employment.

    If one is assigned to rewrite that functionality, that is certainly within the scope of employment.

    In either situation, or in the case where I was to do one or the other, based upon my expert opinion which was a better plan, I would not have a real issue with it.

    I'd personally not have a problem with it if I were allowed to refactor it - but it had to be on my time. If I'm going to be working with this thing regularly, there's a quality of work environment aspect that would, IMHO, be worth a couple of weekends of refactoring work. (I've done it before - and I expect to do it again.)

    If, on the other hand, I was required to maintain that code without gratuitous refactoring, I would consider my options.

    If I was required to maintain that code, and maintain its current style (no refactoring each section I'm required to update), I would probably actively seek alternative employment.

    There are people who are far less cautious than me who would simply quit - and I wouldn't complain about it, if they were not allowed to fix the problem on company time.

    Now, those who would actually quit over just having to interact, however briefly, with said code, like the grandparent poster indicated - I agree with you on his claimed prima donna status.

    Beautiful answer; thanks for taking the time to post it.

  • Slartibartfast (unregistered)

    Might this sequence of 1 and 0's be the original core of the internet? If the internet ever crashes this PHP page can be run on a local web server to restart it?

  • vanglorious (unregistered) in reply to Procedural
    Procedural:
    tgape:
    Procedural:
    2. If you did you wouldn't be worth employing anyway; this code needs refactoring. Do you not consider refactoring part of your job ? Do you only take jobs to fix and improve code that is already good ? Perhaps you can't reengineer your way out of a few lines of code ? What good are you to a project then ?

    I propose that we relabel all the "I'd quit" posters that pollute every single darn story as incompetent and lazy prima donnas. Take up gardening or something.

    It depends.

    If one is assigned to refactor that code, then, certainly, refactoring it is within the scope of the employment.

    If one is assigned to rewrite that functionality, that is certainly within the scope of employment.

    In either situation, or in the case where I was to do one or the other, based upon my expert opinion which was a better plan, I would not have a real issue with it.

    I'd personally not have a problem with it if I were allowed to refactor it - but it had to be on my time. If I'm going to be working with this thing regularly, there's a quality of work environment aspect that would, IMHO, be worth a couple of weekends of refactoring work. (I've done it before - and I expect to do it again.)

    If, on the other hand, I was required to maintain that code without gratuitous refactoring, I would consider my options.

    If I was required to maintain that code, and maintain its current style (no refactoring each section I'm required to update), I would probably actively seek alternative employment.

    There are people who are far less cautious than me who would simply quit - and I wouldn't complain about it, if they were not allowed to fix the problem on company time.

    Now, those who would actually quit over just having to interact, however briefly, with said code, like the grandparent poster indicated - I agree with you on his claimed prima donna status.

    Beautiful answer; thanks for taking the time to post it.

    really interesting contribution to the thread you've made procedural. i only disagree with you calling the first guy a prima donna. like someone else pointed out, i think he didn't literally mean he'd quite the instant he saw this code. it was just a hyperbolic expression of his disgust at the code. and i think we can all agree that the code is disgusting.

  • bg (unregistered)

    hmm, after reading the code 5 times (damn my head hurts) i think i reverse-engineered it! Voila Soo, i guess it's a very 1337 way of product extras i.e. If the field has 0 at index 5 then this product doesn't have the fifth feaure

    Yeah, like, i admit it, i have written similar shit code :)

  • ollopa (unregistered)

    That was just about the most frightening thing I've ever seen. Absolutely the most pain I have ever felt while scrolling code as fast as my computer would let me. How fast is that? Not fast enough...

  • redox (unregistered) in reply to Little Bobby Tables
    Little Bobby Tables:
    There are 10 types of people in this world..

    AWESOME

  • random (unregistered)

    Death to high level coding. The ASM code needed to extract data from that string would be shorter than the string itself.

Leave a comment on “1's and 0's”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article