Rules about formatting within scripts and similar stuff.
Please have a look at the C/C++ coding guidelines and apply them when they make sense.
Some more or less strict rules:
Try to have a good readable text flow. Lines with very different length are a pain.
Avoid lines longer than ~ 100 characters unless there is no other choice.
Think about a comparison of the new and the old version of a test script within a graphical diff tool.
Having the difference frequent at the end of long lines is very uncomfortable.
mysqltest only accepts comment lines starting with '#'.
Use spaces, not tabs.
Lines must have no trailing spaces.
-
Write SQL statements in the style of the MySQL Reference Manual
SQL keywords and reserved words: uppercase
Identifiers (table names, column names, etc.): lowercase
Ignore this guideline if your intent is to check the processing of mixed lettercases ;-)
Please follow this guideline for new tests. Rewriting existing tests to use better formatting is good, but can be tedious - a rule of thumb: don't rewrite unless you intend to touch the entire subtest (not the entire .test file, but the statements that make up a complete testing 'unit')
If an SQL statement is long, add line breaks to reformat it and make it easier to read.
SELECT f1 AS "my_column", f10 ....
FROM mysqltest1.t5
WHERE (f2 BETWEEN 17 AND 25 OR f2 = 61)
AND f3 IN (SELECT ....
FROM mysqltest1.t4
WHERE .....)
ORDER BY ...
except you intend to check the parser or the performance of the reader of the code ;-).
Unfortunate example:
select 1+1,1-1,1+1*2,8/5,8%5,mod(8,5),mod(8,5)|0,-(1+1)*-2;
Improved example:
SELECT 1 + 1, 1 - 1, 1 + 1 * 2, 8 / 5, 8 % 5,
MOD(8,5), MOD(8,5) | 0, -(1+1) * -2;
For each test or auxiliary script, create a header that contains the following information:
Purpose of the test or script
Corresponding WL task, if there is any
Creator of the test and date of creation
Author of last significant change + date of change + what was changed
Dates should be in ISO format (ISO 8601): YYYY-MM-DD
In case that the script assigns values to some variables and sources some master test script, please explain the purpose of these variables and why you use these values
Note: The header, like the rest of the test, should not mention confidential information. Remember, our tests are available publicly.
########### suite/funcs_1/t/processlist_val_no_prot.test ############# # # # Testing of values within INFORMATION_SCHEMA.PROCESSLIST # # # # The prepared statement variant of this test is # # suite/funcs_1/t/processlist_val_ps.test. # # # # There is important documentation within # # suite/funcs_1/datadict/processlist_val.inc # # # # # # Creation: # # 2007-08-09 mleich Implement this test as part of # # WL#3982 Test information_schema.processlist # # # ######################################################################
Please work 100% perfect when using boxes made of '#'. Such boxes "jump" into the eye of most readers. Bad example similar to what I found in some tests:
############################################### # # # Some text # # Some text # # # # Author : ..... # # # # Some text # # # ###############################################
Please note that this is caused by spaces, not tabs.
