This is a list of some good programming techniques that I learned myself over the time

Programming Procedure

I normally follow a simple steps procedure when coding, to do in every new function:

1. Write: I have the idea in mind, so I need first to make it working, this is normally ugly code but here, the goal is to make it working
2. Make it good: Then I make better the code, including the methodologies of this coding like correct returning values, making a better structure and a better and readable identation
3. Understanding: Good names in variables and functions is maybe the better correct programming tip that you can have, see the section of convention-names, this is a little slow procedure since thinking in the best names to use requires some brainstorming
4. 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_get, is_sources_compiled, is_interactive... So everytime your application does a specific thing, you can set or unset the affected variables to define the state/progress of the application to know what to do next. 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.

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...

Checks

Your code should be perfect, but in fact, it is not... so don't assume that everything is OK, sometimes by an unkown reason something fails and you could have catastrophic disasters, in order to avoid a buggy application or catastrophic disasters, there's a simple rule: always check everything, simply create short functions for that, for example i have one that is called check_directories with arguments passed by commas which you should understand what it does, another called check_variables and another called check_files, I decided to maintain this name-convention there simply because they are in the group of checkers and to have them by the prefix files_ variables_ directories_ has not much sense.

Human factors

Memory

You don't have a genius memory (specially me), so you can't remember exactly what this code exactly does or why this thing is there, a good way to avoid that is by adding comments but sometimes you forget to do that or they are not sufficient, in most of the cases you think that you don't need this part of the code, or that should be an old not-needed-anymore element or similar things, what I personally do for accelerate the development process and not think on it on that moment is to add on this step a function called named step_requires_fixme message, which basically runs me a prompt/shell if i come to this state of the code asking me what I'm doing here or to verify something

Convention Names

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

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)

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.

Procedure

1. Write the feature and make it to work
2. Minimize the code (less lines, simple and short functions, less-complex algorithms, etc)
3. Structure it correctly (spaces/readability, comments, begin-end parts, local variables, etc)
4. Convention names, take some seconds to decide the optimal names for your variables and calls

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

• the simplest procedure/option is the best, do not think in complex ways to do supa-dupa-intelligent-features if they are not needed

• 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