Coding Standards document
AT-AT Coding Standards Document
Section titled “AT-AT Coding Standards Document”Introduction
Section titled “Introduction”This document defines the coding conventions and standards used across all three layers of the AT-AT (API Threat Assessment Tool) project to ensure our code is uniform, clear, reliable and efficient, which includes:
- A JavaScript-based REST API (Node.js + Express)
- A Python engine for API threat analysis
- A React-based frontend user interface
1. JavaScript API (Node.js + Express)
Section titled “1. JavaScript API (Node.js + Express)”Code Style
Section titled “Code Style”- Indentation: 2 spaces
- Semicolons: Always use
- Quotes: Single quotes preferred
- Trailing commas: Required in multiline constructs
- Brace style: Always use braces for blocks
// Goodif (user) { return true;}
Naming Conventions
Section titled “Naming Conventions”camelCase
for variables, functions and filenames- UPPER_SNAKE_CASE for environment variables
Comments
Section titled “Comments”Single-Line Comments: Use ’ // ’ for single-line commments Multi-Line Comments: Use ’ /* … */’ for multi-line comments
Example of Comments from coverage.js
// scripts/coverage.js - Coverage Analysis Helper
/** * Parse coverage summary and display formatted results */function displayCoverageSummary() { ... }
Error Handling
Section titled “Error Handling”For error handling, try-catch statements are used to ensure errors are properly caught and handled.
2. Python Engine
Section titled “2. Python Engine”Code Style
Section titled “Code Style”- Follow PEP8 standards
- Indentation: 4 spaces
Naming Conventions
Section titled “Naming Conventions”snake_case
for variables, functions, and filenamesPascalCase
for class names
Logging
Section titled “Logging”Use the logging
module instead of print()
for production logs:
import logginglogging.info("Spec uploaded successfully")
Imports
Section titled “Imports”- Standard imports first, third-party next, local modules last
import osimport yamlfrom engine.scanner import ThreatScanner
3. React Frontend
Section titled “3. React Frontend”Folder Structure
Section titled “Folder Structure”Organize by feature, not file type. Example:
/src /components Navbar.jsx TagEditor.jsx /pages UploadPage.jsx ReportPage.jsx /assets logo.svg /styles global.css
JavaScript & JSX
Section titled “JavaScript & JSX”- Use
camelCase
for functions and variables - Use
PascalCase
for components - Use arrow functions for components
- Keep components focused and reusable
const UploadForm = () => { return <form>...</form>;};
- Use CSS Modules or component-level styles
- Use
kebab-case
for class names - Example:
tag-list.module.css
State & Props
Section titled “State & Props”- Use
useState
,useEffect
,useContext
appropriately - Validate props with
PropTypes
or TypeScript if used
API Integration
Section titled “API Integration”Use a dedicated api.js
or services/
folder for API calls:
export const fetchEndpoints = async (apiId) => { const res = await fetch(`/api/endpoints`, { ... }); return res.json();};
4. Git & Workflow Standards
Section titled “4. Git & Workflow Standards”Branch Naming
Section titled “Branch Naming”main
→ Stable codedev
→ Development integrationfeature/<name>
→ Feature branchesfix/<name>
→ Bug fixes
Commits
Section titled “Commits”Use clear, human-readable commit messages that briefly describe the change
Pull Requests
Section titled “Pull Requests”- Use descriptive titles
- Link related issues if tracked
- Ensure all tests/linting pass before merging
By adhering to these conventions, all contributors to the AT-AT project ensure a cohesive, readable, and professional-grade codebase for API threat assessment.