Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Write code like a human will maintain it

unstack.io

Post reply on HN
Print view View original

171–180 of 325 posts

Re: Write code like a human will maintain it

#171

Post by djjdfjjddndn »

dualvariable wrote: post #146
egonschiele wrote: post #95

In a similar vein, here's my favorite prompt: "Please review the tests you've written. Will the tests actually test what they're meant to? If the code breaks, will the test fail?" It's amazing how often LLMs will write tests that don't test anything.

I've seen a lot of human-written tests that wind up testing the testing framework and not the actual code.

yeah but it'll be one or two at a time that you find like that. LLMs will output two dozen tests for one line of real code, where you maybe needed one

Re: Write code like a human will maintain it

#172

Post by clintonb »

dualvariable wrote: post #167

I think the usable counterpoint here is that you can refrain from excessively DRY'ing code up and defer it until later. There's a huge cost to Clean-Code-style DRY'ing of your codebase which is that you wind up creating all kinds of little functions that all add cognitive overhead to reading your codebase, and that premature DRY'ing can lead to picking the wrong abstractions. If you can tolerate a bunch of copypasta,…

My threshold is three. The third time I duplicate code/behavior is when I start to think about DRYing said code/behavior.

Re: Write code like a human will maintain it

#173

Post by blanched »

willturman wrote: post #152
throwaw12 wrote: post #62

Earlier quoted context omitted.

Can you share your list? I am curious what does it contain, for me a lot of times its a back and forth with agent until it "looks good to my eyes and taste", but haven't written any such list yet, because it is context dependant, in some projects I forgive minor issues, or allow magical numbers, but in other projects I force agent to use constants with meaningful names `SECONDS_IN_A_DAY = 24 * 60 * 60`

It is interesting that the output of code is associated with sight and taste, while the quality of the code itself is associated with smell . https://en.wikipedia.org/wiki/Code_smell *edit: that wikipedia page ^ itself is a pretty answer to your request for a list of things to avoid when writing maintainable code.

Pairs nicely with the fact that smell is the sense most likely to be experienced differently between two people :)

Re: Write code like a human will maintain it

#174

Post by baptou12 »

sheept wrote: post #165
baptou12 wrote: post #122

I agree, but “write code like a human will maintain it” can also be limiting: if LLMs reduce the cost of maintaining more explicit or verbose code, we should use that to raise the standard, not preserve compromises made for human convenience.

Aren't LLMs trained on and optimized for human code? In general, anything that is concise is more effective as context for the LLM, whether it be your CLAUDE.md or code, since LLMs are meant to model human language.

Humans can share context outside the code, while LLMs need it to be more explicitly structured inside. And if we keep the slightly verbose good practices that already help humans understand the intent, we kind of get the best of both worlds.

Re: Write code like a human will maintain it

#175

Post by vorticalbox »

yCombLinks wrote: post #159
vorticalbox wrote: post #148

> There's a much cleaner way to do this - a shared helper disagree, then you end up with something this this function checkAll(target, conditions) { return Object.entries(conditions).every(([path, expected]) => { const value = path.split('.').reduce((o, k) => o?.[k], target); return typeof expected === 'function' ? expected(value, target) : value === expected; }); } and const ok = checkAll({ user, account }, { 'user.…

No, you've created a generic condition checker, which is where all of your complexity comes from. Further, you've left the actual check to be duped in all callers.

[dead]

Re: Write code like a human will maintain it

#178

Post by radlad »

xhrpost wrote: post #155
cadamsdotcom wrote: post #29

Write yourself a /review command. That is an empty markdown file at `.claude/commands/review.md`. In it, put a checklist of things the agent should look for. When you’re ready to have your agent review the code, type `/review`. The checklist will be examined and it’ll plan out some findings to ask you if you want them fixed. Mine starts with “Enter plan mode. Examine the differences on this branch vs. main. Consider:…

> Any time I notice something in code review and have to get the agent to fix it.. I throw it on the list! My list is like 200 items now. This is a gripe I've had with AI tools for a while now. Though it's gotten somewhat better in time, but we don't really know what to expect from the tool in terms of quality. Ex. I'd expect a human engineer to probably not use a brand new assertion library for a new test when there…

I find project-wide or subpackage-wide (for sufficiently large projects) CLAUDE.md's that document patterns (including for tests) solves this.

/init will make a project-wide one, or you can instruct it to "Create CLAUDE.md in any sub-directory that is sufficiently complex" then modify from there.

Re: Write code like a human will maintain it

#179

Post by SomeHacker44 »

SoftTalker wrote: post #100
alexpotato wrote: post #3

There is an old quote: "Add comments to your code under the assumption that the next person to maintain it is a homicidal maniac who knows where you live"

Used to work with a guy who would frequently say "a comment is an apology" i.e. the comment is there because the code itself is not clear. That can be the case, but I generally find more comments better than fewer, especially if they relate the code to actual business or functional requirements and don't just restate what the code is doing. Years ago I would often write comments first. I.e. start with describing the…

I still code this way.

Re: Write code like a human will maintain it

#180

Post by duskdozer »

latexr wrote: post #43
schnebbau wrote: post #7

That sounds like a good idea, but shipping 10x as many features and bugfixes sounds better. I started using AI with the best intentions. Checking everything before committing. Improving output by hand if it didn't quite follow the existing code style guidelines or variables were not named as well as they should be. Or if it did something sloppy or hacky. Now, AI GOES BURRRRRRRRRRRR! If the tests pass it's good to shi…

Man, I bet Jia Tan is simultaneously kicking themselves and having a field day. All those years of wasted effort gaining trust and making good contributions to try to land a sophisticated backdoor into a tool via layers of indirection, and then not long after we have devs just going “I don’t need to read this code, or prioritise, or think about what makes sense, just prompt for fractals of kitchen sinks and ship it”.…

It's a good time to archive pre-LLM copies of the programs you use and make sure you can build them.
Post reply on HN