One of my favorite new features of 2008r3 is definitely the "warning" system. I believe that it's going to help people to understand the more hairy spots in their code base, and do so in an unintrusive fashion.
My big beef with the way most compilers handle warnings is that they're always in your face. If you're starting a project from scratch, it's not that big of a deal. But if you're jumping into the middle of a code base that you inherit, it's actually terrible -- it causes you to ignore warnings, which could very well point out bugs in your code! Studies have shown that when the user is confronted with too many warnings, they generally ignore them. Sometimes this can be a simple matter of not looking at them. Other times, it can mean physically setting a preference that says "don't show me warnings." No matter how it happens, the result is the same: important information is lost.
Because of this, the warning system in REALbasic takes a slightly different approach. If you hit Run or Build, the assumption is that the programmer doesn't care that much about warnings. They're more interested in debugging or releasing their application, and that's the wrong time to pester them about warnings. Instead, we repurposed the "Check Project" menu items to be "Analyze Project." When the user wants to check their project for errors, what they're really saying is: "what problems are there?" Previously, the only problems that were reported to you were compile errors that you had to fix in order to proceed. Now there's a new class of problems reported to you: warnings.
Warnings are code issues which the programmer may not be aware of, but aren't exactly problems. The code could be right, or it could be wrong -- the compiler can't definitively say one way or the other. These warnings, along with errors, are what get reported to you when you analyze your project. In 2008r3, the only warnings that are displayed to you are deprecations (well, this isn't entirely true -- unknown pragmas changed from an error to a warning, and old-style constructors are now warned about as well). However, future versions of REALbasic will continue to add more and more warning heuristics to the compiler to report various other problems. For instance: implicit type conversions which can cause data loss, floating-point equality tests, and unused code items are all prime candidates for warnings.
I should note that the behavior of Check Project has been modified while being repurposed. It used to be that the only issues to report back to you were compile errors. Because of that, we could use incremental compilation without worrying about user expectations. If you got an error, then the whole project would have to be recompiled on a subsequent check. However, with warnings, it's a bit more fuzzy of a problem -- imagine taking an existing project, analyzing it and getting 100 warnings (no errors). So you fix the first warning, and analyze the project again. Your expectation is that you'll now get 99 warnings, but if we incrementally compiled the project, chances are likely that you'd get a number much smaller than 99. So analyzing a project will always recompile the entire project so that it can continue to always report issues accurately.
I certainly have my ideas of what sort of issues would be good to report via the warning system, but I'm curious to know what sort of issues you'd like to see reported. Keep in mind that some things are very easy for the compiler to alert you to, and other things are very hard. So don't be disheartened if I say "oooh, probably won't happen." ;-) But I'm still curious to hear your thoughts on what issues should be reported.
the warning system is a welcome addition, but as one who - religiously uses CMD K just to instinctively and religiously check for obvious syntax errors as we go, I now find that things take much longer. I realise its against your way of thinking but couldnt we have a seperate menu/keyboard combination for just doing basic syntax checking ? It used to be so fast and things are a lot slower now.
@Dan -- You can still use Cmd+Shift+K (or is it Opt on the Mac? I forget.) to analyze just the current item instead of the entire project.
I think the issue with the current design is that it requires people to use Check Project to even know there are warnings. Check Project isn't a feature that I use because I always want the project to run so my unit tests will execute. It took me a while to figure out what deprecation warning people were talking about on the beta list and how to see them.
If RS is only going to use this model to highlight deprecations, etc, ... then I think you're going to end up with many are never going to see them. That leads to upset people when those deprecated features are removed (not that that doesn't happen anyway).
The challenge I guess is that every other development tool I've ever used reports warnings during compile so I assume that if my build doesn't report anything then I'm good. Having RB be the odd man out makes switching to it that much harder. I'm not sure that this feature isn't designed for the few as opposed to the many.
On the topic of this that should be reported, unused variables, unreachable code, uninitialized variables, ... really all the things other development tools report while building. There should be UI to control which warnings are displayed. This latter is key because right now our project shows a ton of deprecation warnings making the feature almost useless.
@Chris -- yes, REALbasic is the odd man out when it comes to showing warnings to the user. But that's not a bad thing, IMO. Here's a good "for instance" as to why. I added some warnings for a future release to warn about implicit type conversions that can cause data loss, and type comparisons which may behave unexpectedly. I did an Analyze Project on the IDE and got almost 600 warnings. If I saw those warnings every time I compiled, I'd just try to find a preference to shut them off -- it's too much information, and there's no way I'm going to tackle those all at once.
Uninitialized variable warnings is really quite hard because all variables in REALbasic are guaranteed to be Null/0/Empty String/False/etc. So there is no such thing as an uninitialized variable, which makes it hard to warn you. Unreachable code would require an optimizer to be able to analyze branches which will never be hit. I could probably make an ad hoc mechanism which works if the branch expression is a constant though, but it wouldn't be able to catch code like this:
As for the UI -- yes, I agree that some UI is needed to turn off warnings on some sort of case-by-case basis. I've not figured out what that UI will be, or how granular it'll be though.
I guess if you bury warnings they are buried not matter how you do it. I would still prefer to see a UI to control the warnings and have the warnings show up during compiles. I think that would increase the odds that people would even know they were there.
The large volume of warnings issues are caused by this being a new feature. I would hope for a new project that people would start with full warnings (perhaps even a warnings as errors option) and have their project be warning free.
Of course you're right about the unitialized variables. Too much time working in other languages makes me initialize everything.
Unreachable code is something that evolves over time. Start with the simple cases and improve from there. I think it is the kind of thing that if you wait until you can do it perfectly you will never implement it. I think this is true of most things.
Very cool. Perhaps I'll actually use this feature now. :)
I definitely like the new warnings feature, but I'm with Dan on this one. I miss having Cmd-K just check syntax without doing a full recompile. I know I can use Shift-Cmd-K to just check the item, but oftentimes I'll change some code in a variety of places (all related to a single feature) and want to check syntax on all those areas without forcing a complete recompile.
I guess I'm saying I'd like to see a separate option for "Syntax Check" and one for "Analyze Project".
Of course, if you want to add background compilation to check syntax that would be even better :-)