mirror of
https://github.com/JuliaFEM/JuliaFEM.jl.git
synced 2026-08-06 04:21:33 +00:00
159e738038
- Removed redundant H1 heading (already in YAML frontmatter) - Moved "Coding Standards" above "Architecture" in What's Here section - Updated "Before Contributing" list to prioritize standards (now item 2) - Marked coding standards as REQUIRED for all contributions - Changed reference from "Code Style" to "Coding Standards" (file renamed) - Added blank line after "We assume you:" for better formatting
2.1 KiB
2.1 KiB
title, description, date, author, categories, keywords, audience, level, type
| title | description | date | author | categories | keywords | audience | level | type | |||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| JuliaFEM Contributor Manual | Technical guide for developers and contributors | 2025-11-09 | Jukka Aho |
|
|
developers | advanced | manual |
Audience: Developers, contributors, advanced users who want to extend or modify JuliaFEM.
This manual is technical and detailed - it explains HOW the code works and WHY we made certain design choices.
What's Here
- Testing Philosophy: How and why we test
- Coding Standards: Required conventions for all contributions (variable names, types, performance)
- Architecture: Module structure, data flow, key abstractions
- Performance: Zero-allocation design, profiling, benchmarking
- Adding Elements: How to implement new element types
- CI/CD: Continuous integration, releases, versioning
- Git Workflow: Branching, commits, pull requests
What's NOT Here
- User tutorials (see
docs/user/for that) - Deep mathematical theory (see
docs/book/for that) - "How do I solve problem X?" (that's user docs)
Philosophy
"Show me the code AND tell me why."
We assume you:
- Know Julia reasonably well
- Understand FEM basics
- Want to add features or fix bugs
- Care about performance and correctness
- Need to understand design rationale
Before Contributing
- Read Testing Philosophy
- Follow Coding Standards - REQUIRED for all contributions
- Understand Architecture
- Check Performance Guidelines
- Review Git Workflow
Key Principles
- Type stability: No
Any, noDictwithout types - Zero allocations: Hot paths should allocate nothing
- Immutability: Prefer
structovermutable struct - Composition: Use tuples and free functions, not OOP hierarchies
- Explicit: No magic, user knows what happens
- Test first: Write tests before fixing bugs
Start here: Testing Philosophy | Architecture Overview