coding best practice

coding best practice.md

coding best practice

This best practice doc has 3 major parts.

1. building server and plugin
2. how to place logging
3. how to import with alpha symbol path.

building server and plugin

very important: When changes are made to server code then you need to rebuild the server. when you rebuild server (you can build the server in terminal). I have to manually restart the server after its been rebuild. so you have to to stop after rebuilding it so I can do that. after I have restarted the server manually I will tell you and you have to rejoin the channel and proceed with calling commands etc. Remeber this in the continuation. to build server use: cd src/server && bun run build (WE DO NOT RUN SERVER IN TERMINAL, THE SERVER RUNS INSIDE CLINES OWN MCP SERVICE, DO NOT TRY TO RUN THE SERVER IN THE TERMINAL!)

IMPORTANT: WHEN changes to plugin is made. you need to rebuild the plugin (you build the plugin in terminal), but no need to stop. the plugin hotloads. so just call the command right after. to build plugin use: cd src/plugin && bun run build

Also add a lot of logging when we debug and edit code. more the better as it lets use diagnose things faster.

rember this in the continuation please!!!!

logging best practice:

Here's a structured prompt based on your request:

Code Enhancement Request: Comprehensive Logging Implementation

Priority: HIGH

Request Summary

Please implement the suggested edit with extensive debugging and logging throughout the solution to prevent lengthy debugging cycles.

Key Requirements

1. Core Logging Implementation

• Add detailed logging around the primary edit/solution
• Include logging for both:
  • Caller methods (who invokes the functionality)
  • Receiver methods (who processes the requests)

2. Comprehensive Coverage

• Identify all methods that interact with this edit
• Add logging to every related method in the call chain
• Include entry/exit points for each method
• Log parameter values and return values

3. Debugging Information to Include

• Method entry/exit with timestamps
• Input parameters and their values
• Intermediate processing steps
• Error conditions and exception handling
• Performance metrics (execution time)
• State changes and data transformations

Rationale

To avoid:

• ❌ Multiple back-and-forth debugging sessions
• ❌ Incremental changes with minimal visibility
• ❌ Constant requests for additional logs
• ❌ Frequent server restarts for debugging
• ❌ Time waste on troubleshooting

Expected Outcome

A robust, well-instrumented solution that provides complete visibility into the execution flow, making any future issues immediately diagnosable through comprehensive logs.

Please prioritize logging comprehensiveness over code brevity in this implementation.

**when you make changes. ** I BEG YOU TO BE MORE AGRESSIVE WITH ADDING ADDITIONAL LOGGING. Not just where edits are made. but also in code that calls the code that is edited and code the edited code calls.

When refactoring or making edits:

**use @ paths **

here is an example of an @ path

import { FontUtils } from "@/commands/utils/FontUtils";

(DO NOT USE RELATIVE PATHS!!!!!!)

Commentings carry over comments. from old code if you refactor

always write javadoc and inline comments for new code or edited code