DEV Community

Cover image for 10 golden rules for becoming a better programmer

10 golden rules for becoming a better programmer

Paul Seal on July 11, 2018

Here are my top 10 rules to follow which will enable you to become a better programmer 1. Don't repeat yourself This is a great princip...
Collapse
 
lobsterpants66 profile image
Chris Shepherd
  1. Check to see if it's been written before. I have seen so much unnecessary code over the years where people had not looked to see if there were ways to do it already coded or built into the framework.

Code left out seldom goes wrong.

Collapse
 
rafalpienkowski profile image
Rafal Pienkowski

I'd like to add:

Read the friendly manual (RTFM rule)

Collapse
 
lyon profile image
Lyon

These rules are great, thank you for writing this. The only rule I would disagree with is 7:

  1. Follow the boy scout rule If you see some buggy or messy code, fix it while you are there and move on. Don't leave it for someone else to do, but don't rewrite the whole program either.

With issue tracking, such as Team Foundation Server, changes to code that are associated with an unrelated task, issue, or bug can be very frustrating and may actually break the build when it comes time to include changesets in a build.

This has been my experience at any rate. Your mileage may vary.

Collapse
 
sergio1990 profile image
Serge Gernyak

Agree with you, Lyon 😊

If I found the messy code during some feature implementation cycle I prefer to just somehow notice such places and do some refactorings after. I do them as separate commits, or, moreover, as a separate pull request. I do not let such refactorings to be inadvertently interconnected with the feature changes. This gives to me a clear context what I've refactored and the ability to even revert the changes as the single thing if it broke something.

Nevertheless, this list of rules is great and useful!

Collapse
 
marmorawski profile image
Marius Morawski

Good rules to code by.
There's just one rule that I feel should be less absolute: String literals. When a string appears only once (e.g. a log message or the name of a config option or so) using literals can actually improve readability without sacrificing anything. At least that's been my experience.

Collapse
 
okolbay profile image
andrew

Give your methods a clear name for what they are going to do

I would put it β€œgive your methods honest names for what they are doing”

even if this name will have β€œand” in it
like validateAndFormat()
this is the best todo hint for others (including future you) to split it.

I’ve seen so many method names like do() process() handle() doAction() and on half of occasions its because developer came up with a method too long and was confused by himself, how to name it. Probably trying to follow a rule that method name should be short, and its not possible to give a short name to something that has 500 LOC, such generic names are born. Really, it would be better to have a 128 chars long name, so that someone else could help )

Collapse
 
thejoezack profile image
Joe Zack

Great list, these are so much more important than what language you're using or whether you space or tab!

Collapse
 
berniemfitz profile image
Bernard FitzGerald

Why would you use spaces?

Collapse
 
thejoezack profile image
Joe Zack

For ultimate precision!... or because the labguage's style guide suggests it.

Thread Thread
 
berniemfitz profile image
Bernard FitzGerald

:) I should have put :sarcastic: at the end of my comment. Totally agree with following language style guides (or team’s rules around formatting)

Collapse
 
minimumviableperson profile image
Nicolas Marcora

So true. Thanks for sharing!