Contribute Code

This page describes the standard procedure to modify code of weex.

Before Coding

Check License

Weex adopts Apache License 2.0 as its open source license. Make sure your potential contribution obeys the requirement of Apache License 2.0.

Bug or Feature ?

• If you are going to fix a bug of Weex, check whether it already exists in Github Issue. If it exists, make sure to write down the link to the corresponding Github issue in the PR you are going to create.
• If you are going to add a feature for weex, reference the following recommend procedure:
  1. Writing a email to mailing list to talk about what you'd like to do.
  2. Write the corresponding document

Coding

1. Fork the Github repository at https://github.com/apache/incubator-weex.

2. Clone the forked repository and create a new branch from master to push your commits to.

3. Develop your feature or bug fix in your new branch. Make sure your code meets the style guidelines.

4. Add the License below to the top of any new file(s) you've added.

    /*
    * Licensed to the Apache Software Foundation (ASF) under one
    * or more contributor license agreements.  See the NOTICE file
    * distributed with this work for additional information
    * regarding copyright ownership.  The ASF licenses this file
    * to you under the Apache License, Version 2.0 (the
    * "License"); you may not use this file except in compliance
    * with the License.  You may obtain a copy of the License at
    *
    *   http://www.apache.org/licenses/LICENSE-2.0
    *
    * Unless required by applicable law or agreed to in writing,
    * software distributed under the License is distributed on an
    * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
    * KIND, either express or implied.  See the License for the
    * specific language governing permissions and limitations
    * under the License.
    */
   

5. Commit all the changes to your branch.

:::tip If you are writing Java or C++ with Android Studio, License will be added to the head of the file automatically. :::

Code Style Guidelines

Objective-C

• Tabs should be used for indentation. Please do not use spaces.
• * operator goes with the variable name (e.g. Type *variable;)
• For function definitions, place each brace on its own line.
• For all the other braces, place the open brace on the line preceding the code block and place the close brace on its own line.
• Use #pragma marks to categorize methods into functional groupings and protocol implementations
• Follow other guidelines on GitHub Objective-C Style Guide

Java & Android

• Use Google Java Style as basic guidelines of java code.
• Follow AOSP Code Style for rest of android related code style.

C & C++

• Use Google C++ Style as basic guidelines of C++ code
• Weex defines a subset of the Google C++ development specification that covers some of the major C++ scenario usage specifications.

Publish your Change

Open a pull request against the master branch of apache/incubator-weex. Make sure following guidelines are considered when creating a pull request.

1. One PR should solve only one problem.
2. The PR title should be the form of [COMPONENT] Summary:
   • COMPONENT is one of the mentioned PR categories (android, iOS, JsFm, web, test, etc..).
   • Summary should be a brief description of your change within one sentence.
3. Content description of PR
   • If the PR is about fixing a bug excluding crash, a demo is necessary in code's description.
   • If the PR is about adding a new feature, another PR for documentation is necessary in codes' PR description.
   • Optional If the PR fixes an existing Github issue, you may add the link to the corresponding issue in the PR.

There will be a static check program when you submit a PR,and the following rules will be checked:

1. Check if your PR is submitted to master branch, if not, you will failed.
2. Check if your PR is binded with a milestone, if not, you will receive a warning message.
3. Check if your PR description contains keywords Documentation and it's correponding http links. if not, you will receive a warning message.
4. Check if your PR description contains keywords Demo and it's correponding http links. if not, you will receive a warning message.
5. Check if your PR modify the changelog.md, if not,you will receive a warning message.

:::tip Reviewing PR may take a great deal of time, please be patient. If your PR doesn't get response over 96 hours, you might send an email to mailing list to ask the progress. :::