Let me try with a few simple ("obvious"?) style guidelines I try to follow:

• Use meaningful names that are spelled out or that use widely-adopted abbreviations from the field of application.
• Begin names with lower-case letters (except when they're going into a Package for others' use) and then use camelCasing.
• Avoid nesting functions too deeply with use of brackets; instead, try to use the built-in special input forms, e.g., /@ for Map, @@ for Apply, prefix form with @, and (when it's semantically appropriate) postfix form with //.
• Intermix text cells containing documentation with input cells containing code.
• Define ::usage strings for functions to be used by others, or for functions whose syntax you may readily forget.

Everyone will have their own preferences about coding style. This is especially true for Mathematica, as most work done in this language is interactive, and until recently there was relatively little open collaboration between people that could have led to the development of standards. The existence of this site (Mathematica.SE) helped make a big progress in this area.

Let's try to collect a few guidelines which are already commonly followed in the online Mathematica community.

Naming things

• The only characters allowed in symbol names are alphanumeric characters and $. This naturally leads to using Camel Case for names.

• When developing packages meant to be used by others, use fully spelt out, descriptive names for public symbols.

• When doing interactive work, use only names starting with lowercase, e.g. findAllRoots.

• When writing packages, use only capitalized names for public symbols, e.g. FindAllRoots. However, for symbols private to the package use lowercase.

• Start the names of constants or flags with a $ sign. This is typically used for global variables that control in some way how the system works, e.g. $MaxExtraPrecision.

When there's more than one way to write something

• Instead of f[g[h[x]]], write f@g@h[x] for readability. Instead of f[{a,b,c}], write f@{a,b,c}.

• If you have a purely stylistic choice between = and :=: use = for variable definitions and := for function definitions.

• When evaluation has side effects, prefer DownValues to OwnValues. I.e., use randomNumber[] := RandomReal[] instead of randomNumber := RandomReal[].

• For procedural loops, prefer Do over For

In the excellent responses above, I find that one of my favourite guidelines is missing. It concerns the case when one has to apply one function after another.

Instead of writing

f[g[h[k[q[x]]]]]

write either

x // (q /* k /* h /* g /* f)

or

RightComposition[q, k, h, g, f][x]

I prefer this method because it is reminiscent of the pipeline operator in F#. And triple-clicking has never been a good friend of mine.

I found Roman Maeder' package template useful, as a general setup guide. (More comprehensive than any setup I actually use.) From Programming in Mathematica 3rd Ed. (1996), page 290.

Not a general Answer, but I haven't seen such a thing in any language else. What I have found using a 1080p Monitor with the Mathematica Benchmark is: Formatting every function by indending every argument and place the commata on the first level, e.g.

If[ Head@list[[1]] == Symbol,
    foo[]
,
    If[ Head@list[[1,2]] == Symbol,
        bar[]
    ,
        foobar[]
    ]
]

improves the readability heavenly. The codebase I am currently working on is heavily oversmarted, i.e. way too long single lines. Especially since there is no clearly visible "else" I find it very important to at least give the second comma from "if" its own line.

Separate Styles and Options from Functional Code

Almost nothing was said about Styles and Options so I think I will do that now.

Basis

In all modern languages it is a best practice to separate presentation and behavior of interface elements from content. In web development presentation is controlled with cascading stylesheets (CSS) and behavior with JavaScript (JS) which were early on expressed inline or embedded throughout web pages (HTML) making them appear extremely cluttered and clumsy to work with. This is analogous to how Mathematica currently embeds styles and options throughout functional code. As web pages became more dynamic and grew much larger it became essential to separate presentation and behavior from content by intelligently placing CSS and JS in separate files and linking them to HTML files with a few simple commands at the top. We can't do that in Mathematica (we can but we shouldn't) however we can do the next best thing -- place all styles and options in cells apart from the rest of the code by defining hooks and handlers linking them. This accomplishes three main things...

• It makes the dependent code more readable and styles and options easier to find when debugging or adjustments are needed.
• It helps in keeping style directives and options consistent.
• It practices DRY resulting in writing less code and lighter files.

This is probably not a great strategy for smaller projects which are about a full page or less as using hooks and handlers may cause some bloat. However it is still great practice for becoming proficient at this and for setting up smaller projects that are over time expected to grow or refactored.

Implementing a Strategy

1. Don't Be Clever

Before I suggest a solution I wish to stress just because you can do something it doesn't mean that you should. Do not change the default set options of native functions especially when other developers with various backgrounds or levels of experiences may need to access your code. Too much can go wrong by just forgetting you did that. There is a better way as shall be discussed shortly. Options can also be borrowed between functions but such code usually appears entangled (violates KISS) making it very difficult to read or debug. So I don't recommend this either even though it practices DRY.

2. Separate Presentation and Behavior from Content

The following uses Grid as an example.

My solution is to specify all options using variables then they can be inserted inside a function in place of the actual options.

gridops = Sequence[op1->spec1, op2->spec2, ...]
Grid[{row1, row2,...},gridops]

Sometimes you will have many output structures that have common option specs but with minor differences. You can do one of two things. Trail unique option specs (op3 and op4) after placement of the options variable. This should be the only exception to the rule of separating presentation from content.

gridops = Sequence[op1->spec1, op2->spec2, ...]
Grid[{row1, row2,...},gridops,op3->spec3,op4->spec4]

Or you can create a function to handle unique option specs as parameters. Just one caveat. You may need to wrap the options function in an Evaluate when placed in your dependent function as is necessary with Grid and others like Plot.

gridOps[spec1_,spec2_]:=Sequence[op1->spec1, op2->spec2,...common ops here]
Grid[{row1, row2,...},Evaluate[gridOps[spec1,spec2]]]

Similarly can be done wherever Style is used. For my grid headers I might wrap text in the top row of cells with Style and place common style specs in a variable. If you have unique styles you can create a function to handle them or trail them as was done with Options.

headerstyle = Sequence[12,"Helvetica", Bold]
Style["string",headerstyle,...trailing unique styles]

3. Collect All Option and Style Handlers in One Place

Group all Styles directives and Option specs handlers into a single cell at the top of file placed so that they load before dependencies. This is analogous to how CSS and JavaScript are loaded in web pages. If there are an overabundance of handlers use several cells keeping related styles and option definitions together. Of course there is no need to reminder user that it might be a good idea to set those cells as Initialization Cells.

4. Go Further With Theming

Most projects demand setting only a few options or style directives that are consistently sprinkled in a lot of places. Instead of repeating the same specs define those specs in alias variables (a new feature in CSS does this) and insert aliases everywhere they occur including the aforementioned styles and options handlers made in points 2 and 3. These would then be collected in a cell higher up from any dependent code. Doing this would enable making quick and consistent changes to behavior or theme from just one place in your file. Your hierarchy might look like below. As before it might be a good idea to set cells to Initialization Cell.

(* TOP CELL *)
(* theme aliases goes here *)
bgcolor=Darker[Blue];
fontcolor=White;
fontfam="Helvetica";
fontsize=12;
font=Italic;
spaces={4,4};
align=Center;
frame=All;
output=Traditional;
method=Automatic;

(* NEXT CELL *)
(* handlers from points 2 and 3 *)
(* may be injected with aliases from point 4 *)

(* ALL OTHER CELLS *)
(* all other code *)
(* injected with hooks and aliases *)
(* from points 2 - 4 *)

Your Opinion Matters

What are your thoughts on this? Do you already do something similar? What are your best practices?