ZacharyZhang-NY
e74dafcd36
Three independently ugly bugs that all fed the same log flood:
* Electron's `WebFrameMain.send` writes every "Render frame was disposed"
to stderr via `console.error`. When the worker fans a second
agent-event past a reloading renderer, we produced thousands of
identical lines and stalled the main loop on stderr I/O. Added a
`mainFrame.detached` guard so the send is short-circuited before
Electron's own catch block fires, and installed a targeted filter in
`suppress-warnings.ts` (now actually imported from the entry point)
so the specific `console.error("Error sending from webFrameMain:"…)`
noise never reaches the terminal. Any other payload still surfaces.
* `dispatchAgentMessage` accepted the human-reader sentinel as a wake
target when an agent replied to `__board__` — `wakeAgentIfPossible`
then called `db.getAgent("__board__")`, threw, and the dispatcher
kept repeating on every send. Strip `HUMAN_SENDER_ID` at
`resolveMessageWakeTargets`, and keep a defense-in-depth guard in the
heartbeat so a stray caller (future automation fan-out) cannot
reintroduce the crash.
* Pi's skills loader rejects any SKILL.md whose frontmatter `name`
diverges from its parent directory. The four bundled `my-writing-style`
copies declared `name: writing-style-skill`, so every install emitted
a warning and dropped the skill. They also lived as orphan gitlinks
(mode 160000 without .gitmodules), and the global `*.md` gitignore
hid every other SKILL.md from version control. Fixed the frontmatter
to match the dir, converted the dangling submodules to plain trees,
and allowlisted `builtin-skills/**/*.md` so a fresh clone carries the
catalogue instead of silently losing it.
2.9 KiB
2.9 KiB
title, impact, impactDescription, tags
| title | impact | impactDescription | tags |
|---|---|---|---|
| Keep Functions Small | CRITICAL | enables comprehension at a glance | func, size, readability, comprehension |
Keep Functions Small
Functions should be small. They should be smaller than that. Functions should hardly ever be 20 lines long. Each function should do one thing, do it well, and do it only.
Incorrect (large function doing multiple things):
public void renderPageWithSetupsAndTeardowns(PageData pageData, boolean isSuite) {
if (isTestPage(pageData)) {
WikiPage testPage = pageData.getWikiPage();
StringBuffer newPageContent = new StringBuffer();
includeSetupPages(testPage, newPageContent, isSuite);
newPageContent.append(pageData.getContent());
includeTeardownPages(testPage, newPageContent, isSuite);
pageData.setContent(newPageContent.toString());
}
}
private void includeSetupPages(WikiPage testPage, StringBuffer buffer, boolean isSuite) {
if (isSuite) {
WikiPage suitePage = PageCrawlerImpl.getInheritedPage(
SuiteResponder.SUITE_SETUP_NAME, testPage);
if (suitePage != null) {
WikiPagePath pagePath = testPage.getPageCrawler()
.getFullPath(suitePage);
String pagePathName = PathParser.render(pagePath);
buffer.append("!include -setup .")
.append(pagePathName)
.append("\n");
}
}
// ... 20 more lines
}
Correct (small, focused functions):
public void renderPageWithSetupsAndTeardowns(PageData pageData, boolean isSuite) {
if (isTestPage(pageData))
includeSetupsAndTeardowns(pageData, isSuite);
}
private void includeSetupsAndTeardowns(PageData pageData, boolean isSuite) {
WikiPage testPage = pageData.getWikiPage();
String content = buildPageContent(testPage, isSuite);
pageData.setContent(content);
}
private String buildPageContent(WikiPage testPage, boolean isSuite) {
return getSetups(testPage, isSuite) +
testPage.getContent() +
getTeardowns(testPage, isSuite);
}
Each function is 3-5 lines. Each does exactly one thing. Each is at one level of abstraction.
When NOT to apply this pattern:
- If a 15-20 line function does one thing at one level of abstraction, it does not need further decomposition. The goal is comprehensibility, not minimizing line count.
- Do not extract functions that are only called from one place and whose names merely restate their implementation — this adds indirection without clarity.
- Ousterhout's "deep modules" critique: extremely small functions can create "shallow modules" that spread logic across many files, forcing readers to jump between functions to understand a single behavior. Balance depth (functionality per interface) against size.
Reference: Clean Code, Chapter 3: Functions