Meta Coding
Packaging
- Supply automatic packaging, build system.
- Publish periodic releases.
Reviews
- Remember cause
- Can’t write truly complete test cases
- education
- Web based code review tool
- Ideal prerequisite for check-in
- Readability review
- Code owner review
- Separate changelists for separate changes
- Self critique
- Beware over-confidence bias
- Take break, return fresh
- Beware over-confidence bias
- Record confidence
- ‘Confidence in correctness: High. Reason: Tested multiple times’
Separate data from code
Externalizing messages
Message strings should, in most cases, not be hard-coded inside the code. Instead, message strings should be externalized; perhaps be returned by a function when provided with an appropriate key.
This separates the program logic from the messages cleanly. One advantage of doing this is that these messages can be changed without touching the program logic.
This is also convenient when the program needs to be made available in several different languages.
Automate tests
In case of code to be shipped: test every function; make test scripts. If on GitHub, use free testing and build tools like Travis.
Optimizing code for speed
Use a profiler to detect parts of the code which are slow. Use libraries optimized for speed.
Avoid repeated memory allocation.
Avoid writing loops in interpreted languages without ’just in time compiling’ facilities - like Matlab: use a compiled language like C instead: otherwise interpretation costs for executing the code piles up.
Code reuse
Don’t rewrite the same logic multiple times: put it away in functions.
Experiment functions
Make a function out of each experiment.
Clearly make program variables for all parameters involved in the experiment. You should not have to comment or uncomment code to run different variations of the experiment; you should just set the experiment parameters as necessary.