Some changes to coding style

docs/coding_style.rst

@@ -42,13 +42,26 @@ For extra clarity prefix fields representing true/false states of model with "is
 URLConfs
 ========
 
+Link Names
+----------
+
 Link names should correspond to views and patterns whenever possible. This means that link pointing to "user_warnings" view should be named "user_warnings" and should match "user/rafalp-1/warnings/". This makes associating patterns, links and views easy for those trying to understand your code.
 
-Avoid temptation to prefix links with app names. Good link name should point at correct app without that. If there's name collision, you should rethink your views because there's chance you are either repeating yourself or planned your app structure incorrectly.
+.. note::
+   Notable exception from this rule are "detail" views. While you may name your view displaying threads in forum "forum", this will force you to name variable with forum model displayed something else and propably longer.
+
+   There are many approaches to this "problem" but preffered one is to use more descriptive name instead. Ask yourself what your view shows to the user and use this name instead. This means "threads_list" instead of "forum" or "user_profile" instead of "user".
+
+
+Avoid temptation to prefix links with app names. Good link name should point at revelant app without that. If there's name collision, you should rethink your views because there's chance you are either repeating yourself or planned your app structure incorrectly.
+
+
+Link Parameters
+---------------
 
 Links pointing at classes instead of functions should use lowercase letters and undersores. This means that link pointing at "ForumThreads" should be named "forum_threads".
 
-If link parameters correspond to model fields, name them after those. If your link contains model's pk and slug, name those parameters pk and slug. If link contains parameter that represents foreign key or pk of other model, don't suffix it with "_id" or "_pk". For example link to edit reply in thread can define parameters "pk" and "slug" that are used to fetch thread from database and additional "reply" parameter that will be used to identify reply in thread's reply_set.
+If link parameters represent model fields, name them using model_field scheme. This means that if your link contains UserWarn's id and slug, name those parameters user_warn_id and user_warn_slug in your link and view. In rare cases you may want link parameters point at two instances of same model. If this is the case add use more descriptive prefix instead of one from model name (ergo "quoted_p").
 
 
 Views and Forms