Code Indentation Density

I once worked in a VB6 shop where we had one developer insist that a tab in the code editor was 3 spaces and not 5 like the rest of us were using.  It was no big deal until someone else had to work on his code.  As it turned out, the developer left after a year and we had to extend everything he ever worked on in addition to the inevitable bug fixes.  I think we generated enough hatred for that one developer to last a lifetime because not only did we have to fix his buggy code but we had to reformat it too.

The Real Studio code editor handles indentation for you and you have no control over it.  I know some hate that but I’m okay with it.  It enforces consistency across source code so that it all reads the same.  As someone who reads and edits a lot of Other Peoples Code (OPC) I can appreciate that.

The Real Studio IDE puts in visual indicators (lines) for loops.  This is convenient but I’ve found that once I get past three layers of nested If-Then or For-Next or While loops it gets harder to read.  Perhaps that just me but I suspect that others have the same issue.

Take this first (totally contrived and nonensensical) example:

Real StudioScreenSnapz001

 

It’s not an exceptionally hard method to figure out.  First we check that our array has content.  Then if we have only one item we do something and if we have more than one we iterate through them and do some processing and finally return true.

Towards the bottom of the method where we’re using the For Next loop to process the items I find myself having to highlight the loop so I can visually keep it straight in my mind.  I decided to rewrite it a bit to the following:

Real StudioScreenSnapz002

The only difference is that I immediately bail and return from the method if I have nothing in my array.  It cuts down on my indention nesting by one level ands thus makes it easier to read (in my opinion).

This got me thinking about what else I could do to reduce the indent density.  So I tried this:

Real StudioScreenSnapz003

Switching from the If-Then-Else structure to a Select-Case makes it less dense.  I don’t know about you but I generally don’t think about a Select-Case statement when dealing with array processing.  Perhaps that is because I don’t generally care if I have only one item in the array or not as in this case.

In some situations there’s simply no way around huge complex nested loops and if-then statements.  What I tend to do is take my innermost loops and convert then into their own functions and name them something that makes total sense (to me at least).  If that means a function is named “These_Are_Not_The_Droids_You_Are_Looking_For” that’s okay.  It eliminates one or more levels of nested code.

Regardless, making your code easier to read should be a goal in life.  Making code less dense and easier to understand will aid that process.  Of course comments can help but to each their own on that.  White space can help too.  Remember:  you’re not coding just for now or five weeks from now but for five years from now.

I hope everyone has had a good holiday season so far.  I’ve been enjoying my time off by —- coding, of course!

 

Remote Debugger Issue

One of the changes in Real Studio 2012 Release 2 was an improved Remote Debugger Stub.  It compresses the files it’s going to transfer which results in a significantly faster transfer to the remote machine.

I’ve been happy with it until today when I kept getting this error when trying Remote Debug into Windows in VMWare on my machine.

VMware FusionScreenSnapz001

 

Not a very helpful error message.  This occurred as soon as the first data packet reached the Debugger Stub.

After banging my head of against the wall for about an hour (and starting to panic a bit because of a deadline) I started poking around.  The stub has worked for me, without issue, for years.  Why now?  What changed?  I tried using an older stub, older IDE versions, and all sorts of things.  Since I had the older one, newest one, and even a new beta version I had renamed the folders so I could keep them in one folder.  Last week I consolidated and moved folders around so I could manage them batter.

Have you guessed what the problem is yet?  I finally went to options and that’s where I discovered that the Download Location I was putting the files into no longer existed.  A simple change fixed the error and I was able to use the Remote Debugger in Windows again.

Feedback report <feedback://showreport?report_id=23508> was submitted.  Ideally the Stub should check the location before a debugging session starts or if the location doesn’t exists uses a temporary location.  I suspect this one will get fixed rather soon.

So, there you go.  If you’ve been banging your head up against a wall trying to get Remote Debugging to work, you might want to check the Options/Preferences and see if the Download Location exists.  Hopefully this saves someone, somewhere along way, some time.  Happy Coding!

