Code quality in current state of my open source projects

Tue, May 14, 2013 at 12:17PM

There are a great deal of negative things one could say about the source code I write when comparing it to various coding standards and best practices.    I'm not claiming that my work is at the highest level of polish.  Anything can be improved.

When I release code, I approach it from my perspective of being a one-man operations with limited time and motivation. I am trying to release more open source projects in less time. With db-dot-cfc, I already did a lot of refactoring, but it's not entirely perfect.

I have a reduced number of code quality requirements when preparing the CFC for its initial release.
A: Standalone from other CFML
B: Simple to use public methods/options
C: Some documentation
D: Good performance
E: Explicit scoping everywhere

The examples provided with the project are designed to test a number of the features instead of making more thorough unit tests.  I realize this is not good, but just making the CFC standalone and documented was a huge milestone compared to where it was.

I do try to break code into smaller functions that have fewer things happening, though it probably doesn't appear that way since some of them like execute, and the parsing are way too long. To refactor them, requires more thought sometimes. It's not anywhere close to clean code according to the various books on the subject.

I value performance a lot higher then other concerns so you can assume there is some level of performance consideration in everything, but the areas where a performance decision was made is not obvious probably. The building of the SQL and execution of the query in the db-dot-cfc project was designed for speed. The security/parsing parts were not because they can be disabled in production.

I plan on releasing maybe 20 other standalone CFCs like this, and then I'll need to switch to documenting the larger project which integrates them all. In many cases, a small change in this standalone CFC will cause a lot of refactoring across the rest of the project. For example, I have to rewrite some of the code for over 1,500 queries to use the refactored db-dot-cfc everywhere.

I have to keep in mind 100+ unique domains built over 9 years when I change the code. So while I may be willing to rewrite a lot more for the benefits of db-dot-cfc, I may not be willing to change the arguments / functions sometimes because the work would be too time consuming.   I also don't like to add new copies / alternate versions of features.  I try to make one very flexible feature, and migrate old code to it.

If you have any code quality suggestions for the projects I write, I welcome that input.  However, I am trying to mostly release the code, and worry about some of the more time consuming quality concerns in future releases.

Bookmark & Share