Changes between Version 2 and Version 3 of HowtoGoodProgrammingTechniques

Timestamp:

Apr 1, 2012, 10:14:33 PM (12 years ago)

Author:

Thanatermesis

Comment:

--

HowtoGoodProgrammingTechniques

@@ -10 +10 @@
 1. '''Cleanup''': Now is time to remove all the useless parts, the goal is to use the simplest solutions and procedures, they are usually the most appropiate ones, try to reduce the code the maximum possible, this step consist in multiple reading of the function thinking on ''how it works'', you will discover on this step a lot of bugs in your code that you won't imagine that exists.
 
+
+
 == States == 
 
@@ -18 +20 @@
 To have states and flags to know how to deal situations is good, but is even better if you don't need to do that! before to deal with any special situation just think if is possible to deal with this element in a better way or totally avoid this need, try to always avoid complex coding.
 
+
+== Integration ==
+
+An application does a lot of steps, the process does something and then save it to the database, but in fact, you only want to save it in the database only and only if the entire process is successful, but how to know that on this actual step ? well, just create a boolean variable with a state or flag saying that it needs to do that in the end, and when the entire process finishes you have a function called ''final_steps'' that runs all the steps that needs to be commited if the entire process has finished succesfully, this is useful for example for remove temporal directories, for commit or send things, for umount or closing shared medias, etc...
 
 
@@ -38 +44 @@
 
 When the application becomes big and start having a lot of names for variables, it is good to know what's exactly that variable, to know if we are dealing with a file, with a directory, or with a value, I personally use for that a suffix (ending in) in the variables like '''_v''' for values, '''_d''' for identifying directories, '''_f''' for identifying a file.
+
+== Extra ==
+
+* Always use local variables, don't share them externally or you can have catastrophic results
+
+* Use vim with a good set of plugins, no way to use a less powerful one
+
+* trap signals, like exit errors etc
+
+* Think on multi-work, if you use a temporal directory called /tmp/myapp, you could have conflict when another user try to use the same application which will point to the same location (so /tmp/user-myapp is a good option). Or also including the ID of the process is also a good method for avoid re-using the same directory if the application can be launched multiple times
+
+