Live data from Hacker News

Write code like a human will maintain it

unstack.io

231–240 of 325 posts

Re: Write code like a human will maintain it

#231

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:…

My experience is the more things you add to the list, the worse agents perform (I'm not exactly the first person to notice this) I actually have a pretty simple set of instructions right now and Claude still regularly messes them up. Like, my first instructions are: - Never commit to git without permission. - Never sign commit messages You know what it constantly does? Commits without permissions and signs commit mes…

I personally find that models are trending towards ignoring any instructions given to them, so depend more on vendor-instilled behavior. Anecdotal, but I had bad experiences with OAI's new 5.6.

Re: Write code like a human will maintain it

#232
post #231

Earlier quoted context omitted.

My experience is the more things you add to the list, the worse agents perform (I'm not exactly the first person to notice this) I actually have a pretty simple set of instructions right now and Claude still regularly messes them up. Like, my first instructions are: - Never commit to git without permission. - Never sign commit messages You know what it constantly does? Commits without permissions and signs commit mes…

I personally find that models are trending towards ignoring any instructions given to them, so depend more on vendor-instilled behavior. Anecdotal, but I had bad experiences with OAI's new 5.6.

Same for me. Not sure if its intentional (do they want to push people towards workflows that will burn more tokens?) or if it's just a side effect, but it's very annoying. I refuse to use tools that dictate how I develop, I'm just going to switch models to less opinionated ones.

Re: Write code like a human will maintain it

#233
post #170

Crazy how many engineers in here just say they are using another prompt on top. From my experience that makes things worse. It does abstractions, but the wrong ones. It overcomments, confusing future calls of the LLM. To me building on multiple scalable systems this has been the most dangerous part of LLMs. On a good codebase it will work good, but it will maek it worse, so you keep using it, till it doesnt work and…

>> AI isn’t always faster

It is always faster if you don't care about quality and need to churn out code as fast as possible to close tickets.

Re: Write code like a human will maintain it

#234

Earlier quoted context omitted.

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 :)

Is that actually true? Just because English treats scents as only describable by analogy doesnt mean all languages do. There are a number of languages with scent descriptions for aspects of a smell that are transferrable. [1] That suggests everyone is capable of decomposing a scent into components the same way.

If that's true, we're left with a question equivalent to "does everyone see the same red?". As far as I know, the pure version of that question cannot be answered because subjective experiences of sensation cannot be transferred. And at that point, I'd say the manner in which they're experienced differently is equivalent.

1. https://youtu.be/w3KswMaEBiI

Re: Write code like a human will maintain it

#235

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:…

My experience is the more things you add to the list, the worse agents perform (I'm not exactly the first person to notice this) I actually have a pretty simple set of instructions right now and Claude still regularly messes them up. Like, my first instructions are: - Never commit to git without permission. - Never sign commit messages You know what it constantly does? Commits without permissions and signs commit mes…

I’m not a Claude code user, is there really no way to get it to not commit to git other than “asking it nicely in a prompt”? I thought there was some sort of permission system?

Re: Write code like a human will maintain it

#236

Earlier quoted context omitted.

Sometimes the fact you mentioned “signing commit messages” is exactly why it starts signing commit messages, and it’s better to start with no prompt at all. Negative prompting is very unreliable. Giving exact instructions on how you want commits made will give you better results.

How am I supposed to take this tool seriously if it struggles with the concept of "dont"? if what you're suggesting is true, then more important instructions like "Don't delete the production database" are a problem. I shouldn't need to consider how to phrase "Don't delete the production database" in a positive manner. Isn't the point of an AI agent that it understands my intent and I don't need to hold its hand? I'm…

Absolutely. It should simply not have permissions to delete your production database, can’t rely on prompting alone for that kind of safety.

These are still stochastic machines, guardrails must be inserted at the system level.

They are getting better every day about managing their own guardrails, so we will get there eventually.

Re: Write code like a human will maintain it

#237
post #125

## HARD RULE - design scope must always be maintained and no function should ever be longer than XXX lines and no class should have more than Y methods. Create new classes and subclasses and refactor until the criteria are met. You'd be surprised how readable this makes the code when XXX is about the size of your vertical screen and Y is relatively small.

Similarly, I try to follow an “around 400 lines per MR” (violations can exist for test code if something is particularly gnarly).

I’ll build whole features and then break them apart into several MRs that chain off each other.

Everyone who has seen this style has been really grateful for it and finds my code much more readable. I encourage and embody the pattern everywhere I go.

Exception: For mass find/replace or auto-linter changes, that’s all one MR, and is usually pair programmed so the other person can confirm that’s all I did, still easing cognitive load.

Re: Write code like a human will maintain it

#238
post #125

## HARD RULE - design scope must always be maintained and no function should ever be longer than XXX lines and no class should have more than Y methods. Create new classes and subclasses and refactor until the criteria are met. You'd be surprised how readable this makes the code when XXX is about the size of your vertical screen and Y is relatively small.

but then you end up with a clusterfuck of classes?

You’d be surprised how often this doesn’t end up happening, especially in languages that are supportive of this style:

Kotlin, Python and Typescript, to name a few. A lot of functions you write are helper functions, wrapper functions, system functions, etc and all 3 languages support making things modules of interconnected concepts, extension functions, etc.

You can make code very readable this way - arguably more readable.

Have you ever had so many tests for a single class that you’ve broken the test class into a package and have a whole file / test class for each big method? Same idea! :)

Re: Write code like a human will maintain it

#239
post #231

Earlier quoted context omitted.

My experience is the more things you add to the list, the worse agents perform (I'm not exactly the first person to notice this) I actually have a pretty simple set of instructions right now and Claude still regularly messes them up. Like, my first instructions are: - Never commit to git without permission. - Never sign commit messages You know what it constantly does? Commits without permissions and signs commit mes…

I personally find that models are trending towards ignoring any instructions given to them, so depend more on vendor-instilled behavior. Anecdotal, but I had bad experiences with OAI's new 5.6.

I let it have elevated permissions and it started doing some crazy things like figuring out I had zsh and running zshell commands instead of the common ones.

Re: Write code like a human will maintain it

#240

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…

You're forced to document every check and thought related to development until you're wiring a manual on how to be laid off (unless self employed or otherwise critical).

Which is fine. One should write quality docs and all that. But it seems exactly like training my offshore contract replacement instead of building tools for my own use. Except that income doesn't even go to a human just a black box datacenter company and shareholders.

Post reply on HN