Skip to content
Open
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
230 changes: 230 additions & 0 deletions STYLEGUIDE.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,230 @@
# Documentation Style Guide

For those new to markdown styling, please familiarize yourself with the following [Quick reference cheat sheet](https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet).

**Before** starting on any work, please check the [Project Board](https://github.com/Bannerlord-Modding/Documentation/projects/1) to ensure that nobody else is working on whatever you are planning on doing. If nobody is, [create an issue](https://github.com/Bannerlord-Modding/Documentation/issues) describing what you are creating / fixing / enhancing.

All Pull Requests are expected to match this style guide.
___

## Base level Structure / Navigation

Items in the root README.md should always be nested under wider category.

Base level items are containers for more specific items and should be linked to the root README.me. Inidvidual files (like tutorials or classes) should not be linked to the root README.md, but should be detailed the lower level files.

```
## [C# API Documentation](_csharp-api/)

* [CampaignSystem](_csharp-api/campaignsystem/)
* [Core](_csharp-api/core/)
```
All README files should only go two levels deep at *most* (but one may be more appropriate in many cases), any need to go deeper should be put into a README in the second level to avoid clutter in any single file.

Each of the sections below would be the scope of a single readme:
```
ROOT README
# Section (eg: api)
- packages
```
```
# package
- classes
```
```
# Class
- methods
- params
```
Each of these READMEs should only contain the table of contents of it's relevant data.
___

## C# Packages

Each package directory should contain the following sections in its README:
```md
<Package overview>
## Table of contents
* [classes](_csharp-api/packagename/classes/)
* [childclasses](_csharp-api/packagename/childclasses/)
* ...
## Classes
* [classname](_csharp-api/packagename/classes/classname/)
* ...
## Child Classes
* [classname](_csharp-api/packagename/childclasses/classname/)
* ...
## Template Classes
* [classname](_csharp-api/packagename/templateclasses/classname/)
* ...
## Enums
* [enumname](_csharp-api/packagename/enums/enumname/)
* ...
## Structs
* [structname](_csharp-api/packagename/structs/structname/)
* ...
## Interfaces
* [interfacename](_csharp-api/packagename/interfaces/interfacename/)
* ...
## Exception Classes
* [exceptionname](_csharp-api/packagename/exceptions/exceptionname/)
* ...
```
>Each of the sections (at both levels) should have a valid link to their respective info pages.

The package information header should contain the following:
```md
Current Version (Stable branch): v0.0.0.0
<Brief description of the package and its contents>
```
___

## Classes (Base, Child, Templated, and Exceptions)

Unlike the root and package level READMEs, the class README will contain more than just links to child folders. Each class will start with a **Class Overview Panel**:

### [Parent Object Name](EXAMPLE)

@Anakael Anakael Apr 22, 2020

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

File should start with H1 header.
I suggest move info about parent and interfaces to H2 after description.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd argue its good to have quick access to the parrent class right next to the classname, but thats just me.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, it's good. So that's why I suggested h2 after description.

But when you open a class readme - you, most likely want to read about this certain class first, not related.

# Class Name

This is a description of the class and what it does.

<span style= "font-size:12px">

Using / Namespaces | | <span style='color:yellow'>Taleworlds.Core</span>| | | | <span style='color:green'>Saveable</span> |
:---|---|---|---|---|---|---:|
[System](EXAMPLE) | | | | | | 10000 |
[System.Xml](EXAMPLE)|
[TaleWorlds.SaveSystem](EXAMPLE) |
|
</span>

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is that table correct?
It render as:
изображение
But it make no sense..

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The left column shows all the includes, the yellow is the specific namespace, and savable is green, the savable class number is 10000. I'm more than open to better recommendations

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Table should contain similar data. But without table it will be over wide.
So, maybe table is the best now.


> Omit elements entirely if not relavent to that class (eg: parent class)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why that? Parent class and interfaces - usefull information.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

removed.


> For the non-savable classes, use ```'color:red'``` and change to text to "Not Savable".

After this class overview, a small code snippet should exist showing how to use / initialize the class. **This should not be exhaustive**, just a quick reference.
```csharp
new InformationMessage("Hello World!")
```

The above would be a valid snippet for the ```InformationMessage``` Class, but can be longer if the extra length is used to give important context about the snippet.

Directly after this intro snippet, we have a section outlining the variables of the class. All variables are assumed to have private setters unless otherwise noted. Each variable should contain all of the following information:

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If it private - why it is required to be mentioned?


Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mod?

* Name
* Type (with link to that object or objects)
* Notes

## Variables

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where to describe consts?
in this section, or another?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed :)


<span style= "font-size:12px">

