Analyze Project

Real Studio has an Analyze Project function that scans your project for a variety of things and reports on them.  It checks for unused local variables, unused event parameters, and unused method parameters, to name a few.  It also checks for deprecated method calls in addition to checking for true compiler errors.

I hate to say it, but who cares?  Except for the deprecated methods check I don’t find many of these tests to be all that useful.  I checked with Seth and he doesn’t use it very often (he said rarely) either.  Are we being bad Real Studio developers?

Over the years I’ve worked on projects with outside developers.  Some of them are very vigilant (i.e. OCD) about analyzing their projects and, by golly, if there’s one single item in the list they have to get rid of it.  To me it’s over the top and, if not a huge waste of time, it’s not an efficient use of it.

Don’t get me wrong.  Knowing if you have unused local variables *IS* useful.  Deprecated items *IS* useful.  Unused event or method parameters?  Not so much.  I suppose there is *some* compiler advantages but it seems minor at best and certainly not worth the effort.

So my question for you, dear readers, is this:  Are you obsessive about Analyze Project?  Or do you even care?  If so, why is it so important to you?

Happy coding!

18 thoughts on “Analyze Project

  1. As a career software/systems QA engineer I have to say that I am in the “always analyze” camp. But that doesn’t mean “always fix”. Part of testing (the part many engineers and test people miss) is determining if/where a product will break. Knowing it works is not enough.

    Analyzing helps determine where things MAY go wrong, and it’s better to know, even if the decision is to not fix it, than to be surprised by a customer’s call.

  2. I find it quite useful during refactoring, when it’s quite easy to overlook an unused parameter. I also tend to use it for unused local variables which perhaps is somewhat OCD these days, but a lot of my programming habits date back to when every byte of memory counted.

  3. If you’re not interested in a warning, like unused parameters, you can turn it off in Project > Warnings…

    I use Analyze when I’ve written some code and want to double check it before moving on, easier than a debug run to find out. An amazing improvement would be code validation as you type.

  4. Well, I don’t use it too often. And actually I don’t care for extra variables or unused parameters. The compiler could optimize them away.
    There are things the analyzer should warn about like floating point numbers as counter in for loops, warn about framework functions which cause exceptions where we don’t catch them and warn about functions which often return nil so we need to handle it.

  5. I would submit that keeping your code clean and tidy is absolutely *not* a waste of time. It might *seem* like it 30 minutes or a few days after you just wrote it, but think when you go back to it in 6 months from now – you’ll see that unused variable and spend a few seconds or a minute wondering what it does. What if a different developer has to maintain the code – he’ll likely spend a bit more time investigating. That stuff adds up. It’s noise, it’s mind-clutter.

    Lastly, some of the warnings might be minor (eg. unused variable), but others might not be and might point to a subtle bug – but if it’s buried in a slew of minor warnings, you might overlook it.

    I most definitely think it’s not a waste of time, and I insist my devteam clean up all those things before they commit the code. My 2c (based on 20 years of experience).

  6. @Phil
    I never said anything about keeping code ‘clean and tidy’. Analyze project really has nothing to do with that other than finding some unused local variables.

    The reason this came up is that some complained that Analyze project on the ActiveRecord classes found “errors when I analyze the project.” So I ran it and found a dozen items. 2 were unused variables, 4 or 5 were unused parameters. The rest were false positives errors.

    It was not a good use of my time as they didn’t change the project even in the slightest aspect. I would argue it wasted my time because of the false positives.

  7. S-Copinger :

    I find it quite useful during refactoring, when it’s quite easy to overlook an unused parameter. I also tend to use it for unused local variables which perhaps is somewhat OCD these days, but a lot of my programming habits date back to when every byte of memory counted.

    I tend to use it when I’m refactoring or looking for ways to speed up a particularly slow bit of code. In that case I use it in conjunction with RB Code Reports to look at code complexity and the other things that RB Code Reports looks at.

  8. Bob Keeney :
    @Phil
    I never said anything about keeping code ‘clean and tidy’. Analyze project really has nothing to do with that other than finding some unused local variables.
    The reason this came up is that some complained that Analyze project on the ActiveRecord classes found “errors when I analyze the project.” So I ran it and found a dozen items. 2 were unused variables, 4 or 5 were unused parameters. .

    FYI:

    I just rans across something today I did not know existed:

    #PRAGMA Unused VariableName

    That will suppress the unused variable warning for parameters when using Analyze Project.

    You might just want to use that in your code to help avoid such complaints.

    – karen

  9. I always like to be informed when I’ve forgotten to make use of a parameter in one of my functions, but I usually don’t like to be reminded about unused parameters in the built-in event handlers. That happens a lot with the canvas paint events, which have an areas() parameter that tells you which region of the canvas really need to be redrawn. But I can be convinced to start making use of it if the code analyzer keeps pestering me about it 🙂

  10. I really love the analyze feature in Xcode/clang. Works nice to find bugs in our plugin code.
    But for that RS would need to spend some more work on this to add a couple of real tests.
    Like this:
    dim x as integer
    dim y as integer = 5/x
    where you can detect x being zero and this gives a divide by zero.
    or
    dim n as window
    n.show
    where you can detect that n is nil always.
    Maybe this could be added with going to LLVM?

  11. It may help to think of Analyze Project in a different light: it’s the compiler’s way of saying “this code is making me guess, and whenever I guess, I may guess wrong.” So it’s not going to tell you things that are hard-and-fast — that’s what error reporting is for. Instead, it’s going to tell you things that may be right, or it may be wrong, and the compiler is going to pick one for you.

    Sometimes this is benign, like unused things (that’s the compiler saying “did you forget to do something with this?”). Other times it’s less benign, like mismatched types (that’s the compiler saying “I am going to make these types match at some point, and you may not like the results.”).

  12. talking about possible enhancements to the Analyze Project feature, I’d love to see a warning if one forget to return a value in a function – this would be a lot more valuable to me as the warning of unused event/method parameters for example. There is already a FR for this:
    In daily use, I hit cmd-k quite a lot, and cmd-shift-k even more, mainly to quickly check the current method for compile errors without a full compile and debug run. The warnings about unused parameters I do normally ignore or hide, but its unfortunately not possible to save that selection of displayed / hidden warnings.

  13. @Tobias
    I looked into implementing that one once, and it’s surprisingly difficult to do in a meaningful fashion because you need something which can analyze flow control better than what RB is currently capable of. For instance, if you have code that looks like this:

    Function f() as Boolean
    if true then return true
    End Function

    The compiler needs to understand that this function DOES always return a value, even though there’s the implicit fallthrough for the if and no terminating return statement.

    What’s more, since RB is documented as returning a default value, I could see this being overly chatty (then again, shutting the warning up is easy — return a value!).

  14. Certainly this is a must-have feature. Take Xcode for example. If RB is understaffed it’s understandable to have this removed but it’d be a shame.

    RB should nonetheless try its best to make the product better over time instead of going backward.

  15. @Aaron Ballman
    I totally understand that for properly warn of missing return values, the analyzer would need to understand the code flow way deeper than it does currently. This is why I limited the request to warn of not using the return keyword *at all*. You can see this similar to the warning of unused method parameters. The warning will only be put out if you not use it at all. Things like

    Function KeyDown(Key As String) As Boolean
    if false then
    msgbox key
    end if
    End Function

    will not generate the warning just as your example on return values could let to false-negative warnings as well.

Comments are closed.