lpc-coding-style

Enforces LPC coding conventions for oxidus-mudlib repository modules.

8|3|Updated Sep 29, 2021
One-click install
npx skills add https://github.com/gesslar/oxidus-mudlib --skill lpc-coding-style
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: lpc-coding-style
Source: https://github.com/gesslar/oxidus-mudlib/tree/main/.claude/skills/lpc-coding-style
Command: npx skills add https://github.com/gesslar/oxidus-mudlib --skill lpc-coding-style

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

LPC coding style and formatting conventions ensure that all LPC work in the oxidus-mudlib project adheres to a single, readable standard, reducing onboarding time and merge conflicts.

Core Features & Use Cases

  • Spacing and indentation rules (2 spaces, no trailing spaces, single trailing newline).
  • Bracing style, control-flow formatting, and idiomatic LPC patterns to improve readability.
  • Naming conventions and access modifiers (camelCase, private by default, __ prefix for file-global vars) plus documentation conventions.
  • Use Case: When starting a new LPC object or updating existing modules, consult this guide to align with project conventions.

Quick Start

Consult this guide before writing or modifying any LPC code to ensure consistent project-wide style.

Frequently Asked Questions about lpc-coding-style

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
What are the standard LPC coding conventions for mudlib development?

Standard LPC coding conventions require 2-space indentation, specific bracing styles, camelCase naming, and LPCDoc-compliant comments for public APIs to ensure consistent readability across modules.

How do I format visibility modifiers and file-global variables in LPC?

Format visibility modifiers explicitly on globals and functions, and prefix private file-global variables with a double underscore (__), keeping modules private by default to enforce strict encapsulation.

When should I apply these coding style rules to LPC modules?

Apply these coding style rules when creating new LPC objects, updating existing modules, or refactoring code to align with project-wide conventions and reduce merge conflicts.

What spacing and newline rules must LPC files follow?

LPC files must use 2-space indentation, eliminate all trailing whitespace, and include exactly one single trailing newline at the end of the file to maintain clean formatting.

Why use consistent naming conventions and access modifiers in LPC?

Consistent naming conventions and access modifiers in LPC reduce onboarding time and merge conflicts by enforcing a single readable standard across the entire repository codebase.