Real Studio 2012 Release 2

Real Software released Real Studio 2012 Release 2 today.  As Real Software announced a while back this release still has the existing IDE and the same licensing scheme.  As with the 2012 R1 release this version contains a lot of Cocoa and other bug fixes and a number of new features that will please some and make others yawn.

Web Edition

Dynamic Constants now work without the developer going through hoops to use them!  This is very good news because it makes dynamic constants as easy to use as their desktop counterparts.  One thing that was reported but not in time to get fixed was WebPage Titles.  They plain don’t work and if you are using the #somestring shortcut you’ll see that string in the title rather than the correct one.

This release also has seen the addition of the Web Control SDK  This powerful new addition lets you create your own controls for Web Edition!  This is very much needed as it gives a standard way for developers to wrap the plethora of controls available for web apps such a JQuery and the Yahoo User Interface (YUI) library.  Think of this as plugins for web applications.  I look forward to seeing how developers start using this.

They also added the WebCanvas control.  This is an HTML5 only feature so you should check the Supported method before attempting to use it.  Otherwise, this works just like the desktop canvas control where you draw in the Paint event that passes in a WebGraphics object which unsurprisingly acts just like the desktop canvas version.  The developer then can use Invalidate and Refresh events to cause the canvas to refresh.

A number of important bug fixes for Web Edition were addressed in this release.  For one, Threads, WebContainers, WebPages and WebDialogs no longer leak memory!  Some events that could be out of order are now queued up properly.  This may cause issues if you relied on the previous event order so please double check your apps before deploying.

Desktop

The TextArea control has two new properties that might be useful for you.  They have a new LineHeight and LineSpacing property that will make it easier to change the way the text looks in the control.

One of the features that I’m really happy with is remote debugging.  For years I’ve been unhappy with how slow it is to do remote debugging from Mac to Windows even on my local machine using VMWare.  You’d think this would be wicked fast but it isn’t.  Until now.  The Debugger Stub and IDE now transmit a compressed version of the application rather than the full-sized version. This decreases the transmission time dramatically.

Another new feature that Real Software added as a new Crypto module that allows us to use SHA1, SHA256, SHA512, HMAC and PBKDF2 encryption without resorting to a third-party plugin or utility.  Without getting into the details on each one I suggest you read about it in the online wiki at http://docs.realsoftware.com/index.php/Crypto which conveniently has links to their respective Wikipedia pages.

As you might expect, Cocoa has dozens of bug fixes.  If you are not working with Cocoa in your applications, at least some of the time, I highly recommend you start.  Carbon will eventually be frozen with critical-only bug fixes while Cocoa will get all bug fixes and new features.  With the many bug fixes we are now closer and closer to that day.  Look for Carbon to be frozen perhaps when the new IDE is released.

Windows has about a dozen bug fixes that all appear to be relatively minor.  Obviously if they affected you they weren’t minor but none of the bugs fixed affect my apps.  Your mileage may vary on that one.

Linux also has a number of bug fixes, but again, seem rather minor (unless you were affected).

Databases

Users of PostgreSQL now have SSL support.  Specify what SSL connection type you need before trying to connect.

A number of bugs were fixed in the ODBC plugin that should make it more reliable when working with Unicode text.

Documentation

By my count several dozen Language References were updated to fix incorrect information or add clarifying information or added new examples.  Some of the example projects were updated too.  This is welcome news as two items have been a constant complaint from users for years.

My Opinions

Anyone who knows me will attest that I have very strong opinions.  No!  Say it ain’t so!  All you have to do is look at the list of fixes and improvements to see that a majority of their development time has been in Cocoa and Web edition and presumably the new IDE.

The New IDE has been promised for well over a year and I think we will most definitely see it in 2013 Release 1.  Despite what Real Software says I feel the new IDE has been a distraction to the rest of the product.  You just can’t continue to bolt on new features into the old IDE and into the new IDE without some degradation in productivity.  Whether the release happens in the first quarter or later is a really good question.  I hope it’s sooner rather than later for all our sakes.

