80 lines
2.5 KiB
Markdown
80 lines
2.5 KiB
Markdown
---
|
|
layout: page
|
|
published: true
|
|
noToc: false
|
|
noComments: false
|
|
noDate: false
|
|
title: Fun Style Guide
|
|
subtitle: Coding conventions for C and Fun (indentation, naming, idioms).
|
|
description: Coding conventions for C and Fun (indentation, naming, idioms).
|
|
permalink: /documentation/style-guide/
|
|
lang: en
|
|
tags:
|
|
- coding
|
|
- conventions
|
|
- idioms
|
|
- indentation
|
|
- naming
|
|
- style
|
|
---
|
|
|
|
Conventions for writing C and Fun code in this repository.
|
|
|
|
## General principles
|
|
|
|
- Two-space indentation. No tabs.
|
|
- Keep lines reasonably short (~100 cols). Wrap thoughtfully.
|
|
- Prefer explicit over implicit; favor clarity.
|
|
|
|
## C (C99)
|
|
|
|
- Indentation: four spaces, K&R-ish braces.
|
|
- Naming: `snake_case` for functions and variables; `CAPS_SNAKE` for macros.
|
|
- Error handling: return error codes or booleans; avoid hidden globals.
|
|
- Headers: minimize includes in headers; forward-declare where practical.
|
|
- Memory: clearly document ownership; free what you allocate.
|
|
|
|
## Fun language
|
|
|
|
- Indentation: two spaces.
|
|
- Naming: `snake_case` for functions/variables; `PascalCase` for classes/constructors.
|
|
- Modules: one primary concept per file; export a minimal, cohesive API.
|
|
- Idioms: prefer arrays and maps over ad-hoc structures; keep functions small.
|
|
|
|
## Formatting and tools
|
|
|
|
- No auto-formatters required; follow these simple rules.
|
|
- Keep diffs small and focused; avoid reformat-only commits.
|
|
|
|
## Additional details (merged from legacy MVP draft)
|
|
|
|
This section consolidates practical guidelines that were previously kept in documentation/style_guide.md.
|
|
|
|
1. Files and headers
|
|
- Keep the standard header block with license and date when editing stdlib files.
|
|
|
|
2. Naming
|
|
- Functions and variables: snake_case (e.g., parse_int, is_some).
|
|
- Classes: PascalCase (e.g., DateTime).
|
|
- Constants: ALL_CAPS when truly constant.
|
|
|
|
3. Layout
|
|
- Indent with two spaces; no tabs.
|
|
- One statement per line; no trailing spaces.
|
|
- Use blank lines sparingly to separate logical blocks.
|
|
|
|
4. Comments
|
|
- Line comments with //; block comments with /* ... */ for file headers and longer notes.
|
|
|
|
5. Collections
|
|
- Prefer [] for arrays and {"key": value} for dictionaries; use has_key() before subscripting unknown keys.
|
|
|
|
6. Error handling
|
|
- Prefer Result and Option helpers from lib/utils over ad-hoc nil checks.
|
|
- Avoid unwrap() in library code; propagate errors using and_then()/or_else() patterns.
|
|
|
|
7. Examples
|
|
- Keep examples executable via shebang: #!/usr/bin/env fun
|
|
- Print informative labels for outputs.
|
|
|
|
This guide will evolve. Contributions and suggestions are welcome.
|