Changes between Version 1 and Version 2 of HowtoGoodProgrammingTechniques

Timestamp:

Apr 1, 2012, 10:05:28 PM (13 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 == 
+
+When you programming, you will see that your code needs to be intelligent, he needs to know ''what to do now'' and how to deal with specific situations, this is a lot more easy to reach with states, in short, '''put boolean states everywhere''' they are cheap!, on that way we can always know how to deal in specific situations, but by other side we don't want to have a flooded code or confused states, so we need to think in a good way to organize them in our code, for example, the prefix '''is_''' is one of the best ones to use, just think about the possibilites to have states marked like ''is_sources_downloaded'', ''is_sources_compiled'', is_sources_ugly''. Your application can also have different ways of work, so you can prefix those states with '''mode_''', see for example ''mode_interactive'' or ''mode_editing'', another useful one is also the '''ignore_''' prefix in order to ignore steps on our application.
+
+== Special Situations ==
+
+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.
+
 
 
@@ -17 +25 @@
 Names in variables and functions are something very important, the convention to use is to be the smallest-size possible with a perfect understanding of its name and what exactly does, think on the structure like in object-programming languages, where the first name needs to be the biggest element and the last the smaller one, and in the end include the action.
 
-Never do names like that:
-* download_resource_now: It doesn't has any sense or description, the action is in the first, now means nothing and resource nothing too
-* stmb_sizer_here_here: The double ''here'' means that your code is so ugly that you don't even believe it, sizer is not easy to understand and if ''stmb'' is not the name of a library or evident element, it is almost impossible to understand what it means
+=== Never do names like that === 
+* '''download_resource_now''': It doesn't has any sense or description, the action is in the first, now means nothing and resource nothing too
+* '''stmb_sizer_here_here''': The double ''here'' means that your code is so ugly that you don't even believe it, sizer is not easy to understand and if ''stmb'' is not the name of a library or evident element, it is almost impossible to understand what it means
 
-Better on that way:
-* cookie_download: we know that we are talking about cookies, and we don't need to include ''now'' because ''download'' is already the action, in case that we will have 2 different kinds of download we should use ''download_foo'' and ''download_bar'', without keeping the possibility of a single ''download'' and having an extendeded one
+=== Better on that way ===
+* '''cookie_download''': we know that we are talking about cookies, and we don't need to include ''now'' because ''download'' is already the action, in case that we will have 2 different kinds of download we should use ''download_foo'' and ''download_bar'', without keeping the possibility of a single ''download'' and having an extendeded one
 
-But even better on that way:
-* myplugin_net_cookie_download: Structuring everything entirely is the best option, all our elements should start by ''myplugin'' which is our entire work about, ''net'' means the section were we are those codes (let's say we have core, net, visual, and sound)
+=== But even better on that way ===
+* '''myplugin_net_cookie_download''': Structuring everything entirely is the best option, all our elements should start by ''myplugin'' which is our entire work about, ''net'' means the section were we are those codes (let's say we have core, net, visual, and sound)
 
 In short, most of the times you will see that the names are writed in the inverse mode that how you talk them, if you doubt, just imagine to have some similar possible names and you sort them, you will see how they are sorted and which part of the name needs to come before the other ones
+
+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.