Guidelines and coding standards for Binpress components

We stand behind our code

Binpress is a platform for quality source-code from professional developers. Our sellers are hand-picked, personally approved professionals and we only publish source-code packages that have been manually checked and approved by trusted senior developers.

Our thorough review process is one of the main reasons many buyers choose to purchase source-code at Binpress. The guidelines are provided here for your reference, please go over it before submitting your components for publication.

What kind of component should I upload?

You might be wondering what would be a good idea for a component. We are currently working on a new section of Binpress that would allow great ideas to grow from needs and requirements of real people, but until it is ready please consider the following guidelines when thinking of what to submit :

1 Do you have something ready that just needs some clean-up? using field-tested code is a great start for a new Binpress component.
2 Is it useful? does it solve a real problem or answer an actual need? Binpress is not intended for snippets or short scripts, especially if they are paid components. If it can be reproduced in 15-20 minutes by an experienced developer, there is no point in publishing it here.
3 If you want to submit a premium (paid) component, first consider if it's something you would pay for yourself. Are there better solutions available? are there free solutions available? does your component has something that differentiates itself from the competition?
4 Component ideas that you would do best to avoid unless the execution is exceptional :
Database wrappers, URL shorteners, UI effects that serve no real purpose, simple caching components.
5 Component ideas that work well on Binpress :
A complete and useful solution for a complicated interaction.
An API wrapper where there are no good solutions available.
An extension to an existing platform.
A starterkit / template for an application (not a complete application source).
A solution to a unique problem.

What we look for when approving a component :

Component has real use - please avoid submitting components that have no real use. Try to consider whether you would pay for what you are offering.
Component must work - seems obvious, but please make sure the package you upload works on a standard environment, as-is and out of the box. If there are any special requirements or setup steps, make sure to specify it in the component documentation.
Source-code must be easily deployed - By easily deployed we mean it shouldn't take more than a couple of minutes to set it up using the documentation you provided in the component profile.
Source-code must meet coding standards and conventions - The provided source-code package should conform with an accepted coding conventions for the language it is written in. This includes indentation, comments, file and folder structure and formatting, variable names and more.
No copyright violations - Please make sure you do not submit material that you do not own the copyright for or have permission to publish. This includes stock photos and images (icons, logos are included) as well as licensed source-code. If you include libraries in your source-code that are already licensed, specify the licenses in a custom license you create.

How the review process works :

When your component is ready for publication, submit it for review and it will enter the review queue.
One of our reviewers will go over the component source and profile.
If the component has minor issues in the source or profile (including documentation), you will be given a list of review notes for you to fix.

If relevant, we will deploy your package on a standard environment for the language it was published for, using the installation instructions you provided.
This process will continue until component passes quality review by our reviewer.
If component is too far away from meeting Binpress quality standards, it will be rejected outright (see soft and hard rejections below).

Passing and failing quality review

Passing review

After your component has been reviewed and complied with all of the above criteria, you will receive an Email notification and your component will be published on the Binpress marketplace.
Soft rejections

If the component generally meets Binpress quality standards, the reviewer will help you go over and fix any issues that were found during review. We also try to help you improve the marketing aspects of your component profile.
Outright rejections

If component is too far away from meeting Binpress quality standards and the reviewer deems it will take too much work to make it comply, the component is rejected outright. Please read this page in detail and make sure you understand the requirements before submitting in order to avoid having your component rejected.

Coding standards and conventions

Every package published on Binpress must meet industry standards and use good practices. Our reviewers will inform you if you fail to meet some of those standards, but please consider the following guidelines before submitting your package for approval:

General programming guidelines

We expect well-designed and clean code. Use abstraction and modularity as needed, separate application and presentation logic, implement design patterns where appropriate.
Component should provide beyond trivial functionality. A short, basic script will not be accepted as component on Binpress.
Documentations and comments should be included according to the conventions of each language (see specific language sections).
Code should follow the security conventions of the platform it's intended for (web, mobile, desktop).
- Properly filter and validate user input
- Escape dynamic parts in database queries or use prepared statements
- Escape / filter when outputting user input to avoid XSS attacks
- Do not store passwords in plain-text or in decryptable format
Code should be covered by unit-tests where appropriate (such as libraries and general purpose components).
Easy to integrate - package should be integrated with minimum difficulty. Detailed integration and configuration instruction need to be provided.
The use of globals is highly discouraged (global scope pollution).
Don't ignore or suppress errors - make sure they don't happen in the first place.
Don't submit your package with commented out code and incomplete sections (TODO notes and the like).

PHP

Code formatting should follow the PEAR standards with some caveats:
- Opening braces for class and function names can appear on the same line instead of a new line.
- No need to specify the license in the header block unless required by the license type (open-source)
- Indentation can be made with 4-space tabs as well as 4 separate spaces.
Methods / functions comments should follow the PHPDoc style.
If code does not use PHP5 syntax, it should be noted on component profile. This include 'var' for class properties and not declaring class method / property visibility. For the full differences between PHP 4 and PHP 5, read the dedicated manual section on the topic.
Scripts should never rely on register_globals or magic_quotes.
The use of the error suppression operator is not recommended in general.

Javascript

Avoid global scope pollution and override - wrap your code in a closure and use the 'var' declaration when creating new variables.
For anything above very simple scripting, we advice using one of the popular libraries to ensure cross-browser compatibility. You are responsible for your code running the same in every browser.
Do not use inline Javascript inside HTML markup - use event binding instead.
Code should not depend on script tag placement - use document load event (using event binding).
Try to avoid browser detection in Javascript whenever possible - use feature detection instead.
If possible, try to use progressive enhancement. For example, forms that have client-side validation should also be validated server-side. Links that load content asyncronously should perform an actual redirect if Javascript is disabled (context switching).
Javascript does not have a formal style guide, but please examine the jQuery style guide for an example of a consistent, readable format. Use indentation for control structures and function / class defintations, use comments where appropriate, give meaningful names to your variables and functions.

Python

Follow the Python coding style guide
Four space tabs or four spaces - do not mix
Don't use from modulename import * - clutters namespace
For Django, follow the Django Best Practices guide

Ruby

Refer to the unofficial Ruby Style Guidelines

Java

Refer to the SUN (now Oracle) Java Code Conventions

C/C++

For ANSI C, refer to the C coding standards and style guide
For C++, refer to the High Integrity C++ coding standards manual

C#

Refer to the C# style guide. An alternative naming convention can be used as well.
If your package is meant to be linked, please include compiled .dll as well as source

Objective-C

Refer to the Google Objective-C Style Guide and Apple's Coding Guidelines

HTML markup

Markup should validate against W3 standards. We won't penalize you for HTML5 markup that is not yet recognised by the validator (such as the meta tag error Binpress markup currently receives).
Markup should be consistently formatted and indented. Try to avoid lines that are too long and align opening and closing selector on the same indentation level.
Tables are to be used for tabular data only. Tables used for page structure will not be accepted.
Try to use semantic markup whenever possible such as <h1>,<h2>,<h3> ... <p>, <cite>, <blockquote>, <ul> instead of the generic <div> and <span> tags. When not possible, use meaningful class names and identifiers as shown in the wikipedia examples and the various microformats.
Avoid using more elements than necessary. Don't wrap elements in other elements unless there is a reason to do so.
Use of deprecated elements will not be accepted. This includes the <center> and <font> tags. CSS should be used to achieve the effects those tags used to apply.

CSS

Try to avoid using inline CSS - use stylesheets instead.
Functionality should not be broken in any modern browser.
Progressive enhancement using modern selectors and properties is encouraged.