If you work actively with software and source code you really appreciate when the code, and the system it's a part of, is well structured. There is a lot of litterature in that area, Robert C. Martin's Clean Code andClean Architecture is mandatory reading, another example is Refactoring by Martin Fowler.

More tips includes SOLID, an abbreviation for some simple(?) rules for good object-oriented design that to a great extent can also be re-interpreted to apply for non-object oriented languages. Good code doesn't smell, so Code Smells is also a good list of things that you want to avoid. Something I often do when I spot some code smell is to search for a refactoring that helps.

And there are numerous other tips. But also take care, I've seen programmers going berserk over getting the perfect code before proceeding. Be content with leaving the code a bit better than you found it (the Scout rule).

A "rule" that is as simple as it is effective is the Law of Demeter. A couple of basic properties we are looking for in good code is cohesion, abstraction and low coupling. The Law of Demeter works fine as a guideline to achive this.

One type of dependency, or high coupling, connects units more tightly than necessary is that clients needs to know which fields a used class or structure has. That leads to changes in all clients if a field is modified.

The Law of Demeter does not have anything to do with the greek god, it comes from the name of a project that had it as one of its rules for design. The "law" says

A method can only access either locally-instantiated variables, parameters passed in, or instance variables,

Maybe not so obvious what it means, but in priciple it means that a function or method can not navigate "down" into those structures that it uses. A simple way to express this is

Only one dot per line

Of course, dots only applies to some languages, '->' is another common operator for accessing fields. You can probably figure out what operators you should watch out for in your programming language.

Thanks to Corey Hines, who in his little book Understanding the Four Rules of Simple Design inspired me to this blogpost.