Skip to content
Tim Long edited this page Dec 15, 2020 · 5 revisions

Object Oriented Astronomy

Object Oriented Astronomy

Welcome to the Object Oriented Astronomy project.

The purpose of this project is to create modern, object oriented utilities for use by astronomers.

Astronomy is rife with code written in the 1970s in FORTRAN, which has been ported to C and then in turn to other languages such as C++ and C#. While there is nothing inherently wrong with this and the code is well tested, code that started out in FORTRAN-77 does not usually translate well into modern object oriented languages. It tends to produce clunky interfaces that are unwieldy to use and hard understand. It tends to have an imperative style that encourages poor programming practice and tends to force developers to focus on implementation details instead of abstractions. We think we ought to be able to do better.

The aim is to take this old code, throw it away and start with a clean sheet. We aim to create the libraries we wish we had if C# had been available in 1977 instead of FORTRAN.

In doing this, we strive to use modern analysis and design patterns and techniques. We apply the SOLID principles of object oriented design, test driven development, and other useful best practices.

This project is open source, free and licensed under the Tigra MIT License.

Get Involved

You are encouraged to participate in any way you feel able. We will not insult you by telling you to "write the documentation". If you see something that needs doing, just check out the code and get cracking. It would be helpful if you create a tracking issue or pull request so that everyone knows what's being worked on.

Tigra Astronomy will act as custodian of the project and oversee the general project management. We use the Git Flow branching strategy, but you don't have to (although it is really simple and you might like it). Your contributions should be via a pull request targetting the develop branch. Once your code is merged into develop, it will eventually make its way onto a release/* brach in a beta release and then finally to master in the next production release.

You can work any way you like, but we recommend working on one thing at a time in a feature branch (feature/*). Once you have a feature branch in your own fork of the repository, consider opening a draft pull request straight away as soon as you make your first commit. That way, everyone has visibility of your progress and our build server can pick up and build your code and run the unit tests against your changes.

All contributions to this project are irrevocably committed and become a part of the project and licensed under the project license in perpetuity. By making a pull request to the project, you are agreeing to this. Please be sure you are comfortable with that before contributing code as you cannot take it back later.

Don't forget to add yourself to the Contributors.md file in the wiki.

Clone this wiki locally