Idea: Automated testing of database schema design

When writing or maintaining a MySQL database schema, there are a number quality checks that could conceivably be automated:

• Run the test suite and print out all the SQL statements it runs (e.g. for Perl set DBIC_TRACE=1). Now check that every column mentioned in a `where` clause has an index on it.
• Indexes are defined by: `KEY` or `UNIQUE` next to them
• Indexes are probably most important on large data tables, so identify those manually.

Reasons to split up a very long subroutine into several more subroutines

• Repetition
• If the same or very similar code is being called several times, it should be put into a subroutine to avoid code duplication.
• This is the most obvious reason.
• Clarity
• You should be able to read the code like English
• Reading the code in a top level subroutine or script should give an overview of what it does, without going into detail
• Each subroutine should be able to be easily described in one or two sentences
• Comments are not sufficient for this, as you would still have to scan through many pages to gain an understanding. 
• This reason is controversial; Some people say repetition is the only valid reason (see 'dangers' below)
• Testing
• You should be able to test each conceptual part of the system separately.
• It should be obvious to which part of the system a unit test applies.

Dangers of the second two reasons:

- Too much abstraction, difficult to understand and follow code flow

- Code is slow because of overhead of creating and managing subroutines

Bash menu

Try this menu script for bash scripts:

while getopts ":u:a:s:v" options; do

  case $options in

    u ) uname=$OPTARG;;

    a ) attrs=$OPTARG;;

    s ) searchattr=$OPTARG;;

    v ) att=ALL;;

    h ) echo $USAGE;;

    \? ) echo $USAGE

         exit 1;;

    * ) echo $USAGE

          exit 1;;

  esac

done

echo uname = $uname

Test scripts

Even a set of test scripts often benefit from modularised separate libraries, configuration files and dedicated data files. And logging.

How to use encoding

Encoding is necessary only for transmission of data.

Any data stored in files or a database should never be encoded.

Get the transmission right (decode 'automatically' as part of the receiving process, as soon as possible after receiving the data) and you'll never need to worry about decoding issues.

Regular expressions in C: Advice

If you can avoid using regular expressions in C, then *do not use them!!*

Instead try the strstr (find substring) and strtok (like perl's split) routines.