What indent style do you use?



  • (quick reference: http://en.wikipedia.org/wiki/Indent_style)

    I personally use K&R style combined with Banner Style for fairly readible code, and when the code is big enough that you have to scroll to see the gap between braces, I make the difference. For example

    int doStuff() {
        doStuff1();
        doStuff2();
        while (a == 2) {
              // do stuff
        } // while (a==2)
    }

    Something really irks me about the BSD/Allman style (which is used in a project I'm currently coding on). I don't like wasting a line, and I've used K&R style before I even realized what that is specifically. So what are your opinions on this subject and such?



  • Funny ... K & R has always bugged me; I find it hard to find the opening brace ...

    I've just always done Allman; until reading this in the other thread today, I never even realized that there were [b]names[/b] for the different styles.



  • I use BSD/Allman, so I hope you don't run into any of my code.  I don't recall too many cases where the block is large enough to warrant Banner style.

    If I think about, it would say these are the reasons for my indenting style.

    1. It was the style used in my C/C++ text book
    2. I do a fair bit of VB / VBA / VB.Net which tends toward that style
    3. BSD/Allman aligns well with SQL's Begin/End blocks
    After having trained myself to expect the block opening on a new line, I find myself converting K&R to BSD/Allman whenever I get the chance.  I don't think it really has much effect on readibilty, beyond what you used to.






  • while(true)
    {
        printf("BSD for life, yo.");
    }


    "Wasting a line" is an odd reason, unless it's somehow counted against you in some sadistic SLOC performance calculation.



  • @Michael Casadevall said:



    int doStuff() {
        doStuff1();
        doStuff2();
        while (a == 2) {
              // do stuff
        } // while (a==2)
    }




    I prefer exactly this style; I also have the habit to always use curly brackets after an if or while, even if there is only one command following:

    if (x) {
        y();
    }


    instead of

    if (x) y();

    or

    if (x)
        y();



  • I always turn to Code Complete for answers to questions like this. I've found that Steve McConnell has done an excellent job of researching the facts that can answer the question What Is More Maintainable?

    According to the book, neither style is prefered. However,

    "The bottom line is that the details of a specific method of structuring a program are much less important than the fact that the program is structured consistently.

    That makes sense to me. Since I primiarly code in VS.NET, I would say I prefer the BSD style, which it uses by default (probably can be changed though).

    Another intereting bit to add to the discussion is that one study (though it hasn't been tested again AFAIK) showed that (as a concrete example), an expert programmer using K&R might have a harder time following BSD style. So, perhaps it makes sense to switch it up every now and then?



  • I use K&R these days, though in the past I have used mixups that look horrible (back when I was teaching myself C++ from online tutorials).

    "saving a line" influences my coding style alot, and I like to see as much of my code as possible. I put at most one newline between blocks of code, and in the case of a non-optimizable series of if's, I tend to put the if, opening bracket, few short statements and closing bracket on the same line, this transforms a screenful of if-blocks into a third of that space that's still clearly readable but now has context.



  • I use drunken [code] monkey style.



  • Since i've started coding a lot of Python (which uses indentation for block definition), I've come to like K&R style a lot as it also relies on indentation a lot (the initial brace is mostly not visible, the last one serves as a separator between the current block and the following code).

    I find it very readable (esp. with a 4spaces indentation), and it both manages to not waste vertical space and to strongly link propositions (ifs, whiles, fors) with the code block associated to it (there is no separation between the test and the code itself)



  • <FONT face=Tahoma>I use K&R or BSD/Allman, although I didn't know that they have names... 🙂

    But more often I combine the two, like this: 

    <FONT face="Courier New">void doStuff()
    {   doStuff1();
        doStuff2();

        while (a == 2)
        {   // do stuff
            // do more stuff
        }
    }
    </FONT>
    I tried implementing this in VS.NET, but it tends to convert my style back to Allman everytime I reopen my project or rellocate a code block so I just use Allman recently.



    </FONT>



  • @xrT said:

    <font face="Tahoma">I tried implementing this in VS.NET, but it tends to convert my style back to Allman everytime I reopen my project or rellocate a code block so I just use Allman recently.

    </font>



    Options/Text Editor/C#/Formatting/New Lines/New line options for braces

    nonDev



  • @ammoQ said:

    @Michael Casadevall said:


    int doStuff() {
        doStuff1();
        doStuff2();
        while (a == 2) {
              // do stuff
        } // while (a==2)
    }




    I prefer exactly this style; I also have the habit to always use curly brackets after an if or while, even if there is only one command following:

    if (x) {
        y();
    }


    instead of

    if (x) y();

    or

    if (x)
        y();

    Same here. I once had to add some extra functionality in a school assingment for which the teacher had written a basis and used the last style you mention. Since i always used curly brackets i just added some extra code after the first comment and expected it to work (after all, just adding an extra line of code had always worked before). Took me quite a while to figure out that you need brackets if there are multiple statements. Since that moment i promised myself to always use brackets.

    by the way, i in a few cases i have deviated from this style like this, but in general i  prefer K&R

    for (...){
       if(something){break; }
       do the usual stuff
    }



  • I use K&R.

    If will use if (condition) function(); from time to time, though. I would never put function(); on a new line.

    It's only really because I dislike the way that BSD/Allman leaves blank space after the function definition. I don't need to see the opening brace - I rely on the actual indentation of the block.



  • @Hantas said:

    @ammoQ said:

    @Michael Casadevall said:


    int doStuff() {
        doStuff1();
        doStuff2();
        while (a == 2) {
              // do stuff
        } // while (a==2)
    }




    I prefer exactly this style; I also have the habit to always use curly brackets after an if or while, even if there is only one command following:

    if (x) {
        y();
    }


    instead of

    if (x) y();

    or

    if (x)
        y();

    Same here. I once had to add some extra functionality in a school assingment for which the teacher had written a basis and used the last style you mention. Since i always used curly brackets i just added some extra code after the first comment and expected it to work (after all, just adding an extra line of code had always worked before). Took me quite a while to figure out that you need brackets if there are multiple statements. Since that moment i promised myself to always use brackets.

    by the way, i in a few cases i have deviated from this style like this, but in general i  prefer K&R

    for (...){
       if(something){break; }
       do the usual stuff
    }

    That's why I'm addicted to vs.net now.  You get immediate feedback if you try to do something like add a second statement to an unbracketed if.

    Now I get a weird feeling whenever I type a semicolon and a bunch of stuff doesn't reformat itself on the page.  Time to look for the bug, I think.



  • @benryves said:

    I use K&R. If will use if (condition) function(); from time to time, though. I would never put function(); on a new line. It's only really because I dislike the way that BSD/Allman leaves blank space after the function definition. I don't need to see the opening brace - I rely on the actual indentation of the block.

    Does it bother you because, in your opinion, it takes up unnecessary vertical space?



  • @benryves said:

    I use K&R.

    If will use if (condition) function(); from time to time, though. I would never put function(); on a new line.

    It's only really because I dislike the way that BSD/Allman leaves blank space after the function definition. I don't need to see the opening brace - I rely on the actual indentation of the block.



    That's the very reason that I like BSD/Allman. You may not rely on the { being there, but the compiler does. It doesn't care how nicely your stuff is indented if that's left out. 🙂 (unless you throw your code through some kind of Python pre-processor, which would be an interesting idea, but not one I believe anyone does.)



  • @ammoQ said:

    I prefer exactly this style; I also have the habit to always use curly brackets after an if or while, even if there is only one command following:

    if (x) {
        y();
    }


    instead of

    if (x) y();

    or

    if (x)
        y();

    <FONT face=Arial>Option the third will bite you when you are doing debugging.  If you have code like this:</FONT>

    if (x)
        y();
    z();
    <FONT face=Arial>and you decide to comment out y() for debugging, like so: </FONT>
    if (x)
        //y();
    z();
    <FONT face=Arial>weird stuff will happen.  It's gotten me several times.</FONT>


  • @xrT said:

    <font face="Tahoma">I use K&R or BSD/Allman, although I didn't know that they have names... 🙂

    But more often I combine the two, like this: 

    <font face="Courier New">void doStuff()
    {   doStuff1();
        doStuff2();

        while (a == 2)
        {   // do stuff
            // do more stuff
        }
    }
    </font>
    </font>



    Now this is decidedly less mainatainable than the other two styles, since it very often happens that you have to add or remove the first statement in a block, and then you have to work around the {.

    You need to manually navigate to the first char of the actual statement, and do stuff to it, whereas not combining the { and a statement on one line allows you to do full line operations. Much quicker when removing or adding the first statement.

    The combo-strategy does align matching brackets, but that is outweighed by having to work around the oddity of having a { and a statement on one line.

    I prefer to put the opening { on a new line of its own, because:
    A) newlines open up the code, and I like that. When it's all compacted without any white lines in between, the code is harder to scan. "wasting a line" is not an argument, because none of us are on 800x600.
    😎 open and close brackets are aligned so that the other bracket can be easily retrieved with the eye. This advantage is completely lost with K&R. That loss is mitigated by bracket-match highlighting ( ❤ ), but not as effective as putting the { on a new line. Knowing where to look helps one to find.



  • @Eric Shinn said:

    @ammoQ said:

    I prefer exactly this style; I also have the habit to always use curly brackets after an if or while, even if there is only one command following:

    if (x) {
        y();
    }


    instead of

    if (x) y();

    or

    if (x)
        y();

    <FONT face=Arial>Option the third will bite you when you are doing debugging.  If you have code like this:</FONT>

    if (x)
        y();
    z();
    <FONT face=Arial>and you decide to comment out y() for debugging, like so: </FONT>
    if (x)
        //y();
    z();

    <FONT face=Arial>weird stuff will happen.  It's gotten me several times.</FONT>

    I never realised this could become a problem (since i always use brackets), but hey, here's another reason to always use brackets.



  • Nothing but Whitesmiths (never even knew it was named as well):

    while (some_variable == 1)
        {
        an_action();
        a_second_action();
        }

    if (different_condition)
        one_liner();



  • Mine is pretty much K&R C styly. Also tabs. I like tabs. That are 8 wide. Don't see what the big deal is with them.

    Function calls get a bit extra space padding to them.
    Anyway, code sample:

    <font face="Courier New">int main( int argc, char *argv )
    {
           int i;
           for (i = 0; i < argc; i++) {
                 if (strlen( argv[i] ) >= 3) puts( argv[i] );
                 /
    comment, eh? */
           }
           return 0;
    }
    </font>
    I used to do the thing that people do where they put curly brackets on the line after the for or if statement, but that looks a bit weird when you do this:
    <font face="Courier New">
    if (c = string[i] && (c >= 'a' && c <= 'z')
                            || (c >= 'A' && c <= 'Z')
                            || (c == '_'))
    {
    </font>
    I mean look at the poor curly bracket, it's so lonely.



  • K&R, always have; always will.



  • @dave said:

    @Michael Casadevall said:
    I don't like wasting a line, and I've used K&R style before I even realized what that is specifically. So what are your opinions on this subject and such?

    It isn't wasting a line - it offers a perfect place for that comment explaining what it is you're about to do:

    while (a == 2)
    { // do stuff
    // real code goes here
    }

    So you can force yourself to right sensible comments.

    I personally hate the style of putting a comment to tell you what the structure you've just terminated is - this suggests to me that you're expecting your indentation to be screwed up.



    no, it means your function (or whatever) will probably be so big or have so much nested stuff, it will either scroll off the screen (go K&R) or the indentation won't make it clear enough (maybe set sw=2 is a little over the top in horizontal space conservation, but ssh usually doesn't give you too much room in your terminal.



  • @AI0867 said:

    @dave said:
    @Michael Casadevall said:
    I don't like wasting a line, and I've used K&R style before I even realized what that is specifically. So what are your opinions on this subject and such?

    It isn't wasting a line - it offers a perfect place for that comment explaining what it is you're about to do:

    while (a == 2)
    { // do stuff
    // real code goes here
    }

    So you can force yourself to right sensible comments.

    I personally hate the style of putting a comment to tell you what the structure you've just terminated is - this suggests to me that you're expecting your indentation to be screwed up.



    no, it means your function (or whatever) will probably be so big or have so much nested stuff, it will either scroll off the screen (go K&R) or the indentation won't make it clear enough (maybe set sw=2 is a little over the top in horizontal space conservation, but ssh usually doesn't give you too much room in your terminal.


    Yeah, I learned to program on the command line, so every line counted, hence how I got started with K&R. I always do the brackets for if statements, or leave it on one line (though I do that less and less) so it doesn't break. Indentation helps me figure out what block goes where a LOT more then the brackets do - if its on the left most line, its either a preprocessor directive, or a function, and I clearly see where each one ends. I might try using the Allman/BSD style someday, but for the moment, I'm quite happy with K&R and Banner.



  • <sarcasm>I never bother to indent anything - it wastes too much vertical and horizontal space:

    if (condition) { dosometing1; dosomething2; dosomething3; if (othercondition) { domorestuff1; domorestuff2; } dosmething4; } else { dootherstuff1; dootherstuff2; } doextrastuff;

    </sarcasm>



  • @Albatross said:

    <sarcasm>I never bother to indent anything - it wastes too much vertical and horizontal space:

    if (condition) { dosometing1; dosomething2; dosomething3; if (othercondition) { domorestuff1; domorestuff2; } dosmething4; } else { dootherstuff1; dootherstuff2; } doextrastuff;

    </sarcasm>



    ACK IT BURNS.

    Back on topic, it seems those who use python also use K&R style - is there any other language that uses identation style?


  • Well, I use K&R style with 4-space hard tabs almost exclusively - even in my CSS and Javascript, with some slight adaptations for T-SQL 🙂 - so I found Python really easy to adapt to. It was almost the exact same thing, but without actually typing the braces.

    I always HATED it when professors would give us some code stubs for projects, and they would be an ugly mess of soft tabs and newlines before opening braces. Ha ha.



  • @Michael Casadevall said:

    @Albatross said:

    <sarcasm>I never bother to indent anything - it wastes too much vertical and horizontal space:

    if (condition) { dosometing1; dosomething2; dosomething3; if (othercondition) { domorestuff1; domorestuff2; } dosmething4; } else { dootherstuff1; dootherstuff2; } doextrastuff;

    </sarcasm>



    ACK IT BURNS.

    Back on topic, it seems those who use python also use K&R style - is there any other language that uses identation style?

    Haskell sort-of does, Haskell parsers use indentation to replace explicit scoping (using braces and semicolon), they autocomplete the missing parts based on the aforementioned indentation (which is why you sometime get weird error messages, with Hugs for example). Nobody ever uses the explicit scoping, so Haskell can be considered indentation-based.

    There is also a set of Scheme reader macros to replace S-exp by indentation-based rules.

    And ABC, from which Python inherits the whitespace-significant syntax.

    Old Cobol versions were also somewhat indentation-styled. Truth is that older COBOL compiler were column-based, not indentation.



  • @masklinn said:

    Old Cobol versions were also somewhat indentation-styled. Truth is that older COBOL compiler were column-based, not indentation.

    Ahhhhhhhh!  Run away!

    In my first COBOL class (one of my first programming classes ever, sometime in '88 or '89), we were "encouraged" to use coding forms, to ensure we got everything lined up right.  I remember the compiler puking on more than one occasion because of misaligned columns.

    Can't say that I miss that part of those days.



  • I too use this style (without prior knowledge of it having this
    name).  However, I use braces for all if statements, not just
    those that span multiple lines.



    I like this style because it reminds me of python code, which I find to
    be the most readable of all languages (potentially because python looks
    almost exactly like pseudocode).




  • @llpope187 wrote the following post at 07-25-2006 1:28 AM said:

    I use BSD/Allman, so I hope you don't run into any of my code.

    If I think about, it would say these are the reasons for my indenting style.

    1. It was the style used in my C/C++ text book
    2. I do a fair bit of VB / VBA / VB.Net which tends toward that style
    3. BSD/Allman aligns well with SQL's Begin/End blocks

    Good Lord, when geeks can't have a flamewar about languages because they more or less agree on their favorite language, they'll have a flamewar about exactly where to put the curly braces.  (Instead of thanking the Lord for languages that have curly braces in the first place.)

    That said, I found myself to be a bit schizophrenic in that respect.  When there are curly braces, I very much prefer what the original poster called BSD/Allman, yet in Pascal I prefer the equivalent of K&R instead for some reason:

    <FONT face="Courier New" size=2>for(size_t i = 0;  i < whatever.size();  i++) do begin
          DoStuff0();
          DoStuff1();
    end;</FONT>

    (well, I don't remember the exact syntax for a for loop in Pascal off the top of my head, it's been a while, but I'm sure you get the idea).  It's curious that someone might let their preferred style in one language influence their preferred style in another language... 😉



  • I use K&R because I learned to code that way. BSD is hard to read for me, but I guess it's because I'm used to K&R



  • I will not give away a line to a mere opening brace! I use what I think is straight down the line K&R (i.e. open braces after the test, close braces alone):

    void Method(int arg){
    try {
    while(sometest){
    ...
    // Sometimes I'll do this though
    for(int i = 0; i < thing.length; i++){
    if(arg == thing[i]) { index = i; break; }
    }
    // Or this
    if(test) oneliner;
    }
    } catch(Exception) {
    // handle it
    }
    }

    Edit: arse, the forum ate half my code because of that pesky <



  • Indentation in C/Java already shows you at which level your code is;
    therefore, the choice of curly braces is rather arbitrary.
    Below is a lispy style I've been fond of lately.

    #define dotimes(I,N) for(int I=0; I<(N); ++I)

    class HaveFunMrTA {
    public:
    void method(int arg) {
    try {
    while(sometest) {
    dotimes(i, thing.length) {
    if(arg == thing[i]) {
    index = i;
    break; }
    if(test) oneliner; } } }
    catch(const Exception& ex) {
    // handle it } } }



  • Um ...

    // snip
     // handle it } } }

    err ... oops? I think the compiler might choke when it finds it has three less }s than it wanted 😉



  • @cholesky said:

    Indentation in C/Java already shows you at which level your code is;
    therefore, the choice of curly braces is rather arbitrary.
    Below is a lispy style I've been fond of lately.

    #define dotimes(I,N) for(int I=0; I<(N); ++I)

    class HaveFunMrTA {
    public:
    void method(int arg) {
    try {
    while(sometest) {
    dotimes(i, thing.length) {
    if(arg == thing[i]) {
    index = i;
    break; }
    if(test) oneliner; } } }
    catch(const Exception& ex) {
    // handle it } } }


    Mhmmm... looks almost like Python.
    I'm a bit afraid this style cries for hard-to-find bugs when indentation and brackets do not match.



  • You're right about the bugs, see e.g. the last line

    // handle it } } } // whoops, brackets commented!

    Keeping track of parenthesis (or brackets in this case) is
    a known problem for lisp-ers. Good editors support
    blinking of matching parenthesis/brackets, which eases
    maintaining such code.



  • @cholesky said:

    You're right about the bugs, see e.g. the last line

    // handle it } } } // whoops, brackets commented!


    This one is relatively harmless, as the compiler catches it. But how about that one:

    #define dotimes(I,N) for(int I=0; I<(N); ++I)

    class HaveFunMrTA {
    public:
    void method(int arg) {
    try {
    while(sometest) {
    dotimes(i, thing.length) {
    if(arg == thing[i])
    index = i;
    break; } }
    if(test) oneliner; }
    catch(const Exception& ex) {
    // handle it } } }



  • @cholesky said:

    You're right about the bugs, see e.g. the last line

    // handle it } } } // whoops, brackets commented!

    Keeping track of parenthesis (or brackets in this case) is
    a known problem for lisp-ers. Good editors support
    blinking of matching parenthesis/brackets, which eases
    maintaining such code.


    Of course, even faster than bracket-matching would be a proper format for your brackets so you can match them by scanning.

    The line-wasting format is the only one that facilitates this:
    if (bastard)
    {
    Collection BloodyMess = bastard.fubar(Enum Fucknedness.veryBad);
    for (int i=0; i < BloodyMess.length; ++i)
    {
    bastard.cleanUp(BloodyMess[i]);
    }
    }

    Perfect alignment!
    Some people also lineWaste with CSS:
    .smuck
    {
    background:black url('schmuck.gif') repeat-x;
    color:#ccc;
    padding:10px;
    }

    But that has some bad effects and is completely pointless, as:
    A) CSS becomes vertical and scrolling really quickly, therefore lineWasting is felt much sooner than with code, which is more spread out in two dimensions.
    😎 CSS usually isn't nested, so being able to see which bracket goes where has ZERO advantage.

    ) it's possible, with the namespace an media constructions, to get nested brackets, but that's so, so so rare and not advisable anyway.



  • Ah, you're right, a line-waste will make the nesting level visually
    most perceptive. Perhaps there is also an eye-ergonomic effect of
    having more separation between lines.



    Actually, we use line-wasting at work. The reason I don't waste lines
    at hobby projects is that I like to see as much code as possible at
    once. Also, bracket matching is something which can be very much
    automated, and as such I'd rather leave it to the editor. Match
    blinking, autoindentation and runtime bracket balance checking does
    wonders.



  • Perhaps there is also an eye-ergonomic effect of
    having more separation between lines.


    This is a big issue for me.

    I hate it when people don't pepper their code with blank lines, and just condense all code as mush as possible. I tend to put blank lines between setup/action combinations. For example, variable delcarations and the subsequent For loop or couple of functions that act upon them.

    runtime bracket balance checking does
    wonders.


    Good one! Most normal text editors don't support that kind of actual script interpretation; they're just colourizers. Editplus isn't going to pop up an alert saying "Your shit don't line up, see" when I save.



  • @cholesky said:

    You're right about the bugs, see e.g. the last line

    // handle it } } } // whoops, brackets commented!

    Keeping track of parenthesis (or brackets in this case) is
    a known problem for lisp-ers. Good editors support
    blinking of matching parenthesis/brackets, which eases
    maintaining such code.

    It's not blinking, it's parens-matching (doing something with the opposite paren, some editors blink it, others change it's background or foreground color). And can do it with braces and brackets too of course (I'm in fact often annoyed by editors that don't do it, especially when the lowly Scite has that ability)

    And some editors (emacs) also manage to "autocomplete" parens & braces: hit a key and every open paren is closed

    @dhromed said:
    Of course, even faster than bracket-matching would be a proper format for your brackets so you can match them by scanning.

    Did you realize that you completely and utterly missed cholesky's point?

    And as a side note <style-war>I find K&R to work much better to match levels</style-war>



  • @masklinn said:

    @dhromed said:
    Of course, even faster than bracket-matching would be a proper format for your brackets so you can match them by scanning.

    Did you realize that you completely and utterly missed cholesky's point?



    He said something about a method for keeping track of brackets.

    Then, I said something about a method for keeping track of brackets.

    Not exactly missing the point.


  • @dhromed said:

    @masklinn said:
    @dhromed said:
    Of course, even faster than bracket-matching would be a proper format for your brackets so you can match them by scanning.

    Did you realize that you completely and utterly missed cholesky's point?



    He said something about a method for keeping track of brackets.

    Then, I said something about a method for keeping track of brackets.

    Not exactly missing the point.

    He said something about keeping track of brackets when using a lispy coding style in Java, thus your answer didn't satisfy the basic requirements of the problem.

    Thus completely missing the point.



  • I used to use K&R, but I recently switched to BSD/Allman because it was the defacto standard at work. Now I find that I actually prefer BSD. Of course, even when I used K&R style, I would put in extra whitespace to make my code more readable. My net lines of code has actually stayed about the same.

    Also, what some people call "wasting lines", I call "making code easier to scan". What difference does it make if I can only see 30 "real" lines of code rather than 50 "real" lines. It's not like I can actually focus on more than a couple of lines at a time anyway, so I break it up with whitespace to make it easier to scan.

    Just for reference, my old style:

    if (foo) {

        doSomething();
        doSomethingElse();

    }

    Now:
    if (foo)
    {
        doSomething();
        doSomethingElse();
    }

    Oh, and hard tabs are a must! That way the guy down the row who likes 8-space indents, the guy in the next cube who likes 1-space indents, and me (4-space) can all set our IDEs to control the tab-width and not drive each other nuts.



  • @masklinn said:

    He said something about keeping track of brackets when using a lispy coding style in Java, thus your answer didn't satisfy the basic requirements of the problem.

    Thus completely missing the point.



    Even Lispers have the option of formatting their parens, even though that's silly in Lisp. [i]Also[/i], we're not actually writing Lisp. [i]Also[/i], the main topic here is bracket style.

    My point remains valid and on track.


  • drhomed, masklinn: stop it, please



  • Okay.



  • @Bob Janova said:

    I will not give away a line to a mere
    opening brace! I use what I think is straight down the line K&R
    (i.e. open braces after the test, close braces alone)

    [moderator's note: included the quote]
    Same here, exactly.



  • @Bob Janova said:

    Um ...

    // snip
     // handle it } } }

    err ... oops? I think the compiler might choke when it finds it has three less }s than it wanted 😉


    [moderator's note: included quote]

    I would hate to debug your code.

Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.