The Analyze Project command (and its sibling, Analyze Item) is a relatively new piece of functionality which has taken over the old "Check Project for Errors" functionality. It continues to check your projects for errors, but packs an extra punch. Some people (myself included) erroneously refer to it as a "warning system" because that's what it appears to do. 2008r4 continues with this trend by showing you some very common warnings that will feel familiar to you if you've come from other languages. However, as I said, it's not correct to think of it as strictly a warning system. It will certainly warn you about things you might not otherwise notice, like implicit numeric conversions. But it's true purpose is to help you write more correct code.
The best way to think about Analyze Project is with a silly little anecdote. When you select that menu item, what you should envision in your mind is that you've packaged your project up and sent it to a little gnome (who is under a strict NDA). That little gnome is the best REALbasic programmer in the world, and the most nit-picky entity you will ever encounter. Ever. The gnome is pouring over your code and finding each and every place that you could do better. At the end of checking your project over, the gnome makes a full report and the IDE displays it for you. I told you it was a silly anecdote, but it's still a reasonable metaphor. Analyze project is meant to help you write more correct code. Note that I said more correct, and not "better." Better is a relative term. To some people, it's perfectly acceptable to rely on side effects instead of being explicit so long as it gets the job done (such as with implicit numeric conversions). This is a perfectly reasonable way of thinking since it tends to make more readable code under certain circumstances. However, the compiler cannot verify that it's correct either (it can only assume).
Thankfully, as more and more warning-like items get added to Analyze Project, there become less and less of them to report. That leaves time for the more truly interesting pieces of feedback for our little gnome to report on. This is where "better" and "more correct" start to see eye to eye. One of the future improvements I'd love to see made is an indication that you can encapsulate members better. If you have a method that's marked as Public in a class, but the method is only ever access by the class itself, it'd be great for the compiler to tell you that! So hopefully someday, you'll start to see issues like "Foobar is marked as Public, but is only requires Private scope."
Refactoring patterns is a major avenue I'd like to see this feature take in the future. Doing things like telling you about scoping rules is relatively easy to accomplish given the current technology the compiler has (though it's still isn't trivial). But that's just the tip of the iceberg. It'd be great if it could tell you how to decouple classes, or make better use of interfaces, etc. Basically, my ideal Analyze Project should be grabbing pages out of Fowler's Refactoring book and report them back to you. What's more, it should have a very easy way for you to select an item from the list and say "fix this for me please." After all, computers are supposed to make my life easier!
Keep in mind that Analyze Project is still in its infancy. However, it's going to be growing up little by little with each release both in terms of its interface and in terms of its functionality. So don't be too surprised when each new release finds a bunch of new items for you to work on. The purpose of this feature is to show you all the places you can improve your code, and we're planning on making a smarter gnome with each release. ;-)
I question the reasoning for putting this into the IDE and not as separate 'add-on' or utility. It seems like some fairly severe project bloat for something that while useful, has a limited number of people that would use it the way you want them to use it.
I think I'd prefer that you guys put the hooks into the IDE so the community can come up with their own solutions. I can think of a number of projects like Reality Check that have already attempted to do this work but have been stymied by the lack of hooks into the IDE, no documentation for the project file formats, limited IDE scripting and limited shell scripting.
Don't get me wrong, I *LIKE* the direction you're going with analyze project, but there are interested parties in developing their own solutions. And you don't have to be everything for everybody. I'd prefer an approach that lets us developers create our own solutions in addition to your own. My guess is that a partnership like that could really produce some awesome stuff - probably most of which would be open source.
Thanks for the article, Aaron,
Well, what you're proposing sounds great and it would lead to better code-writing, but please remember to make those items that are non-critical 'nags' optional.
I'm not a grumpy gus or anything, but if you have a huge project and you knowingly use less-than-correct code to solve certain problems (workarounds are an old companion to long-time RB users), you'd probably want to reduce that little gnome to roadkill after wading through dozens or even hundreds of non-critical items littering the Analyze Project listing. Again, I see the need for such a feature and think it would be great...just give us an 'off switch' when necessary.
Having the option to disable things like that would make users happier, and we wouldn't have to take so many blood-pressure meds. ;-) I'm still smarting from the fact that code-folding was forced on us and we were given no way to disable it, but apparently I'm the only one in the universe who doesn't use it. :P
Thanks again, Aaron, and hope you're feeling better.
As it happens, I've been having trouble with your incredible Windows Functionality Suite when using RB 2008r4. Analyze Project finds 66 "issues", and the Windows Functionality Suite project won't compile at all. Your delight in the Analyze Project features is rich with irony...;)
I haven't gotten far enough to try my own project on it, no doubt I'll have a lot of work to do!
- John
@John -- I've not updated the WFS in a long time. I'm aware of the compile errors and current shortcomings, but just haven't really had the incentive to put together a new release. No irony involved, just apathy. :-P
The only serious problem with WFS and 2008r4 is that uses BitwiseAnd, which causes crashes on compiled applications. I'm going to try some workarounds today, we'll see how my coding skills are this morning!
Those are some nice ideas. I use Eclipse a lot for university and work and I do really like the refactoring facilities it provides. This definitely is something that's missing in RB.
@bkeeney: I don't think that refactoring stuff should be a separate product from another vendor. Maybe features like this should just go in the pro version instead of standard/personal?
@Aaron: As for the additional analyses, have a look at the book "Object-Oriented Metrics in Practice", written by Lanza and Marinescu (ISBN: 3-540-24429-8). It contains lots of useful design heuristics and the authors do a very good job explaining the rationale behind them and show how to implement what they call "detection strategies" for the related "code smells" based on source code metrics. They do also introduce some interesting and simple source code visualization techniques which can be very handy.
@bkeeney +1
I'd be interested to hear if more RB'ers would rather RS expose the IDE or the compiler. I'd prefer the latter, then let me use my own text editor and development process.
@DeanG -- regardless of whether we exposed compiler functionality to third parties, that doesn't change anything about analyze project. It should be something RS controls for exactly the same reason as error reporting should be. We know what the language should be, and so we know what constitutes an error or not. Similarly, since we know what the language should be, we know what constitutes a best practice or not which is the purpose of Analyze Project.
Aaron,
As you already know, I think that REALbasic needs to provide an API for third-party tools, especially tools that can analyze projects and refactor, provide provide statistics, or print out an indexed copy of the source code. The lack of such an API is stifling a rich source of third-party tools for REALbasic. All you need to do is to look at the hundreds of third-party IDE plugins for Eclipse, IntelliJ IDEA, Visual Studio, and so on. I also feel that the lack of these tools is hampering the growth of REALbasic.
-Scott
Aaron
I am a new user to RB, but experienced in VB and Java. I need to monitor a serial port to log a continuous data stream. My problem is DataAvailable cannot be turned off once the serial port has connected. I want to sample the data stream, prompt for the next values (there are five distinct records that need to be prompted for)and then sample again at some given interval, say 30 sec. When I try to aggreate the first record (62 bytes at 9600) and try to move to the second record the DataAvailable keeps filling the receive buffer and eventually it overflows (I am speculating, as the app hangs and I must reboot to clear the serial port). I need to aggreate the first record, save it off and then prompt for the rest of the records. Prompting for the next record consists of sending a Chr(13) to the serial port. I have done all this but working within the DataAvailable event limits how I can control the data stream. I bought your three articles from RBLibrary and have read them, especially the "hands on Serial Programming". It gave me the idea of saving the individual records to disk so they can be parsed during the logging interval. I developed a pseudocode to describe the complete process, as follows
read the serial port parameters from the DB
do until all 5 packets received
open the serial port
read data from port until there is enough data for a complete packet
append data in serial buffer to a text file on disk
send a CR to the serial port
repeat
close serial port
start data logging interval counter
read text file from disk
parse out a single copy of each data packet
assemble and write the record of all the data packets to the DB with time date stamp
show values on screen as data and /or a graph
if Stop Logging button is clicked then exit this procedure
check interval counter
if interval has passed return to do loop
but I can not get the following code to aggreate the record properly, any suggestions would be greatly appreciated.
Sub DataAvailable()
' get data from the serial port
RecData= ""
do
dim chars_count As String = me.LookAhead
' aggrate the read data until there is at least 130 chars
if chars_count.Len > 130 then
RecData= Me.Read(130)
' write it to the edit field
efRecData.Text = RecData
end
loop until RecData > ""
' save the info to Record for parsing
RecRecord = RecData
efRecData.Text = ""
stRecRecord.Text = ""
' display the data in a edit box
efRecData.Text = RecData
stRecRecord.Text = RecRecord
RecData = ""
' send a char to move to next record from MaxSol
Serial1.Write Chr(13)
' if it is the first time through sent Chr(13) twice
if InitialCounter = 1 then
Serial1.Write Chr(13)
InitialCounter = InitialCounter+1
end if
' wait for data to be sent
Serial1.XmitWait
' delay the reading of the next message
Delay(100)