Clean code & why it's important
I'm a C++ coder, studying the subject through Games Programming. Many hundreds of people work on a single video game or even in the software world hundreds might make a new edition of a software suite. If we can be expected to write code as a group then the expectation must be on the individual to write clear, understandable and maintainable code. Without any C++ knowledge (but an idea of C based programming is preferred) allow me to convince you of the importance of code which may take longer, take more thought and effort but is better for your overall product.
So here is some code you might see in a game. This revolves around the player's movement. The first line gets the call for the keyboard, the second tests if the W key is being pressed. If it is, it'll start the process. The first bit being movement, testing collisions, then finally an animation if there is a movement. This code might look alright until you consider, this method is called "movement" and yet it actually handles button presses and animation. Additionally this is just upwards movement (forget delta for now games programmers) imagine this being duplicated for all the direction and imagine this happening for multiple button presses for diagonal movement. Let's clean up this code with some rules.
1. Naming Standards
Now there already is a little naming standard in the screenshot as I'm using code I programmed a little while ago, engine is called p_engine because it's a protected variable to engine. Naming standards can apply to anything though, methods, variables and classes.
Most people employ some skew on Hungarian notation and the one I'm going to employ here is my own skew on this naming scheme. I use the first letter to denote where the variable is stored, this is because in C++ some data will remain after a method or class is deleted if one is not careful. I use m_ (member variable), l_ (local variable), f_ (sent via the method parameters) and p_ (set as protected or public in the class). It doesn't matter what naming scheme you have provided you stick to it. Additionally I'll make the first letter or couple of letters the data type which just makes me think twice before changing the type.
2. Methods perform one task
This movement method is doing four things, it's figuring out which button is pressed, attempting to move the player, testing collisions to stop the player moving and animating the player. Realistically speaking this method should only be concerned with moving the player. So instead let's add more methods and calls, and separate out the operations so that the only task this method is performing is movement of the player, calling something else to test and calling an animation.
You'll sometimes hear this as separation of concerns which is an adjacent principle. The basic idea is to keep methods short and sweet you should reduce the amount of tasks any one method (or class) is performing or concerned with. See this link for more of an explanation.
The above is a simple example of refactoring some code. The above code is neater, clearer, more broken up and does more than the original code. The original code only worked on one direction however if you break apart a function you can use the excess space to add functionality to make your code more useful. This code is close to being clean, there's one final step I'd like to add.
3. Comment as if you're not the client
Even if you're the only person who's ever going to look at a peice of code, that doesn't mean you'll remember how it works months after the fact when returning to reuse or fix bugs. Instead comment as if the person looking at your code is figuring this stuff out as they go. Comments should describe things that are not obvious, comment things which you wouldn't know if you've not coded using your system and do not put change logs or edit logs in comments - that's what source control is for.
Additionally if your programming language allow you to customise tool-tips on methods and variables - use it. This is displayed above in C++ however other languages sometimes have this option so search your language so you can learn how you can help your IDE!
This is a very surface level look at clean code but I hope this has convinced any new programmer to continually refactor, continually clean up and continually leave code clear, concise and clean!
Additional reading: