| 19 | | - Programming language(s) |
| 20 | | - Frameworks |
| | 19 | * If possible, select a '''programming language''' that is widely known and already used within the CLARIN infrastructure, an in particular CLARIN's core development team. For applications that run on a server, '''Java''' is the preferred language of choice. For web applications front-ends that run client-side, '''Javascript''' is used preferably combined with one of the frameworks mentioned below. Scripts could be written in '''Python''' or '''Bash'''. |
| | 20 | * The same applies to any '''frameworks''' that you might use to develop your application. The following frameworks are preferred for various programming languages/environments: |
| | 21 | * [http://wicket.apache.org/ Apache Wicket] for Java-based web-applications |
| | 22 | * [https://jax-rs-spec.java.net/ JAX-RS]/[https://jersey.java.net/ Jersey] for REST services |
| | 23 | * [https://facebook.github.io/react React] for Javascript based front-ends |
| | 24 | * ... |
| 23 | | - Unit tests |
| 24 | | - Code review |
| | 27 | * Follow the '''conventions''' with respect to code layout, naming and project structure/organisation associated with the language and/or framework that you are using. There may not always be 'official' or uniform conventions, but Google has [https://github.com/google/styleguide style guides] for various languages (including [https://google.github.io/styleguide/javaguide.html Java], [https://google.github.io/styleguide/javascriptguide.xml Javascript], [https://google.github.io/styleguide/pyguide.html Python] and [https://google.github.io/styleguide/shell.xml Shell]) that generally provide good guidelines. Obviously, the most important thing is to use consistent style. |
| | 28 | * Provide '''automated tests''' (unit tests) for your source code. Various tools are available to measure the test coverage of your project. [http://cobertura.github.io/cobertura/ Cobertura] is an open-source solution for Java projects. |
| | 29 | * '''Run your tests''' every time you publish code or binaries. You can test locally on every build, or even better set up remote execution of your tests on a regular basis or triggered by commits/pushes using a continuous integration solution that hooks into your versioning control system (such as [https://travis-ci.org Travis]). |
| | 30 | * Try to '''get your code reviewed''', either by a colleague or someone else within the CLARIN community. Start the reviewing process early on, as it usually gets exponentially harder to make structural changes to your code base while it grows. |
| | 31 | * Make sure that there are no '''secrets''' such as passwords, or other '''environment specific values''' in your sources. Use external files (e.g. property files or XML documents) to provide these to your software and provide an example of such a file with your code. |
