Being a programmer doesn’t mean to just write code that works, but it must be written cleverly and well so that your team or people that work with it afterward, can understand it easily. To write better code means mainly to understand it and keep it consistent.
Style is important, not to make code look pretty, but because it helps with reading, editing, and understanding. The code should be divided into logical units and it’s important to keep the style consistent throughout the whole document. In most of the programming languages, spaces and indentations do not affect the function. If you are using an IDE, it is recommended that you create a formatted config so everyone uses the same one.
Every developer will be more comfortable with one style or another. If you start working on code that was written by someone else, the style should be followed.
There is no right or wrong, but just the way you feel most comfortable with.
There is a love and hate relationship with comments and there is a fine line between helpful comments and redundant ones.
It is, in fact, very useful to use them to explain the code, especially complicated passages. Comments will help you and others understand why you did what you did. It may seem obvious to you when you are writing it, but will others who work on the code understand it? Will you remember what you did after a month or a year?
Comments are worthwhile as long as they are a few and written for key passages. Too many comments at every single line will make the code completely unreadable and messy, no matter how neat the style and consistent the indentation.
Usually, Languages have their own naming conventions. For example, java uses camelCase. Naming needs to stay consistent, otherwise, it will very difficult to find things inside the document.
There are two main ways to name things:
camelCase: which means that every word of the file name is capitalized except for the first one, e.g. nameFilesConsistently
Underscores: in this case you write underscores between each word, e.g. name_files_consistently
Repeating code will make your document very long and it will break the reading flow. If you have pieces of code that will be used more then ones, it is preferable to make a separate file and include the file path when needed.
A typical example is a web page: most pages will have the same header and footer, but there is no need to copy-paste the same code onto every page, just link to it.
Writing long lines of code makes it very difficult to read, moving back and forth horizontally, losing any sense of what it’s actually written. Style and indentation will help with this.
Keep also in mind, that the terminal window limits characters to 80 per line, so if the code is longer, it will be just cut, making it incomprehensible.
A whole new feature will never be just a few lines long. Even with comments, a 500-lines function will still be a pain to browse, understand and edit.
Your best choice is to break down the big task into a smaller chunk of code.
Having a file with thousands of lines of code doesn’t help anyone, but broken down into shorter files organized based on function or feature will help you get right to the point when something needs fixing. Having the whole code organized in files and folders is very good for maintainability, especially if different teams and people are working on it.
Write clever code, but the main focus should be on readability and maintainability.
If the code is kept short it is easier to go through, but if it’s too smart, it will take too much time to understand and edit it. You know that your code was too clever if you can’t read it after 3 months. So be clever but not too much!
Every developer knows this – you write some code because you want to finish the feature and in the end, it works. When you then look at it after some time you think – did I really write that? I could have shortened it so much! So you start rewriting that piece of code better, probably shorter, without changing any functionality.
You wrote new code, great. Is the new code working? If yes, then just delete the old one!
There is no point in keeping the old code, and comment it out. It will just look messy and unnecessarily long.
A design pattern is a general reusable solution to a commonly occurring problem within a given context in software design.
Writing and reading code may look “easy” if you know what you are doing, but you are probably not the only one working on the code. If you work in a team, it is a good idea to define best practices, guidelines, so that it is easier for the other team members to read, edit, review and maintain the code.
Following best practices will also help you be a better programmer overall. The main keywords to always keep in mind are consistency, simplicity, and readability.