• (nodebb)

    And here we see the frist principle of all commercial software development: Have clueless managers hire or rpomote clueless leads. The rest is just details.

    What a great way to start our days, not Barry & Stu's day.

  • Jonathan (unregistered)

    In my early days of programming I lost hours on a hobby project where I was tweaking someone else's JavaScript code for something and the lack of braces caught me out in a similar way, since then I also spot this problem instantly.

    I have to wonder if Barry had a similar painful past experience that made it quick for him to spot or maybe even myself at my point of experience now would also spot this super quickly.

  • Kevin M (unregistered)

    This is obvious right, that the code from Stu does not do the same thing?

  • Tim (unregistered)

    Since the new bug affects everything except product 3, it seems to me as if the new version wasn't tested at all. QA needs to bear some responsibility here as well.

  • Tim (unregistered)

    Since the new bug affects everything except product 3, it seems to me as if the new version wasn't tested at all. QA needs to bear some responsibility here as well.

  • Darren (unregistered)

    Dev breaks something.

    Dev feigns illness, but lets everyone see their dedication to the cause and how much of a company-player they are by rising from their deathbed to provide a fix.

    Dev get praise for fixing the issue by management.

    It's a tale as old as time.

  • (nodebb)

    I'm waiting for someone to Spot The Language --- in this case, which programming language actually considers white space indenting as meaningful, and Stu's original code would work?

  • (nodebb) in reply to Kevin M

    This is obvious right, that the code from Stu does not do the same thing?

    I think that depends on the implementation of each IsProductx(). If more than one could return true for the same product id, then you are correct. Also, if there are side effects...

  • (nodebb)

    This reminds me of my favourite if related WTF that I discovered in a colleague's C code 27 years ago:

    if (condition);
    somethingThatShouldOnlyHappenIfCondition();

    It probably produced a warning, but the code in question spewed hundreds of compiler warnings.

  • (nodebb) in reply to dpm

    Python, but that has colons at the end of if conditions:

    if condition:
    do_thing();
    do_other_thing();
  • (nodebb)

    Who is worse, the lead who wrote this, or the manager who promoted/hired him?

  • (nodebb)

    Back in the COBOL days, there was a shift from ending each statement with a period to ending a block of statements with a period. Spotting a missing bracket is one thing...spotting an errant period was a joy unto itself.

  • (nodebb)

    After the Apple SSL bug, all of the major C compilers implemented warnings for this kind of construct. I would be surprised if the C# compiler doesn't have such a thing. I would not be surprised if those warnings aren't being used on this project. Or any warnings.

  • TrueWill (unregistered)

    I love these "story" articles. Thank you!

    There's a reason for compiler warnings...

  • sudgy (unregistered)

    This is why I never use this construct. If the body of the if statement doesn't fit on the same line as the if statement itself, I will always use braces. No exceptions.

  • (nodebb) in reply to thaines.astro

    The C# compiler itself doesn't have stylistic rules for if block braces, but you can write an analyzer using their Roslyn API (or find one that already exists) which enforces rules just like this. I've written an analyzer which is somewhat more complicated and I can confidently state that the brace style analyzer would be super easy to write. (Again, high chance one already exists.)

    Addendum 2025-03-27 15:15: PS. I just went and checked - Visual Studio has a built-in style analyzer (not part of the C# compiler) which you can configure to complain about braceless if blocks, up to and including as "errors" (even if it's not a language error). So, you don't even have to look for it online - you already have it if you have Visual Studio.

  • Officer Johnny Holzkopf (unregistered) in reply to TrueWill

    The reason for compiler warnings is that a programmer is allowed to ignore them. Options like -Wall and treating warnings as actual errors just slows down code production and feature shipping, so send them to /dev/null and declare bugs as "cannot reproduce, case closed", enabling a faster app output...

  • (nodebb)

    My personal pet peeve are people who ignore the {} around blocks even if they are a single line.

    Single lines have a habit of becoming multi-line blocks, and not putting {} after an if statement is loading a footgun to go off some time later.

    I always put in the braces in my code. The only time I don't is when I'm debugging something and had to put it in so I could do like a printf(), but then remove it to minimize code changes.

  • Daniel (unregistered)

    I remember my first C# book that really put this on the line with an ongoing joke: For every chapter there was a small quiz about the stuff in the chapter. Whenever there was something with braces there inevitable were multiple question about "what happens in this case" (without any braces in the code) and there always was one additional response (that was always correct): "In case I put braces there I don't have to worry about that".

  • luqman (unregistered)
    Comment held for moderation.
  • Ingedient X (unregistered) in reply to Worf
    Comment held for moderation.

Leave a comment on “A Bracing Way to Start the Day”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article