For those Windows and Linux users out there, do you feel abandoned?  What bugs/features are you looking for that would make you happy?

Take Your BKeeney To Real World

Real Studio is a small community and we can sometimes feel isolated since we may not have other Real Studio developers to bounce ideas off of.  The Internet helps but there is a real power in getting together in a room with other developers and discussing your issues and learning new techniques.  I’ve talked before about how much I love developer conferences.  It’s an awesome experience to be in a room full of developers that speak the same language you do.

Real Software announced today the sessions for Real World 2013.  I am proud to announce that Seth and I are each doing two sessions.  Seth is doing Beginning and Advanced Object Oriented Design and I am doing a session on Reporting Tools for Real Studio and Intermediate Database Coding.  Should be a lot of fun for both of us.

In addition to all that, we are also proud to announce that BKeeney Software is holding a day of training before Real World starts.  Join us on Tuesday, April 23rd, for a morning and afternoon session (lunch is provided) for training.  The morning session is all about database development using Real Studio for desktop and web applications.  The afternoon session is all about the third party controls, libraries, plugins, and utilities that you need to really polish your Real Studio applications.

The entire BKeeney Software development staff will be on hand to answer your questions.  In addition, all registrants will receive a complementary one-year subscription to our online Real Studio video training!  For one low price you get personal training and access to our thirty-six hours (and growing) of online training.

More information on signing up for Real World can be found at http://www.realsoftware.com/community/realworld.php.  The first 20 people to sign up are entered into a raffle for a one-day pass to Disney World.  I was told this afternoon that a couple of spots are still left so sign up soon!

More information regarding our training day can be found at http://www.bkeeney.com/realbasic-training-section/training-2013.  Our early bird pricing coincides with Real Software’s so save big bucks by signing up (for both) before January 5th, 2013.

Sign up today and don’t forget to bring your BKeeney to Florida!

The Real Studio Debugger

We all know by now that Real Software is redesigning the Real Studio IDE. For better or worse it’s coming whether we want it or not. It would really be nice if they changed the debugger to be more useful. Real Software last changed the IDE for the 2005 release and, in my opinion and many others, the debugger was a huge step backwards in usability.

In my opinion, and the feedback I get from other users, is that the Stack popup menu is not intuitive at all. In the old IDE it was a listbox which let you see, at a glance, what the call stack was that got you to the current breakpoint or exception. The popup menu is not intuitive. It confuses users. I say bring back the listbox.

As Merv pointed out in my last blog post, setting a breakpoint is sometimes an exercise in futility. The area to set the break point is maybe 8 pixels wide? Why not double the size? The UI shouldn’t be designed for 800 x 600 windows any more. Most monitors have much more width space than they used to. Make this more user friendly.

Many, many people have begged for Watchpoints in the debugger. In fact, the Feedback <feedback://showreport?report_id=1095> is currently at #13 and was entered in 2008.

An even bigger request is to have the debugger show a value tooltip while debugging. This means that if you hover your mouse over the variable ‘i’ the tooltip will show the current value. This one is at #7 and was entered in 2009.  <feedback://showreport?report_id=10536>

Make these feedback items part of your Top Cases and show Real Software we really need them.  My bitching about it won’t change it.  Only your votes can give them any indication what you want.

Now, I have no idea what changes they have in store for the debugger. What I do know is that they’ve already said the first release will not have ANY changes to it.  This is too bad but I don’t want to wait five years for a better debugger!

So my question is why do we have to wait for so long to get needed and wanted changes? What else do you think should be part of the debugger?

Loop Variables

A subscriber to my Real Studio training videos sent me an email the other day asking me why I did something in the videos.  He was asking why I did this

for i as integer = 0 to ar.ubound

rather than

dim i as integer

for i = 0 to ar.ubound

