Rules? What rules? There arn't any rules!
But there are lessons. Rules are to be followed, but lessions are to be applied using judgement.
Get it done fast, get it done right, get it done cheaply. Pick two.
These lessons are about the right way to write programs, for some value of "right". The particular value of right is expressed by the following:
Programs are written for people to read, and only incidentally for machines to execute.
The reasoning behind this is that unless someone knows what a program does, the program is useless.
There are some assumptions underlying these lessons. If you're going to run a program once, and then throw it away, none of this matters.
Or, you may be counting on AI telling you what the program does and never having a human read the code. As I write this, depending entirely on AI in this way, in the long term, is an untested approach. If you want to bet on keeping your programs running long-term, only with AI, go for it and good luck. This page is not for you.
I particularly question whether AI will be able to tell you why your programs are written the way they are written, which is part of what's involved in writing code for humans to read. If you don't know what problem your code is trying to solve, the "why" of your code, you don't really know what the code is doing.
The short answer is that I feel like it.
The longer answer is that the AI written code I've seen is written like it was done by a programming novice. Albiet a novice with an infallable memory that has ingested a huge amount of the world-wide code-base.
Given Sturgeon's law, this means the AI has seen a huge amount of crap. As they say: Garbage in. Garbage out.
If you're writing code with AI assistance, read the code. Then, use your judgement. Should the code be changed in light of the lessons below?
If something needs fixing, look for similar errors elsewhere and fix those too.
Try not to make the same mistake in the future.
For the most part, the code should explain itself -- in so far as how it does what it does.
The right choice of names, for variables, functions, etc., goes a long way in this regard.
There are many ways to go about this. Ultimately, a program is a model. Of something. A model that is usually built by combining smaller pieces of code, that are themselves also models.
To use a model you need to know why it exists, what it is, and how it works. Most of the time, the how should be clear from the code itself.
Comment to explain what you're doing and why you're doing what your doing.
Explaing what can be as simple as summarizing the state of the program's model at a particular point in the code and pointing out that this makes some next step in the problem solving process doable.
Explaining why usually involves explaining why the model is the way it is, which means declaring the problem to be solved and in what way the model addresses the problem at hand.
E.g. "Inventory is low, schedule a replacement order" "Inventory is low" explains what the state is, in terms that are meaningful to the problem at hand. "schedule a replacement order" explains why we care, we don't want to run out.
Writing instead "There are only 150 units left, notify the supply department", summarizes what the code is doing, but at a level of detail that relates a lot to how the code works and very little to the problem the code is trying to solve. It also leaves a lot of questions unanswered. "Is 150 a little or a lot?" "Why am I telling supply this?" Etc.
Don't reinvent the wheel, whether badly or not.
If the functionality already exists and is widely used, use it. Even if the standard tool is complex. Learn how to use the tool to write something simple and clear.
Collary -- the old saying: Standard is better than better.
Nobody, meaning the people reading your code, wants to learn some special, and likely limited, approach to doing something everybody else already knows how to do.
Only put code inside a loop if it needs to be executed repeatedly.
If the state the code uses does not change, why is it being executed repeatedly? Ask yourself, why does what the code accomplishes need to be executed repeatedly?
Use the state you have at hand.
Don't go computing something new when you've already got the information you need in the variables you already have.
Write in the style which is in-use.
Don't add new code in a formatting style that differs from the one the program already uses.
Use the existing naming conventions, and abbreviations or lack thereof.
If the code looks overly complicated, it probably is.
Maybe there's a simpler way to do it. Maybe the code needs to be broken into smaller pieces. There's almost always alternative ways to approch the problem.
A clear understanding of the problem you're solving, which can mean developing a short problem statement, often opens the mind to alternative approaches -- which may be simpler.