First solution: write code cleanly. After a while, it will be natural. Use the Tab key.
Second solution: use Edit > Auto Format, it should improve the code. I use it sometime on other people's code...

Thanks. Is there any particular reason i should try to write cleanly when I can just use auto-format or is it just for the sake of a good habit?

Auto-discipline is good...
I might be naive, or old school, but I believe that the way you write code reflects your thoughts: if you have clear thoughts, your code should be clear. Disorganized and confusing code reflects a confused mind...
Now, don't take this too seriously and too "religiously", there are exceptions (code written cleanly but no clear idea of where to go, or a brilliant coder never indenting), but I still believe this. Care on the way you write code shows the care you put in your craft.

Fair enough. But it's an art, not a craft  Or at least processing is.

Even more a reason to make your artwork nice the way you design it, not the way a tool makes it!
(Even if the art is more in the algorithm / design than in the code writing.)

Another important aspect is good documentation of the code. It is tedious and it may consume up to one third of one's work time - why it is often neglected - but it is important if one returns to continue on a code after a longer break, or if one plans to give the code into the hands of others.

Yes, literal variable and method names help.

That's a great quote there D. I always find it hard to name values, especially when they represent relatively abstract concepts, like whether a state is true or not. What I mean is, it's easy for me to name values that relate directly to what the code is doing, but not so much those that relate to the code itself, if that makes anysense.

I understand, as I remember having difficulties to find names myself when I was beginning programming. Well, it was about naming jump labels in assembly code, which is even harder! I finished by using names of famous SF authors... Which is the wrong way of doing things!

A trick is to try and verbalize what the variable does. Like "this variable is used to remember that the user clicked on the shape". I would name such variable, say, bHasClicked or if you need more details (other similar variables), bHasClickedOnShape. I use the b prefix for boolean variables because these are the only variables I allow to be used as booleans. An habit from C, also useful in weakly typed languages like JavaScript or PHP, where a number or even a string can be used as boolean! Not so necessary in Java, but still useful. My only concession to Hungarian notation...

I'd also be interested to hear, how rigidly people stick to the idea that "functions should do one thing, they should do it well, and they should do it only" - I'm finding I end up with code that is far, far easier to read, but that writing the actual code takes much, much longer. Less of a "sketch" and more of an "application" - There seems to be a lot in the way of best practices and programming mantras that perhaps aren't so relevant to Processing...?

D.

Best practice in programming is to avoid global variables.
But we use them a lot in Processing, partly because they are hard to avoid, as it made Java into an imperative programming language, partly because they are actually just member variables of the (hidden) main class, so that's not so bad...

So, yes, programming quick and "dirty" sketches doesn't need the same rigor as making a large application. Except if your sketch is using dozens of classes and so on...

Yes, I can only confirm what phi.lho is saying about global variables (one code of mine uses over 300 lines for those ((6% of the total code). Believe me, I think twice about whether a variable must be global or can be local). I would love to be able to group those declarations into methods that I could call before setup(), e.g.  declare_path_variables(), declare_view_variables() etc., just to keep this initial part shorter and cleaner. Now I'm always searching where the declaration of a variable is located, although I grouped them logically.

I believe that the way you write code reflects your thoughts: if you have clear thoughts, your code should be clear. Disorganized and confusing code reflects a confused mind..

that is so true..at least for me..

i am really new to programming, i have watched some on line courses (especially the MIT channel in youtube) and have used a couple of books. Some rules that i have read really helped me a lot. For example, if you cannot find a name for your function, then your function does way too many things.
i think that processing is good because it gives quick results, i mean it way too impressive to see a ball moving in your sketch but it is not going to teach you good coding. Only after i read and understood java, was  able to understand processing code examples with multiple classes etc..

clean code is also art (i guess i am oldscholl too   )

Less of a "sketch" and more of an "application"

I don't really understand why there is such a bias towards the idea that processing should be considered useful only for small "sketches" when in I've seen it used for some very complex and impressive visual applications.  

- There seems to be a lot in the way of best practices and programming mantras that perhaps aren't so relevant to Processing...?

I think the practices everyone has been describing here are useful to anyone, just as much beginners or people who only intend to dip into programming as for professionals and enthusiasts.

I don't really understand why there is such a bias towards the idea that processing should be considered useful only for small "sketches" when in I've seen it used for some very complex and impressive visual applications.   

There are many different programming languages and Java is just one of them. Java is an object orientated (OO) laguage and OO is a great way to create large scale applications, in fact the Processing IDE, the core/contributed libraries and tools are all witten in Java and use object orientation.

The beauty of Processing is that it allows the programmer to create code without having to learn the complexities of OO

some of the core concepts of OOP (particularly encapsulation) appear to be less ruthlessly observed by Processing users. 

This is not surprising since many of the users are unfamiliar with OO and are experimenting with it.