When we began using RabbitMQ almost three years ago, we initially tried to have "strong" naming conventions which would clearly describe the intended behavior but were unable to prescribe anything logically consistent in all scenarios. As such, the naming evolved "in the wild" as deemed appropriate by the hands-on developer(s) over time. This process led to the looser conventions described below.

Generally, the queues are named:
<something descriptive>_<plural entity name>_q

e.g.
nyse_trades_q

The dead letter queues are always named (where dlx means "dead letter exchange"):
<vhost>_dlx_q

Other configurations might have a dead letter per queue instead of one dead letter per vhost.

The exchanges are trickier. We use a suffix to denote the exchange type:

We strongly prefer and recommend topic exchanges because they’re the most flexible and can behave like either of the other types depending on the bindings.

The topic exchange name attempts to reflect the "class" of the routing keys.

For instance, if we’re publishing "trades", the exchange could be named:
market.symbol.action.tx

And the routing keys on a message could be (e.g.):
nasdaq.aapl.buy

or (e.g.)
nyse.jnpr.sell

The bindings would be:
nasdaq.# ⇒ nasdaq_trades_q

or equivalently
nasdaq.. ⇒ nasdaq_trades_q

and
nyse.# ⇒ nyse_trades_q

If requirements dictate, use the topic to multiplex to additional queues:
#.sell ⇒ all_sells_q

or
#.buy ⇒ all_buys_q

These are the patterns that have emerged over time which have helped us achieve a higher level of logical consistency.