How many times have you heard that Framework fill_in_the_blank will save time and prevent developers from doing things their own way. Or Frameworks save time by eliminating some of the redundant work on application development.
These might be true, but how many times has a the same framework been proposed for creating a 5 page website, or using an entire logging framework to write the results of one job to a text file, when no one ever reads that log…
So I will create the following rules for when using a Framework is OK, if it does not pass this test, roll your own.
- Does the framework configuration/ training take the same time or longer than the coding of said functionality? If yes, don’t use a framework.
- Is application connecting to multiple tables for Create, Read, Update and Delete transactions? If yes, perhaps some type of database framework is needed, that could be it, don’t install an elephant when you need a mouse.
- Does application require standardization for reuse/resale or for multiple programmers of varying skill? If yes, use a framework unless it contradicts with rules 1 and 2.
- Is application or library going to be reused and distributed open source? To facilitate the code and adoption it’s often easier to create when people are already use to the patterns and coding of an application, in this case, unless it contradicts with the rules above, use a framework.
Many times when starting a project you will get a request for some documentation on coding standards for the project. Why? So you don’t get a bunch of coding cowboys and end up with an application that looks completely different from source file to source file.
On the other hand, if you end up with “standards” that are too strict, you may have well just built a code generator to write all the code for you because the standards will often be more verbose than most application code.
Below are ten simple standards that can replace every coding standards manual ever written.
- Don’t Repeat Yourself (DRY). If you find your code redundant and doing the same things, refactor before it’s too late.
- When making any design decision, ask yourself, what’s the easiest or simplest to explain? Pick the easiest or simplest option.
- When making any design coding decision, ask yourself, what’s more lines of code? Pick the least lines option.
- Don’t use a framework unless you really need a framework. You need a framework if it’s not more lines of code or configuration, it does not complicate the application, and it does not add redundancy to your code.
- All code should be testable because it’s not complete until it’s tested.
- Design by behavior, and don’t put two behaviors in the same class or method.
- Use simple rules for categorizing behavior: UI or Client, Business Logic, Data Centric.
- Use interfaces to define behavior, use child classes to inherit functionality, use them only if you need to share behavior or functionality, remember POJOs are your friend.
- Don’t complicate things by adding a “Go4 Pattern”, XML, external configuration, or other gold plating techniques for some nice to have minor enhancement to configurability or some other “ility”. Only use if the result is less lines of code or simpler to explain.
- Commit early and often to a repository and don’t check in untested code to the repository.