GDB Testsuite Coding Standards
The GDB testsuite has historically had fewer rules than GDB itself. This has led to several "styles".
Plus there are occasions when a particular style is required by the test. GDB has to debug all different styles of code, and style can and has affected the debugging experience. The author recalls an issue regarding whether the opening { of a function is placed on the same line as the function name or on the next line.
The best guidance one can give is that unless a test requires a particular style (which is rare) you can't go wrong following the GDB coding standards. Failing that, cut-n-pasting from existing tests is typically OK, but see the rules below.
Rules For New Tests
Setting aside the various "styles" that appear in existing tests, there are a few (well, as of this writing one 
) rules for new tests.
In C code, don't use K&R function definitions
For example, write this
void
foo (void)
{
/* blah */
}Not this:
void
foo ()
{
/* blah */
}
Don't include test directory name in test results
It's important that test results be comparable, run over run, and thus spurious differences need to be avoided. One possibly counter-intuitive source of spurious differences is the test directory name, even if relative: When the testsuite is run in parallel the test directory name is (essentially) machine-generated.
Here's an example: https://sourceware.org/ml/gdb-patches/2014-06/msg00519.html
Unset/clear global array variables before using them
If you need to use global array variables in your program, you must make sure that you correctly unset/clear the variable before using it. For example:
set global_array_var "" # Now you can use the variable # ...
This is needed because the tests run in the same namespace, which can cause name clashing when the same name is used for global arrays.
It is also a good practice to choose unique names for those variables, though this is not really necessary if you correctly unset/clear them.