I had no real answer except that it’s a little less typing and that the variable, i, can’t be used outside of the for next loop.

The subscriber went on to say that he tested both for speed and that there’s essentially no difference between the two versions.  That has been my experience too.

I initially was very against this ‘shorthand’ method.  It was introduced to me by my senior developer, Seth, and it just looked…odd.  I think at one point I might have even emailed him to ask him to stop doing it.  After a brief discussion he convinced me it didn’t matter to him but if I really wanted him to go back to the other method he could.

To make a long story short, I tried it out for a week and I discovered that I really prefer it to the other way and I’ve used it consistently ever since.  It’s a bit less typing.  I don’t know about you but I am essentially a lazy programmer so anything that means less typing is good for me.

The second reason is that when you declare the variable in the for next loop the variable is local only to the loop.  This means I can’t reuse it outside of the loop by accident.  If I declare the variable outside the loop I can use it again (sometimes by accident).  Of course, there are times you actually WANT to reuse the variable but I find those rare.

The other thing that I tend to do is reuse the same loop variable time and time again even in the same method.  So I get code like this:



for i as integer = 0 to ar.ubound
   
   //Do something in this loop
   
next

//Some other code

for i as integer = 0 to iMax
   
   //Do something in this loop
   
next

//Wrap up the function


I find this to be very readable (though I’m not doing anything in these examples). ‘i’ is my default loop variable and I think I’ve had entire apps where my only loop variable is i even though I’ve had thousands of for next loops.

Anyway, given the recent discussion on standards, I thought I’d ask what you do?  Do you have a preference?  Do you despise one over the other?  Does it really matter to you?

Happy coding!

Default Control Names in Real Studio

We get asked, on a fairly regular basis, to review code in a project (that we didn’t write) and make recommendations on how to improve it.  One of the things that annoys me to no end when I review OPC (Other People’s Code) projects is when developers use the default control names that Real Studio provides in the Layout Editors.

The default naming convention used by Real Studio is the baseline minimum.  In my opinion, you have one instance where using the default name is acceptable and that’s with Labels.  And that’s ONLY if you never access the label in your code.  Really, that’s it.  Everything else should be named so that I (and I really mean you too) can read your code at a glance.

Real Studio doesn’t help us out very much on this one.  Once you’ve placed a control on the Window/Page it should, in my opinion, automatically have the control name selected so that all I’d have to do is type in the name I want and then move on.  It doesn’t despite my Feedback items from many moons ago.  At one point I was told it’s not going to be possible in the current version of the IDE.  I don’t remember by whom, or when, but I can take that at face value because the new IDE is coming soon.  Hopefully they don’t force the same bad practices upon us again.

Yeah, I know I’m being anal about this, but if I’m looking at your code and I’m trying to distinguish between TextField1, TextField2, and TextField3 and have to refer back to the layout to tell what each one is, that will be my first suggestion to you.  I’m not a mind reader and, let’s be honest, I’m as lazy a programmer as I can get away with.  Real Studio makes me use the mouse too much as it is so you’ll be better off making your own life easier too.  After all, isn’t txtFirstName, txtLastName, and txtCity much more intuitive then the original names?

We have our own coding standards document that each new developer gets when they start.  It has the list of prefixes we use for our controls (and variables but that’s a different post).  So not only does it tell me what it does (or represents) it tells me what control type it is.  So btnSave, lstNames, chkEnabled, and rbOpenAtStart is inherently clear when I see them accessed in code because I can tell control type and function at a glance without seeing the layout editor.

We have dozens of internal projects.  We have about a half dozen consulting projects at any given time.  The very last thing I want to do is look at a layout to figure it out.  My time is too valuable to muck around with the layout editor.  Your time should be that way too.  Remember, you’re coding for clarity not just for now, or five months from now, but for five years from now.  You really think you’ll remember what TextField1 is going to be by next Friday?  Do yourself a favor and name your controls something meaningful.

