As you probably know, naming things is hard, but it isn't impossible and as long as the name of the class, method, object or variable etc makes sense and helps the reader to understand what is going on, then you are doing it right.
Please don't be the person who does this:
var button1 = new Button(); var textBox3 = new TextBox();
Whilst the code itself may not be realistic, the point here is the lazy naming. It is not helpful to name somthing button1 or textBox3, give it a meaningful name.
I personally think you shouldn't be writing comments in your code. I think you should write the code in a way which explains what it is doing itself without the need for comments. With that in mind, this commandment refers to those comments like this:
//get the user from the database var user = GetUserFromDatabase(); //send an email to the user var success = SendEmailToUser(user);
Those comments are just pointless. It is obvious what the code is doing there. If you really must write comments, use them to explain why you are doing something instead of saying what you are doing.
We all love open source software, and some of us even like to contribute to them or create our own repositories. We are good people, but don't be fooled, not everyone has good intentions, and some nasty people create bots to carry out their evil work.
You should never commit any keys or secrets to an open source repository because there are people who go through the commit history of public repositories looking for such things and using them for no good.
Use things like 'AppSettingsSecrets.config' locally that doesn't get checked into source control. You can use environment variables and key vaults too.
This might sound like a contradiction, but think about what it is saying. It says you can be forgiven for duplicating some code once in the same project, but if you need to duplicate it again for another part of the project then maybe you need to refactor the code so it can exist once and be called from all of the different places which need it.
This one is unforgivable. No one should be storing passwords as plain text in a database, or using weak hashing algorithms such as MD5.
If your data is breached, which is happening more and more it seems these days, you want to make it as difficult as possible for hackers. Ok so they managed to get hold of your data, but if you'd done things right, they wouldn't be able to access password and other personal data because you a very strong encryption method like AES 256 with a different salt and vector per record.
You need to be careful when using someone else's code. If you copy and paste it into your program, you need to be sure that you aren't violating any licences. You might think that you can just rename the namespace, classes and method names, but if the code still looks like the original, you can still be sued. There is a famous court case where Oracle who owns Java sued Google for copying its APIs.
There are so many different licences out there to understand, just because something is free, it doesn't mean you can do what you want with it. The GPL licence attempts to force people to release their source code which might be a problem if you are working on proprietary software.
This article will help you understand more about software licences.
What about dates, do you really need to load in momentjs if you just want to format a date and time.
Surely the best thing to do, is find out the few lines of code you need in your project to achieve these things and eliminate these dependencies, unless you are using them heavily.
Tightly coupled code is code that can't be tested easily. It is code which depends on other code to be able to run. It reduces flexibility and re-usability of code.
Test Driven Development is a way of writing your tests first, then writing your code. You only write enough code to pass the tests. You write enough tests to make sure the code fulfills the requirements. If you are writing tightly coupled code it makes it harder to test. Following a TDD approach gets you thinking about how to write your code in such a way that it is not tightly coupled to any other code. You should use interfaces for your services and dependency injection to inject these services in to where you need to use them.
Let's face it, we have all probably written a try catch statement where the catch just swallows the error so the application doesn't throw an error. This is bad, really bad.
You should at least be logging the error before swallowing it.
In an ideal world you will catch the error, log it, react to it with your code and throw it up to the next level where you can handle it appropriately there too.
Please don't use hard coded values in your code. Come on, how annoying is that. If the value needs to change, what are you going to do, find and replace all occurances of "2"?
It is much better to use constants, variables or enums instead, where they have a meaningful name of what that value represents and you only have to update it in one place?
If you disagree or want to add any commandments, please either comment where you saw this post or tweet it with your comments and get the debate going.