Browse Source

More on coding style. #270

Rafał Pitoń 11 years ago
parent
commit
806bed96c9
1 changed files with 11 additions and 0 deletions
  1. 11 0
      docs/coding_style.rst

+ 11 - 0
docs/coding_style.rst

@@ -42,7 +42,18 @@ For extra clarity prefix fields representing true/false states of model with "is
 Writing Views
 Writing Views
 =============
 =============
 
 
+- view arguments
+- maybe arguments order
+- templates
 
 
 
 
 URLConfs
 URLConfs
 ========
 ========
+
+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.
+
+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 will correspond to model fields, name them after those. If your link will contain 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.