Skip to content

CONTRIBUTIONS.md

Latest commit

 

History

History
204 lines (131 loc) · 3.88 KB

CONTRIBUTIONS.md

File metadata and controls

204 lines (131 loc) · 3.88 KB

Contributing to sxwm

Firstly, thanks for taking the time to contribute to sxwm! Your interest in improving the project is truly appreciated.

Code Style and Formatting

There is an included clangd formatting file, but it won’t do everything for you. Please follow the rules below to keep the codebase consistent and clean.

Indentation

  • Use tabs for indentation — never spaces.

Blocks

  • All blocks of C code must be wrapped in curly braces {}.
  • Each statement must be on its own line.
  • Always add a space between keywords and the opening parenthesis.

Example:

if (x) {
    y();
}
else {
    z();
}

Comments

  • Use this format for comments to maintain consistency:
/* this is a comment */
  • For temporary notes, use:
/* TODO: something to fix */
/* FIXME: known issue */

Function Declarations

Functions should look like this:

void function_x(void)
{
}

void function_y(int y)
{
}

Variable and Function Naming

  • Use snake_case for all variable and function names.

Examples:

int some_variable = 2;
float other_variable = 5;

void do_something(void);

Header Guards

If you create a header file, use header guards:

#ifndef HEADER_NAME_H
#define HEADER_NAME_H

// content

#endif /* HEADER_NAME_H */

Line Length

  • Keep lines under 100 characters when possible to improve terminal readability.

Whitespace

  • No trailing whitespace.
  • One blank line between function definitions.
  • Avoid unnecessary vertical spacing.

Include Order

Organize includes like this:

  1. Corresponding header (if any)
  2. Standard library headers
  3. Other project headers

Build

  • make must succeed with no warnings on your system.
  • Don’t commit build artifacts (e.g., .o, sxwm) or backup files (e.g., *~).
  • Test your changes, especially on multi-monitor setups using Xephyr.

File Layout

  • Don’t create new .c or .h files unless absolutely necessary.
  • Keep most changes within sxwm.c to maintain cohesion.

Submitting Changes

  • Open a pull request with a clear description of what and why.
  • Keep one purpose per commit — don’t mix unrelated changes.
  • If fixing a bug, describe how to reproduce it.
  • If adding a feature, ensure it fits with sxwm’s minimalist philosophy.
  • Open separate PRs for unrelated changes.

Git Commit Guidelines

  • Use imperative mood: Add foo, not Added foo.
  • Keep the summary under 50 characters.
  • Add a detailed body if needed.

Example:

Fix crash when window is closed

Previously, sxwm would segfault if a client closed itself.
This patch adds a check for null pointers before accessing window data.

Tooling & Analysis

  • Use the provided .clang-format file where applicable.

  • You may optionally run:

    • cppcheck
    • clang-tidy

  • Avoid committing debug code like stray printf() or fprintf(stderr, ...).

Editor Configuration

A sample .editorconfig file is provided (or you can request one). It ensures editors match the project’s formatting conventions.

Documentation

Update all relevant documentation if applicable:

  • sxwm.1
  • README.md
  • default_sxwmrc
  • CHANGELOG.md

Respect the Existing Structure

  • For large changes, open an issue for discussion first.
  • Do not change code for personal style unless it improves clarity or solves a specific problem.

Testing Checklist

Please ensure the following before opening a PR:

  • Code builds without warnings
  • Changes are fully tested
  • PR includes a clear explanation
  • Configuration reload works (if relevant)

Code Review Etiquette

  • Be respectful and open to feedback.
  • Feel free to ask questions about any review comments.
  • Reviews are collaborative and meant to improve the code, not criticize you personally.

Happy hacking!