2024-11-24 11:57:06 -06:00
|
|
|
# Style Guide
|
|
|
|
This style guide has two modes that a guideline may be.
|
|
|
|
|
|
|
|
`strict` means that prs will be rejected if they do not follow the guideline.
|
|
|
|
|
|
|
|
`loose` means that a pr would be accepted but should later be fixed.
|
|
|
|
|
2024-11-24 12:22:06 -06:00
|
|
|
## Empty Functions | loose
|
|
|
|
Empty functions are typically a sign of an unfinished program or driver.
|
|
|
|
|
|
|
|
In cases where there is a clear reason to have an empty function it will be allowed.
|
|
|
|
For example FakeAlloc is only empty functions because it is a example of an the allocator api.
|
|
|
|
|
|
|
|
### Allowed
|
|
|
|
```rust
|
|
|
|
/// in example.hb
|
|
|
|
a := fn(): void {}
|
|
|
|
```
|
|
|
|
### Not Allowed
|
|
|
|
```rust
|
|
|
|
/// in fat32.hb
|
|
|
|
a := fn(): void {}
|
|
|
|
```
|
2024-11-24 23:50:46 -06:00
|
|
|
## Magic Functions | loose
|
|
|
|
'Magic functions' are what I am calling small helper functions that do one or two things.
|
|
|
|
### Example
|
|
|
|
```rust
|
|
|
|
a := null
|
|
|
|
magic_a := fn(){
|
|
|
|
a = 10
|
|
|
|
}
|
|
|
|
```
|
|
|
|
The exact policy I want to have here is a bit fuzzy. I think that functions like this are nice in certain situations and not in others.
|
|
|
|
Regardless of if you use them or not, put a comment above the function explaining rational.
|
2024-11-24 12:22:06 -06:00
|
|
|
|
2024-11-24 11:57:06 -06:00
|
|
|
|
|
|
|
## Magic Numbers | loose
|
|
|
|
The policy on magic numbers is make them const and have a comment above them. Typically linking to a source of information about the magic number.
|
|
|
|
|
2024-11-24 12:43:15 -06:00
|
|
|
This helps cut down on magic numbers while making acceptable names and atleast half assed documentation.
|
|
|
|
|
|
|
|
Constants are inlined anyways, so its the same thing in the binary.
|
2024-11-24 11:57:06 -06:00
|
|
|
|
|
|
|
```rust
|
|
|
|
// The standard vga port is mapped at 0xB8000
|
|
|
|
$VGA_PTR := 0xB8000
|
|
|
|
```
|
|
|
|
|
2024-11-24 12:22:06 -06:00
|
|
|
## Tabs Vs Spaces | strict
|
2024-11-24 11:57:06 -06:00
|
|
|
I prefer for hblang code to use hard tabs.
|
|
|
|
|
|
|
|
The rational behind this is that a tab is `1 Indent` which some developers might want to be various different sizes when displayed
|
|
|
|
|
|
|
|
Soft tabs do not allow this user/editor specific as soft tabs always become spaces.
|
|
|
|
|
|
|
|
Bottom line is this is an accessibility feature.
|
|
|
|
|
|
|
|
There are some samples below.
|
|
|
|
```
|
|
|
|
\t means hard tab
|
|
|
|
\n means new line
|
|
|
|
\0x20 means space
|
|
|
|
```
|
|
|
|
|
|
|
|
### Allowed
|
|
|
|
```rust
|
|
|
|
if x == y {\n
|
|
|
|
\tlog(z)\n
|
|
|
|
}\n
|
|
|
|
```
|
|
|
|
|
|
|
|
### Not Allowed
|
|
|
|
```rust
|
|
|
|
if x == y {\n
|
|
|
|
\0x20\0x20\0x20\0x20log(z)\n
|
|
|
|
}\n
|
|
|
|
```
|