Contributing to LayKit

Thank you for your interest in contributing to LayKit! This guide will help you get started.

Getting Started

Prerequisites

Rust 1.70 or later
Git
A GitHub account
Familiarity with Rust and Git workflows

Setting Up Development Environment

Fork the repository

# Fork on GitHub, then clone your fork
git clone https://github.com/YOUR_USERNAME/laykit.git
cd laykit

Add upstream remote

git remote add upstream https://github.com/giridharsalana/laykit.git

Install Rust (if needed)

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

Build and test

cargo build
cargo test
cargo clippy
cargo fmt --check

Development Workflow

1. Create a Branch

git checkout -b feature/your-feature-name
# or
git checkout -b fix/bug-description

Branch naming conventions:

feature/ - New features
fix/ - Bug fixes
docs/ - Documentation changes
refactor/ - Code refactoring
test/ - Test additions/changes

2. Make Changes

Follow the coding standards and write tests for your changes.

3. Test Your Changes

# Run tests
cargo test

# Run tests with output
cargo test -- --nocapture

# Check formatting
cargo fmt --check

# Run clippy
cargo clippy -- -D warnings

# Build documentation
cargo doc --open

4. Commit Changes

git add .
git commit -m "feat: add new feature description"

Commit message format:

type: brief description

Longer description if needed.

Fixes #issue_number

Types:

feat: - New feature
fix: - Bug fix
docs: - Documentation
test: - Tests
refactor: - Code refactoring
perf: - Performance improvement
chore: - Maintenance

5. Push and Create PR

git push origin feature/your-feature-name

Then create a Pull Request on GitHub.

Code Style

Rust Style

Follow Rust standard style using rustfmt:

cargo fmt

Key points:

Use 4-space indentation
Line length: 100 characters (preferred)
Use trailing commas in multi-line constructs
Organize imports: std, external crates, internal modules

Example:

#![allow(unused)]
fn main() {
use std::collections::HashMap;
use std::error::Error;
use std::fs::File;

use laykit::{GDSIIFile, OASISFile};

pub fn process_file(path: &str) -> Result<(), Box<dyn Error>> {
    let gds = GDSIIFile::read_from_file(path)?;
    // Process...
    Ok(())
}
}

Documentation

Document all public items:

#![allow(unused)]
fn main() {
/// Reads a GDSII file from the specified path.
///
/// # Arguments
///
/// * `path` - Path to the GDSII file
///
/// # Returns
///
/// Returns a `Result` containing the `GDSIIFile` or an error.
///
/// # Examples
///
/// ```
/// use laykit::GDSIIFile;
///
/// let gds = GDSIIFile::read_from_file("design.gds")?;
/// # Ok::<(), Box<dyn std::error::Error>>(())
/// ```
pub fn read_from_file(path: &str) -> Result<Self, Box<dyn Error>> {
    // Implementation...
}
}

Error Handling

Use Result types consistently:

#![allow(unused)]
fn main() {
// Good
pub fn process() -> Result<Output, Box<dyn Error>> {
    let data = read_file()?;
    Ok(process_data(data))
}

// Avoid unwrap in library code
// Bad
pub fn process() -> Output {
    let data = read_file().unwrap(); // Don't do this!
    process_data(data)
}
}

Testing

Writing Tests

Every new feature should have tests:

#![allow(unused)]
fn main() {
#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn test_new_feature() -> Result<(), Box<dyn Error>> {
        // Setup
        let input = create_test_input();
        
        // Execute
        let result = new_feature(input)?;
        
        // Verify
        assert_eq!(result.value, expected_value);
        
        Ok(())
    }
}
}

Test Coverage

Aim for:

✅ 80%+ code coverage for new features
✅ Tests for all public APIs
✅ Tests for error conditions
✅ Integration tests for complex features

Pull Request Guidelines

Before Submitting

Checklist:

✅ Code compiles without warnings
✅ All tests pass
✅ cargo clippy passes
✅ cargo fmt applied
✅ Documentation updated
✅ New tests added

PR Description

Include in your PR:

## Description
Brief description of changes

## Type of Change
- [ ] Bug fix
- [ ] New feature
- [ ] Breaking change
- [ ] Documentation update

## Testing
How has this been tested?

## Checklist
- [ ] Tests pass locally
- [ ] Code follows project style
- [ ] Documentation updated