At least it works... this time.



  •  I've been firefighting for 2 years now, and still run into stuff like this every week =(...

    /// <summary>
    /// Thread that continously loops through the given directory "Printouts" for xml files
    /// </summary>
    private void SearchForXml()
    {
        while (true)
        {
            Thread.Sleep(500);
            try
            {
                currentFile = Directory.GetFiles(xmlFilePath)[0].ToString();
                currentFile = Path.GetFileName(currentFile);
                if (currentFile != null)
                {
                    PrintFile(currentFile);
                    currentFile = null;
                }
                else { }
            }
            catch (IndexOutOfRangeException)
            {

            }
        }
    }
     



  • @discomike said:

    else { }

    I lol'd



  • So either PrintFile deletes the file (yay, side effects), or...



  • Yes PrintFile actually deletes the files, but whenever the folder is empty (almost all of the time), you get an index out of range exception - it works but not very pretty. I would probably implement it with FileSystemWatcher, but now I just changed to check if i got any results or not before trying to access it. The main problem with this program was not even in this method... just stumbled upon it.




  • @Ben L. said:

    @discomike said:
    else { }
    I lol'd
    Perfectly good bulletproofing.  Make your else clauses explicit so a subsequent change by another developer doesn't suddenly cause fall-through.

    On the other hand:

    @discomike said:

    while (true)

    is the sign of a disordered mind.



  • @da Doctah said:

    On the other hand:

    @discomike said:

    while (true)

    is the sign of a disordered mind.

    It beats:

    while (false) { 
      stuff that should have just been commented 
      out instead of wrapped with: while false
      - especially when STUFF is spread across multiple classes
    }
    


  • @snoofle said:

    @da Doctah said:

    On the other hand:

    @discomike said:

    while (true)

    is the sign of a disordered mind.

    It beats:

    while (false) { 
      stuff that should have just been commented 
      out instead of wrapped with: while false
      - especially when STUFF is spread across multiple classes
    }
    
    Is that more or less efficient than if(false)?


  • @da Doctah said:

    @discomike said:

    while (true)

    is the sign of a disordered mind.

    Or a game loop.



  • @snoofle said:

    @da Doctah said:

    On the other hand:

    @discomike said:

    while (true)

    is the sign of a disordered mind.

    It beats:

    while (false) { 
      stuff that should have just been commented 
      out instead of wrapped with: while false
      - especially when STUFF is spread across multiple classes
    }
    

    Seriously? Please, say you can post an example of this in use!



  • @Ben L. said:

    @snoofle said:


    while (false) { 
      stuff that should have just been commented 
      out instead of wrapped with: while false
      - especially when STUFF is spread across multiple classes
    }
    

    Is that more or less efficient than if(false)?
     

    Not with an optimizing compiler, but in terms of source-code maintenance, if (false) requires a matching else {}

     



  • @da Doctah said:

    @discomike said:

    while (true)

    is the sign of a disordered mind.

     

    Is it?

    I thought it was a better technique to leave the loop condition as (true) and add logic to break out from within, rather than try to add an overly convoluted logic expression into the parantheses - thinking about future maintainability considerations.

    @da Doctah said:

    Not with an optimizing compiler, but in terms of source-code maintenance, if (false) requires a matching else {}

    Disagree with that, too - an else clause is optional. Is there some reason why an empty else{} should be added?

     



  • @Cassidy said:

    @da Doctah said:

    @discomike said:

    while (true)

    is the sign of a disordered mind.

     

    Is it?

    I thought it was a better technique to leave the loop condition as (true) and add logic to break out from within, rather than try to add an overly convoluted logic expression into the parantheses - thinking about future maintainability considerations.

    @da Doctah said:

    Not with an optimizing compiler, but in terms of source-code maintenance, if (false) requires a matching else {}

    Disagree with that, too - an else clause is optional. Is there some reason why an empty else{} should be added?

    Regarding the empty else... I dont personally follow it (nor do I recommend it), but it does cause some editing mistakes to become compiler errors that could otherwise slip through. Being rigorous about always using braces on the "then clause" is also a key element [and this is one I do endorse]



  • @TheCPUWizard said:

    Regarding the empty else... I dont personally follow it (nor do I recommend it), but it does cause some editing mistakes to become compiler errors that could otherwise slip through. Being rigorous about always using braces on the "then clause" is also a key element [and this is one I do endorse]
    Or you could just auto-indent your code.

     



  • I feel for you, brother.

    Not only is all our brownfield code much like the example you posted (well, apart from the fact our version would also include a web service called through a singleton), I'm slowly getting the feeling that all our new development is no better.

    Recent case in point, WCF JSON serialization: WCF Serializes what you give it. If you pass it a DataContract where all the properties are capitalised, the JSON you get out at the end will also be capitalised. You don't like this, so instead of annotating your properties in the DataContract with [DataMember(Name="sameNameAsPropertyButStartingWithLowerCase")] in a matter of minutes, you spend three weeks writing your own JSON Serializer from scratch (because WCF is too hard, boo hoo) and don't even bother looking for libraries like Json.net, because "3rd party libraries introduce too many dependencies into our software", despite not once having seen the mountain of dependencies your own 40+ solution projects created by making a uml diagram or using something like NDepend.



  • @Severity One said:

    @TheCPUWizard said:

    Regarding the empty else... I dont personally follow it (nor do I recommend it), but it does cause some editing mistakes to become compiler errors that could otherwise slip through. Being rigorous about always using braces on the "then clause" is also a key element [and this is one I do endorse]
    Or you could just auto-indent your code.

    And auto-indent (or any other stylistic element) influences compiler errors HOW?  Yes, "pretty" code is easier to read, but it is still a human effort. If you run a SED script against 5,000 source files, are you going to open each one and read the code? Having the compiler (or other tool in the chain) throw an error is always prefferable to somethan that depends on a person.


  • ♿ (Parody)

    @TheCPUWizard said:

    And auto-indent (or any other stylistic element) influences compiler errors HOW?

    Obviously not a fan of pythong.

    Seriously, though people who don't use braces for single statement if / for / while blocks are worse than those who always put the opening brace on a new line.



  • @boomzilla said:

    Seriously, though people who don't use braces for single statement if / for / while blocks
     

    Agreed.

    @boomzilla said:

    those who always put the opening brace on a new line.

    I found that this is so trivial that you can just get used to it.

    I've set VS to autoformat common control statement with same-line-accolades, and classes/namespaces/otherOOstuff on newline.

     


  • ♿ (Parody)

    @dhromed said:

    @boomzilla said:
    those who always put the opening brace on a new line.

    I found that this is so trivial that you can just get used to it.

    Nooooooo!!!!! Never give up! Never surrender!



  • The problem is getting permission to "fix" code like that gets met with "but it isn't broken, and if it ain't broke don't fix it..." usually with some lecture about how "risky" it is, as you don't know what kinds of bugs you might introduce plus the fact that the entire testing team (usually wrongly called QA) will have to fully test the entire system due to your change.

     

     



  • @boomzilla said:

    @dhromed said:
    @boomzilla said:
    those who always put the opening brace on a new line.
    I found that this is so trivial that you can just get used to it.

    Nooooooo!!!!! Never give up! Never surrender!

    Sorry, I am firmly in the camp that braces never* go on the same line as code.

     * exclusion for rare cases where there is a long list of items each with a conditional and a signel statement. Braces stilll used but everything on one line.



  • Unless you're writing in Javascript, where indent style actually changes the program's behaviour.



  • @boomzilla said:

    Nooooooo!!!!! Never give up! Never surrender!

    if ("you can keep your head when all about you"
        "are losing theirs and blaming it on you")
    {
        if ("you can trust yourself when all men doubt you"
            "but make allowance for their doubting too")
        {
            if ("you can wait and not be tired by waiting"
                || "being lied about, don't deal in lies"
                || "being hated, don't give way to hating"
                && "yet don't look too good, nor talk too wise")
            {
                if ("you can dream" && "not make dreams your master")
                {
                    if ("you can think" && "not make thoughts your aim")
                    {
                        if ("you can meet with Triumph and Disaster"
                            && "treat those two impostors just the same")
                        {
                            if ("you can bear to hear the truth you've spoken"
                                "twisted by knaves to make a trap for fools"
                                || "watch the things you gave your life to, broken"
                                && "stoop and build 'em up with worn-out tools")
                            {
                                if ("you can make one heap of all your winnings"
                                    && "risk it on one turn of pitch-and-toss"
                                    && "lose, and start again at your beginnings"
                                    && "never breathe a word about your loss")
                                {
                                    if ("you can force your heart and nerve and sinew"
                                        "to serve your turn long after they are gone"
                                        && "so hold on when there is nothing in you"
                                           "except the Will which says to them: 'Hold on!'")
                                    {
                                        if ("you can talk with crowds and keep your virtue"
                                            || "walk with Kings - nor lose the common touch")
                                        {
                                            if ("neither foes nor loving friends can hurt you")
                                            {
                                                if ("all men count with you, but none too much")
                                                {
                                                    if ("you can fill the unforgiving minute"
                                                        "with sixty seconds' worth of distance run")
                                                    {
                                                        "Yours is the Earth and everything that's in it"
                                                        && "which is more - you'll be a Man, my son!";
    }   }   }   }   }   }   }   }   }   }   }   }   }


  • @Salamander said:

    Unless you're writing in Javascript, where indent style actually changes the program's behaviour.

     

    wut?

    I thingk you're also thingking of pythong.

     



  • @dhromed said:

    @Salamander said:

    Unless you're writing in Javascript, where indent style actually changes the program's behaviour.

     

    wut?

    I thingk you're also thingking of pythong.

     

    return { // return an object
    
    prop1: val1,
    
    prop2: val2
    

    }

    // vs

    return // semicolon insertion at EOL means you return undefined. nyah nyah!

    { // an object literal non-statement

    prop1: val1,
    
    prop2: val2
    

    }

     

    I think CoffeeScript is a bad idea, btw. Though I haven't really tried it at all.



  • Wait... does choice of where to put new lines count as indentation style?



  • I can't really test your claim as-is, as the your second return is a syntax error, for reasons I cannot fathom.

    When I add "foo =" to the opening accolade, JS does indeed slam a ; after the return statement and the thing returns undefined.

    Of course, observing this fact doesn't mean there's an actual problem, because no sane individual would type return, and put the returning statement on a new line. So if it breaks, it's because the programmer is stupid, not because ;insertion is stupid.

     

    @Zecc said:

    I think CoffeeScript is a bad idea, btw.

    I'm not sure. Is your problem philosophical, like C(++)* might be a bad idea because then programmers won't learn how to write proper, original Assembly?

    Or because Coffeescript is just shit on its own antimerits?

     

     

     

    *) this is your cue for C syntax jokes.*


  • ♿ (Parody)

    @dhromed said:

    Of course, observing this fact doesn't mean there's an actual problem, because no sane individual would type return, and put the returning statement on a new line. So if it breaks, it's because the programmer is stupid, not because ;insertion is stupid.

    I'm not defending the programmer who does that, but semi-colon insertion seems stupid. The language should either require them or not. And if you're going to allow statements to span multiple lines, you either allow that to happen or you provide a line continuation character (blech).

    What about more complex expressions that might benefit from spreading over multiple lines? OK, you could do the calculation before and store in a variable, etc, etc, but I cannot defend semi-colon insertion.



  • @dhromed said:

    I can't really test your claim as-is, as the your second return is a syntax error, for reasons I cannot fathom.
    It was just a quick example I wrote, I hadn't actually run it. "invalid label", says Firebug. Strange.

    @dhromed said:

    Of course, observing this fact doesn't mean there's an actual problem, because no sane individual would type return, and put the returning statement on a new line. So if it breaks, it's because the programmer is stupid, not because ;insertion is stupid.
    I agree.

    @dhromed said:

    I'm not sure. Is your problem philosophical, like C(++)* might be a bad idea because then programmers won't learn how to write proper, original Assembly?

    Or because Coffeescript is just shit on its own antimerits?

    I dunno. Like I said, I haven't really used it.

    But in example code I have seen on the web I find its syntax... uneasing.

    Like it's creators thought "look what I can write being terse and avoiding extraneous punctuation",
    and I'm thinking "but I like punctuation! Punctuation makes the code more readable when used appropriately."

    Here's a borrowed example:

    widget =
      attach: ->
        el.bind 'click', (event) =>
          doStuffWithThis()

    What the hell is that? Oh wait.. here's a better version. Still pushing it, but easier to digest:

    var widget = {
      attach: function () {
        this.el.bind('click', $.proxy(function (event) {
          doStuffWithThis();
        }, this));
      }
    };

    Another borrowed example (nasty!):

    doSomething () ->  'hello'
    doSomething(function() {
      return 'hello';
    });
    doSomething() ->  'hello'
    doSomething()(function() {
      return 'hello';
    });

     

    I think it's like blakeyrat's opinion on the ternary operator: it allows for bad programmers to more easily write bad code.
    I guess I have a general distaste for omitting parenthesis and braces.

     




  • @dhromed said:

    @Salamander said:
    Unless you're writing in Javascript, where indent style actually changes the program's behaviour.
    wut?

    I thingk you're also thingking of pythong.

    I really want to know what the crap Salamander is talking about.



  •  Nice, @flabdablet. I didn't realize Kipling was a programmer.  ;-)



  • @TheCPUWizard said:

    Regarding the empty else... I dont personally follow it (nor do I recommend it), but it does cause some editing mistakes to become compiler errors that could otherwise slip through. Being rigorous about always using braces on the "then clause" is also a key element [and this is one I do endorse]

    Endorse it or not, it is simply a style thing mostly making no difference to code and simply changing it because you don't like it makes things more complicated when you start lerging multiple changes back into the main branch. What is really a change and what is just a pedantic modification?



  • @KattMan said:

    <snip>...and simply changing it because you don't like it makes things more complicated when you start lerging multiple changes back into the main branch. What is really a change and what is just a pedantic modification?

    KatMan, 100%++ agreement there. "drive-by" coding [making changes to existing source that is not directly related to the immediate taks] can be a real problem. A few years ago, I had one client where it was totally out of hand. Over 50% of their commits (counted as individual files) consisted of changes made that were purely stylistic [i.e. the original and modified code produced the same compilation result].



  • @boomzilla said:

    The language should either require [semicolons] or not.
     

    Agreed.

    @boomzilla said:

    a line continuation character (blech).
     

    YESSS

    @boomzilla said:

    What about more complex expressions that might benefit from spreading over multiple lines?

    I have never, ever been in a situation where semicolon insertion in Javascript has inescapably foiled my attempts to make code readable by using multiline statements. Not once, not ever. Until I see reasonable evidence to the contrary, my claim is that it doesn't happen.

    The return { example is contrived and not representative of real-world code. If such rare code is found, the problem is with the programmer, not the (mis)features of the language.

     

     



  • @Zecc said:

    Another borrowed example (nasty!):

    doSomething () ->  'hello'
    doSomething(function() {
      return 'hello';
    });
    doSomething() ->  'hello'
    doSomething()(function() {
      return 'hello';
    });

     

     

    Holy fuck. What the hell is that. Coffeescript is clearly an elaborate joke to troll the programming world, but somehow nobody noticed.

     


  • ♿ (Parody)

    @dhromed said:

    @boomzilla said:
    What about more complex expressions that might benefit from spreading over multiple lines?

    I have never, ever been in a situation where semicolon insertion in Javascript has inescapably foiled my attempts to make code readable by using multiline statements. Not once, not ever. Until I see reasonable evidence to the contrary, my claim is that it doesn't happen.

    The return { example is contrived and not representative of real-world code. If such rare code is found, the problem is with the programmer, not the (mis)features of the language.

    My javascript experience is fairly trivial, and I'm not afraid to admit this perceived problem may not be as bad as it looks. But it doesn't look real good.



  • @boomzilla said:

    My javascript experience is fairly trivial, and I'm not afraid to admit this perceived problem may not be as bad as it looks. But it doesn't look real good.
     

    I remember a version of Bootstrap broke because it relied on a superobscure quirk of semicolon insertion to save space, and when that was minified, it broke and the author of js.min was like Fuck you use fucking semicolons and the Bootstrap guy was like Fuck you it's a valid feature of the language and your minifier should be as transparent as possible ARRRGH PISTOLS AT DAWN. 


  • Discourse touched me in a no-no place

    @dhromed said:

    I remember a version of Bootstrap broke because it relied on a superobscure quirk of semicolon insertion to save space, and when that was minified, it broke and the author of js.min was like Fuck you use fucking semicolons and the Bootstrap guy was like Fuck you it's a valid feature of the language and your minifier should be as transparent as possible ARRRGH PISTOLS AT DAWN. 
    https://github.com/twitter/bootstrap/issues/3057?

    @fat said:

    @douglascrockford said:
    @douglascrockford said:
    That is insanely stupid code. I am not going to dumb down JSMin for this case.
    TC39 is considering the use of ! as an infix operator. This code will break in the future. Fix it now. Learn to use semicolons properly. ! is not intended to be a statement separator. ; is.
    i have learned to use them, that's why there isn't one present.



  •  Pistols!



  • @dhromed said:

    @boomzilla said:

    a line continuation character (blech).
     

    YESSS

    Bonus points if it's non-printable. Like <font face="courier new,courier">\r</font>

    @dhromed said:

    The return { example is contrived and not representative of real-world code. If such rare code is found, the problem is with the programmer, not the (mis)features of the language.
    I agree.

     

     


  • ♿ (Parody)

    @PJH said:

    https://github.com/twitter/bootstrap/issues/3057?

    @fat said:

    @douglascrockford said:
    @douglascrockford said:
    That is insanely stupid code. I am not going to dumb down JSMin for this case.
    TC39 is considering the use of ! as an infix operator. This code will break in the future. Fix it now. Learn to use semicolons properly. ! is not intended to be a statement separator. ; is.

    i have learned to use them in order to abuse everyone who reads my code, that's why there isn't one present.

    FTFF

    Seriously, this kind of nonsense is like someone intentionally switching between leopard prints and solids tabs and spaces in pythong.



  • @Zecc said:

    @dhromed said:
    The return { example is contrived and not representative of real-world code. If such rare code is found, the problem is with the programmer, not the (mis)features of the language.
    I agree.
     

    You can't agree twice to the same thing, you ass-kisser.



  • @cscastle said:

    I didn't realize Kipling was a programmer.

    Take up the whitespace burden--
    Have done with childish days--
    Implicit semicolons,
    The lazy, ill-placed brace.
    Comes now, to grep your source files
    Through all the thankless years
    Cold, edged with dear-bought wisdom,
    The judgment of your peers!



  • @flabdablet said:

    @cscastle said:
    I didn't realize Kipling was a programmer.

    Take up the whitespace burden--
    Have done with childish days--
    Implicit semicolons,
    The lazy, ill-placed brace.
    Comes now, to grep your source files
    Through all the thankless years
    Cold, edged with dear-bought wisdom,
    The judgment of your peers!

     

    +1 wba

     



  • @dhromed said:

    @Zecc said:

    @dhromed said:
    The return { example is contrived and not representative of real-world code. If such rare code is found, the problem is with the programmer, not the (mis)features of the language.
    I agree.
     

    You can't agree twice to the same thing, you ass-kisser.

    Where have I agreed twice?

     



  • @Zecc said:

    @dhromed said:

    @Zecc said:

    @dhromed said:
    The return { example is contrived and not representative of real-world code. If such rare code is found, the problem is with the programmer, not the (mis)features of the language.
    I agree.
     

    You can't agree twice to the same thing, you ass-kisser.

    Where have I agreed twice?
     

    Here:

    @Zecc said:

    @dhromed said:
    Of course, observing this fact doesn't mean there's an actual problem, because no sane individual would type return, and put the returning statement on a new line. So if it breaks, it's because the programmer is stupid, not because ;insertion is stupid.
    I agree.

    I'm flattered, of course.

     



  • @Cbuttius said:

    the entire testing team (usually wrongly called QA)
     

    Eh?

    Testing is a QA activity.

    Unless you mean that they're called QA but all they do is testing, then I'll agree on that front.



  • @Cassidy said:

    @Cbuttius said:

    the entire testing team (usually wrongly called QA)
     

    Eh?

    Testing is a QA activity.

    Unless you mean that they're called QA but all they do is testing, then I'll agree on that front.

     Yes that is exactly what I mean.



  • @TheCPUWizard said:

    @Severity One said:
    [quote user="TheCPUWizard"]Regarding the empty else... I dont personally follow it (nor do I recommend it), but it does cause some editing mistakes to become compiler errors that could otherwise slip through. Being rigorous about always using braces on the "then clause" is also a key element [and this is one I do endorse]
    Or you could just auto-indent your code.
    And auto-indent (or any other stylistic element) influences compiler errors HOW?  Yes, "pretty" code is easier to read, but it is still a human effort. If you run a SED script against 5,000 source files, are you going to open each one and read the code? Having the compiler (or other tool in the chain) throw an error is always prefferable to somethan that depends on a person.[/quote]I dont know how they do things where you work, but where I work, we find an IDE easier when it comes to writing code than sed.

    This code has to be written at some point. Write it properly, press Alt+Shift+F or whatever else you need to reformat, and silly mistakes stemming from indenting quickly become obvious.

    @boomzilla said:

    @TheCPUWizard said:
    And auto-indent (or any other stylistic element) influences compiler errors HOW?
    Obviously not a fan of pythong.

    Seriously, though people who don't use braces for single statement if / for / while blocks are worse than those who always put the opening brace on a new line.

    Well, I must be very bad then, because I leave out braces for single-statements blocks, andput the braces on a new line.

    Discussions about coding style are about as useful as discussions that the Big Endians and Little Endians had in Gulliver's Travels. There's not one style that is "best", because I find excessive use of braces, and especially putting the opening brace in a different column than the closing brace, impossible to read.

    Does that mean that I'm mad? Quite possibly, but I find that I work better if I format code in that particular way. And because Netbeans quite happily formats code in whatever way you want, even adding braces for single-statement blocks, it's not a problem either that my colleagues prefer the style that you do.

    It's just the way my mind works, which is very much in a visual way. For me, an 'if' and '}' don't have anything to do with one another, but a '{' and '}' do.


  • ♿ (Parody)

    @Severity One said:

    And because Netbeans quite happily formats code in whatever way you want, even adding braces for single-statement blocks, it's not a problem either that my colleagues prefer the style that you do.

    Except that it's not just a style issue. It's a readability and maintenance issue. If you're lucky, it's a relatively big problem in your code base, though usually not. I also find it nicer to simply be consistent. The fewer surprises you get reading code the better.

    @Severity One said:

    It's just the way my mind works, which is very much in a visual way. For me, an 'if' and '}' don't have anything to do with one another, but a '{' and '}' do.

    I'm not sure what your point is here. Do " 'if' and '}'" have anything to do with each other for anyone? Maybe people who like compiler errors?



  • @boomzilla said:

    I'm not sure what your point is here. Do " 'if' and '}'" have anything to do with each other for anyone?
     

    He just wants { and } to be aligned vertically. It's an okay point, but there's no reason why one couldn't get used to the same-line style (apart from forced rationalizations about being a visual person (irrelevant) or finding X "impossible" to read (a lie)). It just doesn't matter one bit.


Log in to reply