...
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.
Subscriber 
Subscriber content: The Problem with Embeds, Revisited
To some degree you can accomplish this by moving the code to source procedures, but classes are generally a better solution. Which leads to...
...
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. Yeah, I know, the next better thing is always around the corner. Aspect-oriented programming. Functional programming (again). But OOP is still the best way I know to model most business logic. Get with the times.
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. As much as possible, 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. And now that I have you thinkigg about unit tests...
Adopt Test-Driven Development
Whether or not you use one of the existing Clarion unit testing frameworks, you can still adopt the Test-Driven Development approach. TDD has numerous benefits not just for code reuse and reliability, but also for code design. I can confidently say that TDD has done more for the overall reliability and maintainability of my applications than any other practice I've tried. It's also had a significant positive effect on the way I structure my code.
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.
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 version control
Keep your Clarion environment and your applications under version control. I like Git, but what you use isn't as important as that you use it. Version control is also a critical component of just about any build server.
Create a build server
Once you have your code under version control you're not that far away from creating a build server that sees when you've committed code to the repository, pulls that code and does an automated build. Especially useful in large multi-app systems with multiple developers.
Automate your tests
Ideally your tests should run as part of your automated build process, but the tooling for this isn't readily available yet. Watch this space for further developments.
Move to SQL (if you haven't already)
There are lots of SQL flavors out there, and almost certainly you can find one that is a good replacement for your current flat file database. Once you go SQL you never want to go back.
...
Subscriber content: Our massive 600+ page ebook on databases & SQL
Make your code readable
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 on systems Hungarian...).
Take an API approach
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.
Break long processes down into Hanson Loops
What's a Hanson Loop? It's a construct Mike Hanson once provided for me in a procedure I wrote, and which I liked so much I've used it many times since. Plus I think the name name Hanson Loop sounds sounds cool. It's also a great example of the benefits of turning routines into local procedures. Read more...
Align procedure and method return values with ABC
It took my years to get comfortable with ABC's standard for return values, but I'm fully on board now. It was the above mentioned Hanson Loop that finally pushed me into the Level: zone.
Subscriber content: Clean up your code with the Hanson Loop
Exchange your routines for local procedures
Use bug tracking software
I've used FogBugz in the past; I'm currently a huge fan of of Atlassian's Jira which which is tremendously powerful yet very easy to use. 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.
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. As much as possible, 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. And now that I have you thinkigg about unit tests...
Subscriber content: Many-to-many checkboxes revisited
Adopt Test-Driven Development
Whether or not you use one of the existing Clarion unit testing frameworks, you can still adopt the Test-Driven Development approach. TDD has numerous benefits not just for code reuse and reliability, but also for code design. I can confidently say that TDD has done more for the overall reliability and maintainability of my applications than any other practice I've tried. It's also had a significant positive effect on the way I structure my code.
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.
Use version control
Keep your Clarion environment and your applications under version control. I like Git, but what you use isn't as important as that you use it. Version control is also a critical component of just about any build server.
Create a build server
Once you have your code under version control you're not that far away from creating a build server that sees when you've committed code to the repository, pulls that code and does an automated build. Especially useful in large multi-app systems with multiple developers.
Automate your tests
Ideally your tests should run as part of your automated build process, but the tooling for this isn't readily available yet. Watch this space for further developments.
Align procedure and method return values with ABC
It took my years to get comfortable with ABC's standard for return values, but I'm fully on board now. It was the above mentioned Hanson Loop that finally pushed me into the Level: zone.
What else?
How about you? What are your guiding principles for Clarion development? Post a comment below!
...