DEV Community

Cover image for 10 commandments of programming
Darlan Alves
Darlan Alves

Posted on

10 commandments of programming

These are 10 rules that I follow and will help you with being a better professional and effective developer.

1. If it’s hard, it’s wrong.

If a problem seems too hard to tackle, either you don’t know exactly what you are doing or you are doing it wrong.

Break down your problem into smaller pieces and try to decouple everything. Write pseudocode or create a PoC. Use pen an paper and talk about your solution with a colleague. These are great ways to check if you’re going in the right direction.

2. Don’t reinvent the wheel.

We love coding. Of course we do. But writing your own solution to everything just because we want it to be exactly like “this” or “that” is a waste of time and money.

But you should reinvent things from time to time, just for fun.

You will understand how things work to the tiniest detail. And you can only innovate or improve on things that you know very well.

3. Never stop learning.

Programming is hard. Thinking about all possible ways that something can go wrong is exhausting. Dealing with edge cases and crazy users is an insanity. But you will have to spend some time out of that madness to keep learning new things.

Try a new framework, write pet projects, fill your Github account will endless crap that no one will ever see.

That’s gonna be great for your one day, when you face a problem and “Aha, hold on!”, you know how to fix it because you tried that before.

4. Always be clear about what you are doing.

Don’t start coding until you know exactly what needs to be done.

There’s nothing worse than someone writing code at random and just hoping it will work at some point.

That only adds up to a pile of unmaintainable mess.

5. Don’t repeat yourself.

Reuse everything you can and keep things coherent. But don’t go too crazy either.

The whole point here is… if you need to change something, you should have to change it only in one place. Otherwise, you will make mistakes.

6. Write tests for everything.

Not a single line of code should go to production without some form of testing. And don’t trust your coverage either!

Code Coverage is a lie you tell yourself. It's just code porn.

Make sure you write a test, then write a line of code to pass that test.

Only this way you will know for sure that every single thing in your system is tested.

7. Don’t comment, unless you really, really need it.

Unless something incredibly hard to understand is part of your job, no comments should be tolerated.

Long if condition? Write the condition to a local constant that explains what’s that.
Weird algorithm? Write a function with a name that explains what it does.

Comments rot, and rot very fast.

8. The best code is no code at all.

Code is hard to maintain, so whenever possible, don’t write it.

Think how you can make it both more elegant and less verbose, and over time, it will shrink and work better.

9. Always leave the code you changed cleaner than you found it.

Follow the Boy's Scout rule of programming.

10. Stick to the rules!

Discipline will pay off in quality and clarity over time.

Things should be black and white. If you establish a rule, follow it to the letter.

Why? Because you don’t have to think about it!

Your precious brain juice is better spent on things that you DO have to think about.


Which rules do you follow?

Create a post or share in the comments which rules you follow every day!


Also recommended: Watch this series of Clean Code talks from Uncle Bob:

https://www.youtube.com/watch?v=7EmboKQH8lM
https://www.youtube.com/watch?v=2a_ytyt9sf8
https://www.youtube.com/watch?v=Qjywrq2gM8o
https://www.youtube.com/watch?v=58jGpV2Cg50
https://www.youtube.com/watch?v=sn0aFEMVTpA

Top comments (8)

Collapse
 
thebuzzsaw profile image
Kelly Brown • Edited

Sorry to be That Guy™, but I'm going to add a caveat to commandment number two.

Yes, don't reinvent the wheel, but learn to recognize exactly which wheel you need! There are plenty of good reasons (beyond "education") to build a new wheel. The widely available solutions are general purpose and often try to solve too many people's problems, and it's unfortunate that we shame developers for daring to build their own variant on a popular data structure. Developers are closer to the real problem than those who created the general purpose solution.

Also, it's kind of funny that we use "wheel" for this analogy. Do people understand just how many wheels are invented every single day? We have wheels for every kind of encounter. We have wheels optimized for smooth roads. We have wheels specialized for rough or snowy roads. We have wheels that are bulletproof. We have wheels that work underwater. We have wheels that work on Mars. We are "reinventing" the wheel all the time.

In general, keep a healthy balance. Do not underestimate the power of existing well-tested well-reviewed solutions, but do not shy away from building a custom solution that solves your problem perfectly. Sure, you cannot reuse your solution in other situations, but that was never the point!

Collapse
 
darlanalves profile image
Darlan Alves

Yes, don't reinvent the wheel, but learn to recognize exactly which wheel you need!

This sums up perfectly my intent with that rule!

It's also nicely illustrated by this image about wheels.

Indeed, people reinvent wheels every single day for specific purposes. Eventually, reinventing the wheel leads to entire new things.

AngularJS was an experiment for a side project. Gmail was some guy's pet project too. Those are great innovations out of someone reinventing their wheels.

Collapse
 
ironcladdev profile image
Conner Ow

1. If thou art encountering hardship in coding, ye are doing it incorrectly

2. Thou shalt not reinvent the wheel

3. Thou shall not stop learning

4. Thou shalt be clear on what ye are doing

5. Thou shall not repeat yourself

6. Thou shall write test for everything

7. Thou shall not comment unless necessary

8. Thou shalt not code when necessary

9. Thou shall leave the code you changed cleaner than you found it

10. Thou shalt stick to the rules

Nice job. Very useful info 😄😁😜

Collapse
 
darlanalves profile image
Darlan Alves

OMG I love you for this! 😄

Collapse
 
ironcladdev profile image
Conner Ow

You can change the su-headers in the article to these if you want LOL

Collapse
 
nixon profile image
Jerry Nixon
  1. If it’s hard, it’s wrong.

It's worth remembering that cryptography is very hard. Appropriately adding security to your application is also very hard. Comprehensively instrumenting your code so it can be monitored, and errors can be traced is very hard. Segmenting your code and decoupling it so upgrades over time are less intrusive is very hard. Making sure your app is both globally non-offensive, user friendly, while still accessible to our friends with disabilities is very hard. Ensuring your documentation is comprehensive and updated when your code changes is very hard. Isolating your code in such a way that hackers and junior devs don't access capabilities they should not is very hard. Protecting personal information while still deriving valuable insights is very hard. Implementing excellent error messages across method calls is very hard. Coming up with the 10 commandments of software while staving off wandering comments is very hard. ;-)

Collapse
 
shwetabh1 profile image
Shwetabh Shekhar

Love this. Thanks for sharing!

Collapse
 
kalashin1 profile image
Kinanee Samson

Don't comment unless you absolutely have to. Most of my codes are filled up with comments.
And I think I'll try more of writing tests before I write code