Here some programming "commandments" I collected and which I'm trying to follow. The list is being modified continuously. Consider also the list of "Best practices" posts on my blog. - Never ever duplicate code
Copy your code, make it work and then factor out the common logic.
- Create a layered architecture
Don't mix business logic with data access logic, i.e. no SQL code in business objects. Layering makes your application nicely structured and much more maintainable. Good frameworks that support such approaches are for instance the Spring framework.
- Follow the S.O.L.I.D principle of OO design
Single Responsibility: a class should have one and only one reason to change
Open/closed principle: classes should be open for extension and closed for modification
Liskov substitution principle: derived classes must be substitutable for their base classes
Interface segregation principle: class interfaces should be fine-grained and client specific
Dependency injection principle: depend on abstractions, not concrete implementations
- Refactor your code immediately when you find ugly pieces
Do it immediately when you find some "smelling" code. Don't postpone it, since you won't come back later (when you think you've time).
- Test your code (implemented features)
Test your code by writing Unit-Tests! The best approach would be to use a test-driven-development style: create model -> extract unit test -> implement unit test -> make it fail -> hack the model to make the test pass (just necessary logic) -> refactor the model.
Most often this isn't however possible in reality: time and budget constraints, management politics, unmotivated development teams...
- Separate the model from the presentation
"Separate model from view: don't build assumptions about the
presentation into the model or data source. Keep the interface
between the data source and the presentation abstract. Don't give
the model knowledge of its view. (A good rule of thumb is to ask
yourself if it's possible to have multiple presentations, with
different states, on a single instance of your data source.)
Separate controller from view and model: don't put all of the
"business logic" into view-related classes; this makes the code
very unusable. Make controller classes to host this code, but
ensure that the controller classes don't make too many assumptions
about the presentation."
(Source: Google Objective C Style Guide)
- Create small methods with a clearly defined, single responsibility
Split up huge methods by dividing the responsibility over multiple small methods. Don't create huge methods performing several tasks.
- Give self-explanatory names
Give meaningful names to methods, class members, parameters and variables. By looking at their signature it should be immediately clear what it is about.
Just comment those methods where it is really needed. Too much comments will just mess up your code.
- Just focus on the main functionalities
Don't implement stuff you might need later on. Just implement what you need now! Reduction of waste.
- Never break the build
Never commit a broken piece of software to the common source code repository because the next time other team developers fetch the latest source code they won't be able to go on with their work since they have a broken system on their local machines. See "Best practices: version control system usage" and "Best practices: VCS usage flowchart".
- Don't write logic inside event handlers
Don't write logic inside event handlers such as command button click events. Place them inside a separate method (even if in the same class) and call the method from your handler. This facilitates reuse.
- (to be continued...)
|
|