I've been to a ton of conferences and heard a lot of keynote speeches, and I don't remember that many of them. Nick Petreley's Clarion keynote of many years ago is high on that listis one I recall, but mainly because of the cool Pinky and the Brain clip he showed and not because of what he actually said. And Hank Asher's Clarion keynote has stuck with me because a few years later I was contacted by a lawyer interested in my recording of that event.
But at the Open Source Convention (OSCON) in 2006 I heard Six Apart's Anil Dash present Trying to Suck Less: Making Web 2.0 Mean Something. I was floored. It wasn't so much impressed with his take on web development, as good as it was. It was the frank admission that what we do as software developers so often sucks. And that's okay, as long as we try to suck less.
I came away with a whole new perspective on my work as a software developer. I've written code that I'm proud of, and code that should never have seen the light of day.
Some of my best code from years ago really really really sucks. And that's okay, because But it was the best code I knew how to write then.
...
Clarion's code generation technology provides a huge assist; you get rapid production of highly reliable code, easily maintained and extended within the AppGen environment. That's great, up to a point.
...
But what happens when you want your app to do something the AppGen and its many templates can't handle? You open an embed point and
That's when you start writing your own code. Wonderful!
Except that embed points are like crack, and way too many Clarion developers are embed-heads. It's just so easy once that embed point is open to keep on writing.
Most of the evils of Clarion development boil down to this one thing: abuse of embeds. But there are lots of ways to get betterAnd that's when you really start taking responsibility for the quality of your own applications.
A lot (though not all) of what we can do to suck less involves writing better code.
Sucking less
Here are some of my favorite ways to make Clarion development suck less:
THE BIG ONE: Get that business logic out of embed points!
This is best done with classes, so if you haven't learned OOP, get started! If you don't want to learn new stuff, it's time to get out of the business. Learning new stuff is how we all got here; it's what we do. Embed points are like crack, and way too many Clarion developers are embed-heads. It's just so easy once that embed point is open to keep on writing. Stop! NOW!! Code in embeds is typically non-reusable, awkward to test, difficult to maintain, and frequently unreadable due to excessive length. You need to put that code somewhere you can test it and reuse it. To some degree you can accomplish this by moving the code to source procedures, but classes are generally a better solution. Which leads to...
Learn object-oriented programming
I know, you don't have to know OOP to code in Clarion (even if ABC apps rely heavily on classes). But there's a reason object oriented programming is ubiquitous. It. Just. Works. And it can make so many things about development much better.
Create unit tests for your business logic
Use ClarionTest or CWUnit to unit test your business logic, or set up your own testing framework/coding convention. Be able to test your business logic apart from the user interface or the database. This will make development, maintenance and even design easier. Once your business logic is right you can write it into the UI and/or the database.
Take a layered approach
Start thinking about your apps as having distinct areas of code responsibility: user interface, business logic, database access, and the database storage (there are other ways to break this down, but this is a common approach). Although Clarion procedures tend to combine all the layers in a single procedure, you can still adopt this kind of separation when dealing with your own code.
...
Use fully descriptive names for variables, procedures, classes, methods etc. Keep individual code blocks (procedures, methods, routines) short and focused on one task. If you find yourself needing to comment your code then it's probably too obtuse; code should be its own description. Adopt a naming convention (but please, not some variation on systems Hungarian...).
Create unit tests for your business logic
Use ClarionTest or CWUnit to unit test your business logic, or set up your own testing framework/coding convention.
Create integration tests
Unit tests run standalone and are typically lightning-fast and run constantly during the development phase; integration tests use databases and other external resources. Because of these external dependencies they typically run more slowly and are more fragile, but they can also be a vital part of your development toolkit.
...
The golden age of the standalone desktop app running on just one platform is coming to an end. That doesn't mean the end for Clarion, but it does mean that Clarion's role is beginning to change. A system might have a desktop component, a web component, a mobile component and any number of services. Think about how you can extract functionality from your code base. Perhaps you have code that a mobile app might need to call, using JSON as the data format. Or there's a web app somewhere that needs to call your code via a web service.
Use bug tracking software
I've used FogBugz in the past; I'm currently a huge fan of Jira. You have a world of choices; find a bug tracking system that fits your needs and use it. This is especially important in a team development environment.