More broadly though, what's the point of "style"? There are purely aesthetic aspects, but in the sense of "bad style"
Computer programmers and professional writers might give very different
The central goal of style is this: reducing the cognitive effort it takes for a reader to understand what you're saying.
Style boils down to mental ergonomics. The brain works in certain ways, and the goal is to convey information with minimal effort by the reader. Good style is deceptive, because the brain absorbs the material without exerting itself; it seems as if the subject matter is very straightforward. But this is only because the author went to the trouble of simplifying it for you. My CS prof at Stanford said it best: coding style is about NOT THINKING.
Without further ado, here is my list. It's incomplete, and many of the principles overlap with each other. But I think it's a respectable start - I'd love to hear additional ones in the comments section!
Make the subject matter relevant
The brain is lazy, and only want to work on something that is is relevant to its needs, or at least relevant to something it's already interested in. Good prose starts by framing the subject in a way that is relevant to the reader, or at least making it relatable to something more familiar. Similarly, good code shows at every level (documentation, commenting, function names, etc) what it is to be used for, and whether there are other uses.
The human brain doesn't do well with abstractions, but sometimes abstractions are what you need to convey. If this happens to you in prose, describe specific, illustrative examples. If it happens in code, show sample inputs and outputs (unit tests are often a good place to do this). The human brain is excellent at noticing patterns; it's often more effective to show examples of a pattern and let the brain take it form there, rather than describing something in the abstract. You should probably state the full pattern in the abstract - if only to make sure there are no mis-communications - but be aware that your reader will "get it" from your examples.
Subtly remind readers of things they should keep in mind
This is a standard rule of prose. If the reader needs to be aware that a character is tall (perhaps it'll be relevant to the plot), you might start off by saying that they stand 6' 5''. Then later on they may "tower over" somebody else, and so on - you don't insult the reader's memory by re-stating what they (should) already know, but you drop hints. Subtle choices of word and phrasing that serves as reminders without breaking the flow of the writing. In code we use naming conventions to remind ourselves whether a variable is an integer or a string, global or local.
Use Things the Way People Expect
The novel things in your writing should be the ideas you're explaining, not the perverse-but-technically-legal way you say them. The fewer things the reader has to untangle the better - reduce cognitive load. In software this is often called the "principle of least astonishment".
A subtle example from prose is the use of nominalizations. Nominalization is when you turn a verb or adjective into a noun, and then refer to the noun. "There was stuffiness in the room", rather than just "the room was stuffy". Unless you have good reason to do otherwise, use a word in its default form.
Separate minor details out from the main narrative
We get distracted easily, and little details can break our train of thought. If the details are starting to detract from the big picture, then separate them out in some way. In prose this could mean having footnotes, or first giving an overview of a subject.
One of the worst pieces of code I've worked with was supposed to do the following: take in a table, group the rows according to some column, then for each group of rows perform some aggregation over each column. For example, maybe the table was describing bank transactions and had rows for a person's name, date and the transaction amount. For a given person, we might calculate the sum of the transactions and the latest of the dates; the type of aggregation depended on the column. In this case there were about 50 columns - it was very complicated.
The correct way to write this code mirrors the English description I just gave. The main loop will group the rows by name, then call a "aggregate_rows_for_one_person" subroutine on each group. But the author of this particular piece of rubbish didn't see it that way. He had the main loop iterate over all rows in the table, keeping running track of partial aggregates for each column. For each line it would check and see whether the name column had changed. If so it printed out the aggregates it had, and if not it updated all 50 of the partial aggregates. Without getting into too much detail the sloppy code was buggy, and I ended up having to re-write the whole thing from scratch.
Explain a subject in the most appropriate terms your audience understands
This needs no explanation for prose. In the case of code I'm reminded of Google's coding style guide. It says that when you're using one of Google's standard language you should expect expert-level readers of your code. This means you can freely use fancy tricks like list comprehensions and singleton classes if that is the best way to conceptualize your computation. But for non-standard languages, which your readers might be unfamiliar with, you should aim for the lowest common denominator, even if that means your code is not as conceptually elegant as it might be. The goal isn't to formulate your ideas in the most elegant way possible, although that may be a means to an end - your goal is to make the audience understand what you're saying. Occasionally those things are at odds.
Avoid extraneous content
Extra crap just distracts from the flow of what you're saying. To quote The Elements of Style, "Vigorous writing is concise. A sentence should contain no unnecessary words, a paragraph no unnecessary sentences, for the same reason that a drawing should have no unnecessary lines and a machine no unnecessary parts. This requires not that the writer make all his sentences short, or that he avoid all detail and treat his subjects only in outline, but that every word tell.".
The one counter-example to this is when it's possible to cram so many ideas into one statement that it becomes unreadable. The rule of thumb in coding is "one line of code per human thought".
Programmers are ruthless about this. They will constantly comb through their code for sequences of steps that get re-used, then combine those steps into a single subroutine. This cuts down on the lines of code and makes it easier to make changes. But it also highlights when two things are really just versions of the same thing; it's defining a special-purpose vocabulary for the subject at hand. The same is true of prose, where common threads in your writing should be identified and called out. If you find yourself explaining the same idea twice, in basically the same way, in a single essay, then your essay is probably *about* that idea.