Minimum Dependencies (excellent investment in the long run)
Naming your files (Are you doing it?)
Don’t add it if you don’t need it
Avoid Dups and Redundancies
Refactoring isn’t all that bad
Unlikely Ally: Immutability
Iterative bursts of HIGH focus (Get your game on and crush it)
Know the basics.
Let's discuss something obvious (but very important) as a starting point. Understanding the foundations of everything you do in life is essential, regardless of what you do. Programming is a particularly challenging area. StackOverflow is a popular source of code that people copy and paste into their editors and then wonder why things do not work. It does not make sense to do this. You will have a difficult time without a fundamental understanding of what you are doing. Get a better understanding of data types, algorithms, and data structures. Learn how to program in a variety of programming languages. Don't jump into something bigger without knowing your tools.
Take the time to think before you write.
As you gain experience as a software engineer, you probably notice that you spend more time considering problems and their solutions than writing code. The reason for this is that coding is the act of thinking. Before writing the code, a key to your situation will make it easier to code. Programming languages are often referred to as tools, in our opinion. In addition to the differences in appearance and functionality, they also differ in terms of their strengths and weaknesses. However, if you possess the ability to think logically and solve problems, you can use any programming language with some proficiency.
Consistency is key.
Writing software requires consistency, which cannot be overstated. Following the same rules across your codebase will make it easier for others to read, understand, and track your code. Moreover, you will find it easier to complete the project alone. Maintain a consistent code by keeping it clean, simple, and easy to understand.
In this regard, we refer to the following:
Naming of files
The naming of variables
The use of single and double quotes
Separation of Concerns.
To minimize side effects and dependencies, you should always advocate for coding with as few side effects as possible. There should be a clear separation of concerns, with certain pieces of code doing one thing and doing it well. You shouldn't access the application state when working on database service, for instance, to access the current user ID. Callers can instead pass this information themselves by adding a parameter. By doing so, consumers can clearly understand the parameters that must be given to a function to execute it. Also, the program doesn't depend on other software parts and behaves similarly, regardless of state.
Magic numbers should never be used.
Strings and magic numbers shouldn't be used. Code is often complicated to read and understand because they are primarily inline variables used for a specific purpose not immediately apparent from the code. Extract a variable whose name indicates what it is for rather than throwing in a "magic number."
Keep it simple instead of reinventing the wheel.
The joy of programming lies in its simplicity. We love solving problems in engineering, so we usually come up with solutions to most situations. However, it is not always logical. Focus on solving your problem rather than leveraging other frameworks, tools, and services. You can find a lot of great software out there, many of which are free. Take advantage of it! You don't have to maintain every line of code you don't write.
Keep dependencies to a minimum.
Consequently, do not use the same provider for all your needs. You should avoid adding an external dependency to a problem that has a straightforward solution. Dozens of npm packages provide one single function. Overusing packages is not a good idea. If you are unfamiliar with third-party services or packages, you shouldn't use them.
Name your files in a way that makes sense.
You are already told in "Be consistent" how important it is to name your entire codebase in simple, self-explanatory terms. Abbreviations should not be overused. Make sure your names aren't arbitrary. It's easy to read good code.
As a result
Keep it simple (YAGNI).
Programming principles like "YAGNI" (You ain't going to need it) are based on the belief that functionality should not be added unless it is indispensable. This is something you should never forget. Rather than implementing new features when you think you will need them in the future, implement them only when they are required. It is unlikely that you will ever do so. You should also avoid building a feature in the most complicated way possible. Whenever abstraction is used wisely, it can be highly beneficial, but if it is not used correctly, it can also cause many problems. You should only add needed code since every new line of code needs to be maintained. Without it, it's just an overhead that adds no value. (Don't contribute to technical debt)
Redundancy/duplication should be avoided.
You should avoid redundancy by following the DRY principle (don't duplicate code, have one source of truth). Data, code, and comments are all subject to this rule.
Code should not be copied or duplicated
Ensure that data is not redundantly stored
Commenting without context is not a good idea.
Instead of adding comments to less readable code, writing clean, valid code is better. Duplicating code is another bad idea. Use separate files/modules/functions whenever you need to reuse code.
In case of necessity, refactor.
Refactoring your code is not a bad thing if it is necessary. It is crucial to keep up with the changes in software and yourself. The best thing to do is to refactor the code instead of carrying it along and gritting your teeth. Make sure you spend some time refactoring your code and improving it instead of adding more features now and then. The long-term benefits are worth it.
Don't make assumptions.
In certain situations, your c.ode should never behave as you expect it to. Although you may think your code can never enter state X, this does not mean it will. Error handling is essential. Unexpected things are to be expected. No matter the outcome, your code critical Users never know what kind of data they will enter - this is especially important for user inputs. Murphy's Law often applies here at Framework Science - everything that can go wrong will go wrong.
Immutability is your friend.
Try to avoid directly manipulating existing variables whenever possible (and reasonable). You might find it cumbersome at first, but working with immutable objects makes your code more predictable and error-free. The direct manipulation of existing variables can have unexpected, hard-to-find side effects, which you should avoid if possible. By protecting yourself from dumb mistakes, you prevent yourself from making them.
Introducing environment variables
If possible, introduce environment variables into your software to avoid hard-coding data—for example, the connection strings for databases, file system paths, and app preferences. Your code should never contain data such as this.
Injecting information from the approach of “everything in one place,” you can modify it quickly, and you won't expose confidential information.
Prepare for iterative focus (Moderated high bursts of concentration).
Concentration and focus are required when programming. Put yourself in t.he zone when you're working on a problem. Notifications should be silenced. Think about possible solutions to the problem. It is easy to jump around, to not be concentrated, and to not accomplish anything if your mind is not free. Keep the flow going, and don't break it.
Suppose you are thinking about working with the latest technologies in an environment where you can earn way more money while incrementing your capacity and value; then we suggest getting in contact with our team to make an invitation to a journey of exploration.