Reviewed-by me too.
Thanks, patch is committed.
On 11/21/2013 01:14 PM, Chris Forbes wrote:
Looks like a good improvement to me.
Reviewed-by: Chris Forbes <[email protected]>
On Fri, Nov 22, 2013 at 7:22 AM, Frank Henigman <[email protected]> wrote:
Anyone want to review? Thanks.
On Wed, Nov 13, 2013 at 2:19 PM, Frank Henigman <[email protected]>
wrote:
Signed-off-by: Frank Henigman <[email protected]>
---
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
_______________________________________________
Piglit mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/piglit
_______________________________________________
Piglit mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/piglit
_______________________________________________
Piglit mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/piglit
