If not stated otherwise (here), please follow the angular style guide.

Those are some general guidelines on how to structure the code. Some issues and things will be done via tslint, but others need to be done manually. Those guidelines are written down here.

Variable declarations should be always the first in a class. Avoid prefixing private members with an underscore, except a member has a getter and setter.

Use import line spacing to distinguish angular components (and other direct dependencies such as rxjs), from third party components from OpenSlides (our) own components. Take the following as an example:

import { ActivatedRoute, Router } from '@angular/router';
import { BehaviorSubject, Subscription } from 'rxjs';
import { Component, OnInit, ViewChild } from '@angular/core';

import { TranslateService } from '@ngx-translate/core';

import { AgendaRepositoryService } from 'app/site/agenda/services/agenda-repository.service';
import { Item, itemVisibilityChoices } from 'app/shared/models/agenda/item';

Constructors should follow directly after variable declarations.

The ngOn* functions should directly follow the constructor.

Functions, that override from inherited classes or that implement something of a interface should be marked accordingly with @override.

Documentation for functions use always /* someting */ as comment-style. Comments inside the code always use // as comment-style.

Variable syntax is camelCase, classes and interfaces must be named with CamelCase. Use expressive names (as always) and cosistent names, this is the important part: If you have a view child saveButton do name related variables saveButtonEnabled and saveButtonLabel (not label or buttonEnabled). If a private member has getter or setters, the member might be prefixed with an underscore to prevent name collissions and keep the real name for the getter and setter.

Try to pull every bit of data you need from the according repository.

Something is a BaseModel if there is an according class in the server-code. Everything else (like category numbering) are objects solely handled in the client and are not stored by the server, just processed there.

You should avoid any in any case.

Make usage of .find, .filter, .map, .includes, .some and .every. All these can be simulated with .forEach but this is not the clean way to go.

You shouldn't make any http-calls from components, only repository-services should do this. If something is not a BaseModel it should be handled in the functional nearest Repository. If some of those non-BaseModel-classes use the same logic in more then one point, a meta-class should be used with an according meta-Repository.

If you have keyDown-event based functions in you component, make sure that they are distinguishable from each other. If it is just one function, it is fine to call it onKeyDownEvent or something similar. But as soon as you have multiple function it is important to keep them distinguishable. Name your events by the keys they use and the form they are used in (if there is just one form, it is fine to keep just the keynames in function the signature). i.e. if you have a shift+enter keydown event in your gender form, and one shift+enter in your location form in the same component, one function should be named onShiftEnterGenderForm and the other onShiftEnterLocationForm; if you just have one form, but a shift+enter and an enter event, you should name one onShiftEnter and the other one on Enter.