Heck, I don’t even care what your naming conventions are.  Just get some and use them – consistently.  You’ll be happy you did.  If you’ve watched any of my training videos you’ll realize that I take great pains to name controls.  I do this for everything.  This is one of the shames of the Real Studio example projects because many of them use the default names thus giving people new to the language the impression that this is ‘best practices’.  Thankfully this is changing a bit but it won’t be too soon for me.  I’m tired of making this particular recommendation on OPC projects.

What about you?  Do you feel this is a big deal or am I just having a really bad day?  What things so you wish Real Studio did better to help you write better code?

Real Studio Schedule Change (Again)

Real Software announced today that the much vaunted and talked about new IDE is delayed yet again.  Real Studio 2012 Release 2 was released to the beta list today using the old IDE.  An alpha for 2013 Release 1 will be released (to alpha testers only) soon for us to evaluate and provide feedback on usability.

I have mixed feelings about the announcement.  First off, I’m glad they’re continuing updates using the venerable IDE user interface.  I know there are a number of bug fixes and enhancements that I can use on projects – right now.  The updates are welcome and hopefully no new bugs are introduced (though RS has done a couple of dot releases for Release 1 so I see no reason why it won’t continue as needed).

This announcement, in general, is a good thing and I’m glad that Real Software has decided that burning their bridges with the existing IDE just doesn’t serve us, the Real Studio developer community, very well.  The flip side, of course, is that every release they use the old IDE just pushes off the new one that much further into the future.

Like many Real Studio developers I’m still not convinced we are best served with a radically different IDE.  I believe minor tweaks to the existing IDE might be a better solution.  However, it might be a matter of scale that once you change one thing you have to change this, that, and everything else and by the time you’re done you’ve rewritten the whole user interface.  Add in the new iOS framework and editors and the changes to Web Edition and it might have been the only way to do it.  So perhaps this is a good change but only time, and usage, will tell.

I can’t wait to get my hands on the new IDE and work on my large projects.  I am curious to see how the always visible project tab will work.  If it makes life easier it will be a good thing.  If it hinders me in those areas I find important it will be a bad thing.  Obviously my opinion is the only that counts – to me, at least.  🙂

This announcement also pushes back the new licensing scheme and the one-click Web Edition deployment.  For some this is a big issue and for others not so much.  I guess that’s up to you to be mad, angry, or indifferent.

What do you think of this news?  Good, bad, or typical Real Software time slip?

Defining Primary Keys For Real Studio Apps

An issue that seems to come up fairly regularly with people new to database applications in Real Studio is how to make unique record identifiers when they insert data.  The simple answer is that you don’t – the database itself already knows how to do this.

SQLite databases (REALSQLDatabase in Real Studio) automatically have a rowid regardless if you define your own primary key or not.  You can access this rowid via sql and, in fact, have to use if you want to edit a recordset (if you don’t have a primary key defined) or you’ll get a database error along the lines of it not knowing which record to edit.  However, as soon as you define the primary key field it, and the rowid, are one in the same and hold the same value.

I’ve seen some developers come up with elaborate schemes to come up with unique primary id’s for the database tables.  This is a bad idea!  That database can (and should) do that for you.  It’s exceptionally dangerous to come up with your own scheme.  Bugs happen, mistakes happen, and the problem only gets worse when you add in multiple user databases where multiple connections can insert data at any time and when you have billions, or trillions, of rows of data.  Let the database do that work for you!  It was designed to do that afterall.

I think part of the problem is the built-in Database Editor in Real Studio is awful.  It doesn’t give you the option of making an auto-increment field.  See screenshot below:

 

 

 

We ditched the built-in editor many years ago for other tools.  For SQLite we use a variety of tools and they ALL do a better job of managing your SQLite database than Real Studio.  For example, take a look at the options that Base http://menial.co.uk/base/ gives us just for the primary key:

 

The same goes for all the other databases that Real Studio supports.  There are tools that are genuinely better in almost every aspect that the Real Studio Database Editor.  Do a little research and you’ll find tons of tools that range from free to hundreds of dollars.  If you want editors that are similar across all databases I’d recommend Navicat http://www.navicat.com.

