Introduction

Submitting a patch in a great way to contribute to Cobra. In order that patches can be applied in a timely manner, please follow these guidelines. Doing so eases the burden for those applying patches, gets your patches in faster and reduces the "apply patch" bottleneck.

Discuss the patch on the  forums to see what others think, find out if there is already work in progress, etc.

Coding

See ImplementationNotes.text in the Developer directory next door to the Source directory for information about the implementation of Cobra, how to run the test suite, etc.

Cobra supports both tabs and spaces for indentation, but the implementation of Cobra uses all tabs. Regardless of your particular religious views in this matter (or allegedly rational views), please "go with the flow" and use tabs like the rest of the implementation. Of course, in your own projects, feel free to use either or both (though not in the same line).

Cobra itself enforces some coding guidelines such as capitalizing classes and indenting code blocks. Additionally, try to mimic the style of code that you see around the code are writing. Here are some additional coding guidelines:

# Calling methods: No space after '(' or before ')'. One space after commas.
# good:
foo.bar(x, y)
# bad:
foo.bar(x,y)
foo.bar( x, y)
foo.bar(x, y )
foo.bar( x, y )

# A space before and after most binary operators most of the time.
# good:
x = 1
# bad:
a= 1
b =2
c=3

# No extraneous parens for simple expressions:
# good:
ensure
    result in [8, 16, 32, 64]
# bad:
ensure
    (result) in [8, 16, 32, 64]

Update IntermediateReleaseNotes.text in the Developer directory next door to the Source directory. Include your name or forum/Trac handle for credit.

Be sure to add or update tests found in the Tests directory next door to the Source directory. You may wish to run the test suite before making your changes in order to see if there are any failures independent of them. You must run the test suite after your final changes to be sure nothing has been broken by them.

Do not use print statements in tests. Use assert statements.

# good:
assert x inherits Foo
# bad:
print 'x type =', x.getType

If you have old, commented out code that is no longer relevant due to the patch, delete it. The patch "diff" itself will show the old code and we can always retrieve it from the source code control system if we need it at a later date. Also, remove stray print and trace statements used for debugging.

After testing, if you make any small tweaks to your code, please run the test suite again. You never know what's going to break.

Submission

Example:

cd CobraWorkspace
svn add Tests/110-basics-two/520-blah-blah.cobra
svn di > FixSomething.patch

A typical patch has changes to files in Source, files in Tests and the IntermediateReleaseNotes.text file. Please submit the patch as being rooted in the workspace directory (not in the Source subdirectory or elsewhere). This directory contains the subdirectories Source, Tests, etc.

Use "svn add" on new files to get them to show up in the patch.

Submit the patch as one file which contains all changes. If later, you make additional changes, resubmit the entire patch.

Use ".patch" for the extension and otherwise, name the file as you like.

Attach the patch to a ticket instead of the forums so that it doesn't get "lost". If there was a forum discussion on the topic of the patch, you can always post a link to the ticket in the discussion.