Programming (silly stuff)
[ style |
nuts |
hints+tips ]
I've been known to get quite religious when it comes to programming style, but there is some good thinking behind bits of it.
Full bracing
I'm a strong believer in `full-bracing' of C/etc. constructs, e.g.:
if (condition) {
do_something ();
}
Instead of:
if (condition)
do_something ();
Besides just being nicer, and avoiding the `ambiguous else' problem, it also prevents unpleasantness when `do_something()' is a macro.
For instance, if some included header file contained:
#define do_something() magic = MARKER; do_that_thing()
Then the substitution in the un-braced `if' would break the logic -- the resulting `do_that_thing()' call wouldn't be inside the `if'.
Of course, the sensible macro author would define that as:
#define do_something() { magic = MARKER; do_that_thing(); }
This gets around the problem, but macros aren't always guarenteed to be nicely written like that..
There are a multitude more of macro-related pathological brace breakage cases. E.g.:
#define do_something() if (broken) { abort(); } else { do_something_else(); }
That, although it seems fairly benign, causes a problem when substituted into the brace-less `if':
if (condition)
if (broken) { abort(); } else { do_something_else(); }
Which `if' does the `else' belong to ..?
| Language | How to crack nut |
| C |
Use a standard size hammer. Hit the nut square on and it will crack.
|
| Miranda |
Create a list of hammers and a function which recurses the list hitting the nut as it goes
|
| Occam |
Get 50000 small hammers to hit the nut simutaneously. This will provide enough energy to crack
the nut.
|
| C++ |
Create objects which represent the various hammer components and the nut. Define functions which
will let these objects interact to crack the nut.
|
| Java |
Keep hitting the nut with an inflatable hammer until it cracks (or the hammer bursts).
|
| Assembler |
Define the nut as a register and the hammer as a mask. Simply twiddle one of the bits until the
nut breaks.
|
| Pascal |
Use a small hammer. You may need to hit the nut several times before it will crack.
|
| Basic |
Do people still program in this language ?
|
| Lambda-calculus |
Define a recursive function that will hit the nut until it cracks. Writing the function will take
more time than executing it, so it's probably not worth it.
|
| Lingo |
Create the hammer and the nut as actors and ask the hammer (nicely) to crack the nut. "Please Mr.
nut, crack".
|
| Prolog |
Use constraints to search all possible nut configurations for one which is cracked/broken. Additionally,
use branch-and-bound to search for the configuration which is the most smashed-up nut.
|
- Remember not to deallocate static buffers
- Remember to tell you programming partner when editing the same file
- Always use a different output file than the source code
- Initalising control variables in while loops helps
- Link lists don't like to have the head pointer changed to a random address
- Always fill buffers with data before returning them
- When fixing a bug make sure that it wasn't caused by an earlier bug
- Keep a change log so you can see what you altered and why
- When doing primitive garbage collection, make sure you test it first
- Starting in the right language helps
- When Using fprintf remember to use a pattern
- Remember that two instances of a class are different
- The write() function can fail.
- When sleepy and tired, fix type warnings instead of casting them
- Remember that different machines have different endianisms.
- Always use -Wall so that you spot errors like: if( int_var = 0 )
- Class member functions are their own type, not generic, and casting them does not work.
| 