| Name | Type | Notes |
| --- | --- | --- |
| HeadArmor | int |
| MeshesMask | [SkinMask](EXAMPLE) |
| BeardCoverType | [ArmorComponent](EXAMPLE).[BeardCoverTypes](EXAMPLE)
| ReinsRopeMesh | string | returns ```this.ReinsMesh + "_rope";```|
|...|...|...|
|
</span>

> Always add a blank row ( | ) at the bottom of tables to square them off. Note that this table follows the same font size rules as as the class table.

Methods should follow parameters, seperated by a H1 header.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

-> H1
Is typo here?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed to be H2. Poor wording on my part. The idea is to have a clear break between each section


## Methods

<span style= "font-size:12px">

| Type | Method Name | # of Params |
| --- | --- | --- | --- | --- |
| void | [SetItem] | 2 |
| [Equipment](EXAMPLE) | [Clone](EXAMPLE) | 1 |
| void | [FillFrom](EXAMPLE) | 2 |
| ... | ... | ... |
|
</span>


> The class page should only list out the methods like a table of contents, the detail should be saved for the methods own README page.

Methods should be like a miniature version of a class page, with a small table at the top for parameters (if any), return type, description, etc. as shown below:

<span style= "font-size:12px">

### [Parent Object Name](EXAMPLE)
## Method Name

| Parameters | Type | default | Optional? |

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

MnB2 use C#, not TS. Type -> Parameters is better :)
Methods discription place in separate file, do I understand correctly?
In that case we don't need table here, because we have almost the same in another place. In addition, discription would be better placed here, not in another header.
Example: https://docs.python.org/3/library/math.html

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, Optional and default have the same meaning.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oof. Not a C# master by any means, Fixed.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Each file (Classes, Methods, etc) will focus on itself. So the Methods will have their description in their own file, not in their class file. I agree that this table could be optional, but users may navigate straight to a method from very far away (so to speak) in the documentation and won't arrive by going directly through their parrent class (or struct, w/e) tree. If you think this is still worth removing after that consideration, I'll remove.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To summarize, I suggest:
Put methods declaration in class (when I read about class, I want to see it interface) as list (not table, because table assume that datas similar by size)
Put methods definition in separate file (without table).
In that case class won't be overwhelmed and definition won't be stretched out.

|---|---|---|---|
| Param Name | string | 'Hello World' | ✖ |
| Param Name | [XmlNode](EXAMPLE) | N/A | ☑ |
| ... | ... |
|
</span>

> Parameters should be in the same order as they appear in the method. Types should also link to their class. Copy paste symbols as needed. You don't need to link to base types (like int or string).

### Detailed description of the method.
___
Code Snippets (extended)
```
Here is how you do the thing!
```
```
Here is another way to do the thing
```

___

# Enums

Enums should be placed in their own file at the Class level (on their own page under a package) with the following format:

@Anakael Anakael Apr 22, 2020

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where to describe enums, which defined in class? In separate file? In that case info about using is redundant.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was basing off of the decompiled dlls. Enums are defined in their and don't have anything else in them afaik:

public enum WeaponClass
{
// Token: 0x040005BF RID: 1471
Undefined,
// Token: 0x040005C0 RID: 1472
Dagger,
...

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am working on Hero class. And it define structs and enums in self.
Where would be good place to document them?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If they are unique / private to the class they should probably go somewhere within the class, if they live outside the class then they should go as their own page in the Enums section. Open to recommendations for the former.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok. I will place it to class on my case.
But according to styleguides enum should be separated from class.
So that lack on develop side :D (also with public variables)


### [Parent Object Name](EXAMPLE)
# Enum Name

<span style= "font-size:12px">

Using / Namespaces | | <span style='color:yellow'>Taleworlds.Core</span>| | | | <span style='color:Cyan'>Flags</span> |
:---|---|---|---|---|---|---:|
[System](EXAMPLE) | | | | | | Flag Name |
|
</span>

### Values

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where H2 header?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed to H2

* None
* Mountable
* CanJump
* CanRear
* etc...
___


# Structs

Structs should be placed in their own file at the same level as classes and structs within their respective package (eg: TaleWorlds.Core). Due to the nature of structs, they have identical layout to classes with the only change being instead of savable, they get flags.

## [Parent Object Name](EXAMPLE)
# Struct Name

This is a description of the class and what it does.

<span style= "font-size:12px">

Using / Namespaces | | <span style='color:yellow'>Taleworlds.Core</span>| | | | <span style='color:green'>Serializable</span> |
:---|---|---|---|---|---|---:|
[System](EXAMPLE) | | | | | | |
|
</span>

> For the non-serializable classes, use ```'color:red'``` and change to text to "Not Serializable".

Struct READMEs may have subfolders depending on their size, referr to Class layout for structs.

___

## TODO:

Style guide for Gauntlet, Tutorial, and XML docs sections