![]() Time-out after 10 seconds, if there’s no user response and a timeout is appropriate for the demo (and a longer time-out might be needed, e.g., for ratingScale.The PsychoPy Builder is a free tool to create experiments that can also write your experiment to JavaScript (PsychoJS) to run online. Note: if there is a previous event.getKeys() call, it can slurp up the ‘escape’ keys. Provide a consistent way for a user to exit a demo using the keyboard, ideally enable this on every visual frame: use if len(event.getKeys(): core.quit(). Use win for the visual.Window(), and so win.flip() If you are unsure, please add a note to your commit message, or post a question to the dev list psychopy-dev. This is for readability, especially for people new to python. If you have to choose, opt for more verbose but easier-to-understand code instead of clever or terse formulations. Prefer if : as a construct instead of if = True. And make sure that doing so does not break the demo!įix any typos in comments convert any lingering British spellings to US, e.g., change colour to color Use core.getTime() (= ms since the script started) or core.getAbsTime() (= seconds, unix-style) instead of time.time(), for all time-related functions or methods not just time().Īdd from _future_ import division, even if not needed. Replace import time with from psychopy import core. Inline comments are ok (because the code demos are intended to illustrate and explain usage in some detail, more so than typical code). Try to keep things within 80 chars most of the time.ĭo allow multiple imports on one line if they are thematically related (e.g., import os, sys, glob). com.Ĭurrent PsychoPy ® convention is to use camelCase for variable names, so don’t convert those to underscoresĨ0 char columns can spill over a little. If you are unsure, please post to the dev list psychopy-dev. """įor the comment / description, it’s a good idea to read and be informed by the relevant parts of the API (see ), but there’s no need to duplicate that text in your comment. #!/usr/bin/env python # -*- coding: utf-8 -*- """Demo name, purpose, description (1-2 sentences, although some demos need more explanation). Standardize the top stuff to have 1) a shebang with python, 2) utf-8 encoding, and 3) a comment: ![]() Generally, when you run the demo, does it look good and help you understand the feature? Where might there be room for improvement? You can either leave notes in the code in a comment, or include them in a commit message. Some small changes to function might be needed (e.g., to enable the use of ‘escape’ to quit), but typically only minor changes like this. The idea is to have clean code that looks and works the same way across demos, while leaving the functioning mostly untouched. These are intended specifically for the coder demos, not for the internal code-base (although they are generally quite close). Here are some style guidelines, written for the OpenHatch event(s) but hopefully useful after that too. If something is not clear, you may need to ask a PsychoPy ® contributor for a description email psychopy-dev. ![]() The aim is not to illustrate every aspect, but to get people up to speed quickly, so they understand how basic usage works, and could then play around with advanced features.Īs a newcomer to PsychoPy ®, you are in a great position to judge whether the comments and documentation are clear enough or not. Each coder demo is intended to illustrate a key PsychoPy ® feature (or two), especially in ways that show usage in practice, and go beyond the description in the API.
0 Comments
Leave a Reply. |