A lot of our projects use SQLite.  We use straight SQL to create our tables, indexes, and relationships.  Here is an example of defining an integer primary key that auto increments:

Create Table IF NOT EXISTS  T_Account(Account_ID    INTEGER  PRIMARY KEY AUTOINCREMENT, ShortAcctNumber    TEXT NULL …..

We always use the tools to create the database during development and then have the tools generate the initial SQL for us.  It’s simple and fast and I don’t have to remember the details.  I just define the fields and then copy and paste the SQL into the project.  I’m lazy that way.

If you’re looking for example of this process you can take a look at our subscription training videos at http://www.bkeeney.com/RealStudioTraining/realstudiotraining.cgi.  Our Journal Entry project goes from start to finish creating the database from scratch via code and the showing how to add, edit, and delete data from the database.

Depending upon the rowid can be detrimental to the future of your project.  They can be reused whereas a primary key cannot.  Take a look at this blog post from Marco over at SQLABS:  http://www.sqlabs.com/blog/2010/12/sqlite-and-unique-rowid-something-you-really-need-to-know/.

A quick scan of MySQL and PostgreSQL documentation shows that they don’t use rowid so if you have to migrate from SQLite to a database server your rowid code is now invalid and you’ll rewrite your code to make and use a primary key.  So it’s just easier to start defining your primary, integer, auto increment keys now and start using the primary key field instead of rowid.

Let the primary key work for you.  Don’t create your own scheme for numbering your primary key field and for your own sanity ditch the Real Studio Database Editor.  Happy coding!

Busy Updating Products

I apologize.  Blog posts have been slow lately.  Acquiring products from another company is an interesting process and figuring out the StyledHTMLField and Simple Help Editor was no exception.  First, you have to get in the mind of the original developer and figure out what they were trying to do and then determine if you wish to change the code and then test, test, test.  I can say I am very thankful for source code control because I’ve broken a few (too many) things and had to revert to older code!

One of the things we’re doing with Simple Help Editor is changing the licensing scheme to fit most of BKeeney Software’s other commercial products.  That led me down the proverbial rabbit hole because we discovered that the eSellerate plugin works fine in Carbon and Cocoa (after contacting tech support to get the Cocoa update) but fails in Windows (go figure).  Of course this only happens in Real Studio 2012 R1 and higher so I’m sure it’s simply a plugin compatibility issue and hopefully we can get an update soon (because we’re waiting to release!)

The other thing we decided to do was move to our standard preferences system.  The reasoning was twofold:  First, it now works just like every other of our products so my and my team won’t have to think about what the preferences system does because we know it (and use it everywhere).  The second reason, which was kind of by accident but fortuitous anyway, was that we got to touch code everywhere.  Just by replacing the preferences we go to see a LOT of code we wouldn’t have normally touched.

Just by doing these two seemingly minor items I now have a whole laundry list of items I want to change in Simple Help Editor.  Some of it is personal preference and some of it is features I want for my own products.  It’s also a strong possibility that we’ll integrate the Formatted Text Control into Simple Help Editor to not have to rely upon the RTF to HTML conversion routines and the built-in TextArea control which doesn’t allow any graphics to be shown.  This should make the Simple Help Editor text editors to be a bit more intuitive.  If you are are user of Simple Help Editor and have a feature request then please let me know.  I

Speaking of the Formatted Text Control we’re also working on it too and getting it ready for new features in version 3.  Among the planned features are Retina display support, HTML Export, Hyperlink support, and adding a number of simpler examples that developers can (hopefully) use out of the box without any plugins.

Sometimes I am amazed at how long some things seem to take.  I guess I shouldn’t at this point as I come up with estimates for clients all the time.  When it’s my own stuff it seems to take FOREVER to get done.

Anyway, that’s the current update.  Thanks for you patronage and continued support!