Recent changes to Writing Rules

Writing Rules modified by Nicolas Hainaux

Nicolas Hainaux — Fri, 31 Jan 2014 21:59:04 -0000

--- v6
+++ v7
@@ -19,4 +19,4 @@

 * The names of the variables should be long enough to be clear and understandable. Doesn't matter if they take space, the code must be as easy to read as possible

-* All fields of any class are named with a single leading underscore, like in _field ; they should never be accessed directly. Instead, there is an associated property having the same name without the leading underscore, this gives a 'read-only' access to the field content and will prevent from assigning a field. A setter must be used explicitely (no setterr associated to the property).
+* All fields of any class are named with a single leading underscore, like in _field ; they should never be accessed directly. Instead, there is an associated property having the same name without the leading underscore, this gives a 'read-only' access to the field content and will prevent from assigning a field. A setter must be used explicitely (no setter associated to the property).

Writing Rules modified by Nicolas Hainaux

Nicolas Hainaux — Thu, 30 Jan 2014 19:58:06 -0000

--- v5
+++ v6
@@ -7,10 +7,16 @@

 * All the code should be written in python to avoid complexity and dependencies. There may be exceptions for some parts (like the gui)

+* All the code is written in english
+
 * The code have to be modular and object-oriented to give the maximal flexibility to reuse each component

 * Everything has to be documented. First, all classes, functions etc. have to be commented for Doxygen, as soon as they are created. And sometimes some complicated algorithms need long explanations : no problem, write as long as necessary.

 * The [PEP 8 Style Guide for Python](http://www.python.org/dev/peps/pep-0008/) should be a reference

+Some personnal choices :

+* The names of the variables should be long enough to be clear and understandable. Doesn't matter if they take space, the code must be as easy to read as possible
+
+* All fields of any class are named with a single leading underscore, like in _field ; they should never be accessed directly. Instead, there is an associated property having the same name without the leading underscore, this gives a 'read-only' access to the field content and will prevent from assigning a field. A setter must be used explicitely (no setterr associated to the property).

Writing Rules modified by Nicolas Hainaux

Nicolas Hainaux — Thu, 30 Jan 2014 19:49:51 -0000

--- v4
+++ v5
@@ -1,13 +1,16 @@
 /!\ this is a first draft
 [Back](Home)

-We'll try to write "clean" code. It was not the case at the beginning, but things change.
+We'll try to write "clean" code. It was not the case at the beginning, but things change. Any help to enhance the code, to make it cleaner and easier to read, is welcome.

-So here are some hints :
+We try to follow these rules :

-* all the code should be written in python, except for certain parts like the gui
+* All the code should be written in python to avoid complexity and dependencies. There may be exceptions for some parts (like the gui)

-* this will be modular and object-oriented code to give the maximal flexibility to reuse each component
+* The code have to be modular and object-oriented to give the maximal flexibility to reuse each component

-* everything has to be documented. Sometimes the explanations of complicated algorithms need enough space inside the code, no problem, write as long as required. On another hand, all classes, functions etc. have to be commented for Doxygen, as soon as they are created
+* Everything has to be documented. First, all classes, functions etc. have to be commented for Doxygen, as soon as they are created. And sometimes some complicated algorithms need long explanations : no problem, write as long as necessary.

+* The [PEP 8 Style Guide for Python](http://www.python.org/dev/peps/pep-0008/) should be a reference
+
+

Writing Rules modified by Nicolas Hainaux

Nicolas Hainaux — Thu, 30 Jan 2014 19:43:46 -0000

--- v3
+++ v4
@@ -1,12 +1,13 @@
 /!\ this is a first draft
 [Back](Home)

-As the author is not a perfect programmer, you can tell him and discuss about wrong choices he made writing this code.
+We'll try to write "clean" code. It was not the case at the beginning, but things change.

-Nevertheless he tried to do his best and thinks some common conventions should be respected in order to improve Mathmaker. Here we go !
+So here are some hints :

-To keep the installation simple enough, all components should be written in the same language (i.e. python), although this may be discussed (the gui could be written using another language if there's a good reason to do that).
+* all the code should be written in python, except for certain parts like the gui

-It is necessary to write object-oriented code as well as the programm already is.
+* this will be modular and object-oriented code to give the maximal flexibility to reuse each component

-The source code has to be commented well enough, please use the comments writing rules that have been used so far. The doc is realized thanks to Doxygen, you can use any feature of this software.
+* everything has to be documented. Sometimes the explanations of complicated algorithms need enough space inside the code, no problem, write as long as required. On another hand, all classes, functions etc. have to be commented for Doxygen, as soon as they are created
+

Writing Rules modified by Nicolas Hainaux

Nicolas Hainaux — Wed, 29 Jan 2014 06:17:59 -0000

--- v2
+++ v3
@@ -1,3 +1,4 @@
+/!\ this is a first draft
 [Back](Home)

 As the author is not a perfect programmer, you can tell him and discuss about wrong choices he made writing this code.

Writing Rules modified by Nicolas Hainaux

Nicolas Hainaux — Wed, 29 Jan 2014 06:14:57 -0000

--- v1
+++ v2
@@ -1,3 +1,5 @@
+[Back](Home)
+
 As the author is not a perfect programmer, you can tell him and discuss about wrong choices he made writing this code.

 Nevertheless he tried to do his best and thinks some common conventions should be respected in order to improve Mathmaker. Here we go !

Writing Rules modified by Nicolas Hainaux

Nicolas Hainaux — Wed, 29 Jan 2014 05:57:52 -0000

As the author is not a perfect programmer, you can tell him and discuss about wrong choices he made writing this code.

Nevertheless he tried to do his best and thinks some common conventions should be respected in order to improve Mathmaker. Here we go !

To keep the installation simple enough, all components should be written in the same language (i.e. python), although this may be discussed (the gui could be written using another language if there's a good reason to do that).

It is necessary to write object-oriented code as well as the programm already is.

The source code has to be commented well enough, please use the comments writing rules that have been used so far. The doc is realized thanks to Doxygen, you can use any feature of this software.