Raw File
# Contributing



The source code in this repository was digitized manually from paper printouts, so typos and other discrepancies have been introduced accidentally. The code shall be modified to be made consistent with the following scanned printouts:

- [AGC printouts for Comanche][8]
- [AGC printouts for Luminary][9]

## Useful Extensions

GitHub has syntax support for the AGC assembly language built-in. Unfortunately your code editor will not, however there are AGC language extensions that provides syntax highlighting for the following editors:

- [Atom][Atom]†
- [CodeBlocks][CodeBlocks]
- [Eclipse][Eclipse]
- [Kate][Kate]
- [ProgrammersNotepad][ProgrammersNotepad]
- [Sublime Text 3][Sublime Text]†
- [TextPad][TextPad]
- [Vim][Vim]
- [Visual Studio Code][VisualStudioCode]†
- [jEdit][jEdit]

† Supports automatic formatting

[Sublime Text]:https://github.com/jimlawton/AGC-Assembly

## Formatting

**Note:** GitHub and extensions marked above will ensure you're using the correct formatting automatically.

- Use tab indentation
- Use tab width of 8
- Trim trailing whitespace

## What do I check?

Any discrepancies between the scans and the source code in this repository.

### Comments

Comments in the transcribed code **MUST** match the scans **exactly**.

Common issues you should look out for while proofing include, but not limited to:

#### Typographic Errors

In some places, the original developers made typographic errors while writing comments. Some of these were mistakenly corrected during the initial digitisation, however the digitisation has also introduced typographic errors that were not present in the scans.

For example, if the digitised comments contained `SPACECRAFT`, but `SPAECRAFT` was printed in the scans, then the digitisation **MUST** be corrected to `SPAECRAFT` (missing `C`).

Likewise, if a word has a typo in the digitisation but is spelt correctly in the scans then the typo **MUST** be corrected.

#### Spaces

Spaces between two characters in comments **SHOULD** match the scans. In most cases (see the discussion in [#316[10]), this is:

- Single space for new words.
- Double space for new sentences.
- Triple space for indentations.

Not all pages in the scans follow this generalisation, if the scans only have a single space instead of a double space, use a single space.

### Line breaks

- Line breaks *with* `R0000` in column 1 should match the scans exactly.
- Line breaks *with**__out__* `R0000` in column 1 should contain only 1 or 2 blank lines in a row.
  - If there are more than 2 blank lines breaks, strip the extra line breaks.
    - Lines with `R0000` in column 1 do not count towards this.
  - In the source images, these were created by an unprinted digit in column 8. A 2 there forced a double space (single blank line) and a 3 forced a triple space (double blank line). Values 4-8 were defined but never used. Read more about it in [#159][7]

For example the following:



Should become:



## Note

Before you make a PR, please make sure your changes are consistent with the scans!

back to top