<div dir="ltr">Anyone want to review? Thanks. <div class="gmail_extra"> <div class="gmail_quote">On Wed, Nov 13, 2013 at 2:19 PM, Frank Henigman <<a href="mailto:fjhenigman@google.com" target="_blank">fjhenigman@google.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Signed-off-by: Frank Henigman <<a href="mailto:fjhenigman@google.com">fjhenigman@google.com</a>> --- Paul's patch for HACKING inspired me to go through my notes for mistakes I made trying to contribute, and for suggestions seen on the list or irc. Note: I do not have commit access. HACKING | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/HACKING b/HACKING index d96b994..815de5b 100644 --- a/HACKING +++ b/HACKING @@ -73,6 +73,9 @@ Basic formatting: * Function return type and name go on successive lines * Opening function brace goes on line by itself * Opening statement braces go on same line as the 'for' or 'else' +* Use /* C style comments */, not // C++ style +* Don't write 'if (condition) statement;' on one line - put the statement on + a separate line. Braces around a single statement are optional. The following indent command will generally format your code for piglit's style: @@ -94,6 +97,9 @@ Code conventions: * Preprocessor macros should be UPPER_CASE * Enumeration tokens should be UPPER_CASE * Most other identifiers are lower_case_with_underscores +* Library, executable, and source file names are '<base>_<api>.' + e.g. libpiglitutil_gles2 +* Test names are '<lowercasegroupname>-<testname>.' e.g. glsl-novertexdata * Use int, float, bool except when GL types (GLint, GLfloat) are really needed * Don't put declarations after code. For example: if (x < 3) @@ -102,10 +108,26 @@ Code conventions: This will not compile with MSVC. The 'int y' declaration must be at the top of the brace-block. * Don't use named/designated initializers. They don't compile with MSVC. + + +Test conventions: + +* The goal is to find bugs and demonstrate them as simply as possible, not + to measure performance or demonstrate features. * Write tests that are easily read, understood and debugged. Long, complicated functions are frowned upon. * Don't try to test too much in a single test program. Most piglit programs are less than 300 lines long. +* If a test doesn't render anything, it doesn't need to set the window size. +* Avoid changing an existing testing such that it might fail where it + previously passed. Break it into subtests and add a new subtest, or add + a new test which supersedes the old one. +* Things that should be seen are drawn in green (or blue as a second color) + while red is for things that shouldn't be seen. +* Calculate drawing coordinates from piglit_width/piglit_height as needed, + instead of hard coding. +* If a test can safely run at the same time as other tests, add it as a + concurrent test in 'all.tests' (or wherever you add it). Utility code: -- 1.8.4.1 </blockquote></div> </div></div>