rp's programming rules

Posted on: Friday, Jul 26, 2019

  1. Keep programming comments to a bare minimum. Most comments simply identify code that should have been refactored into methods with meaningful names.

  2. It's OK to have a method that is only called once. Methods don't just add reuse, they add clarity.

  3. Select names (variables, classes, methods, etc) with as much care as you would a heart transplant doctor.

  4. Keep your programming languages current and use their new features (JavaScript ES6 array methods, for example)

  5. If it's not in source control, you're just dabbling.

  6. For every new feature/bug fix, first make a branch. Do not touch working code.

  7. Don't comment out code--remove it. If you argue that you can't do that because you'll lose that code, you aren't using source control!

  8. Don't tolerate dead code. If isn't being used, remove it. See #5.

  9. Inconsistency is consistently a sign of a poor program.

  10. Know what every line of code, and every element in that line, is doing.

  11. Test your app under less-than-favorable conditions. Browser dev tools have network and CPU throttling tools built-in. Use 'em!

  12. If it works and you don't know why, when it breaks you won't know why.

  13. Rarely should a method have more lines in it than you have fingers and toes.

  14. Global variables are a universal programming evil. Don't spread programming evilness.

  15. The cost of decomposition should never be higher than the cost of repetition.

  16. You can never be 100% sure it works with tests and test data. But you can be 100% sure it won't work 100% of the time without tests and test data.

  17. Use indention to give your programs a clear and obvious structure.

  18. Don't write dense code. Let white space, both horizontal and vertical, help tell the story of your code.

  19. A method is doing too much if it needs more than five arguments.

  20. Strive for immutable structures and pure functions. (Which is the 21st century of saying keep coupling low and cohesion high).

  21. If a method's high-level description includes the word "and" that method is doing too much.

  22. Don't ever sacrifice clarity for brevity.

  23. Conditional (ternary) expressions, in any language, are almost always too clever. Avoid them except for the simplest of cases. See 22.

  24. Correctness, clarity, and simplicity are, in that order, the three most important things.

  25. There should never be a numeric digit on hard-coded string in your code! Use constants to give magic numbers/strings meaning.

  26. Don't concatenate long strings--use string interpolation or join array elements (anything but long concatenation!).

  27. Leave old code alone unless it produces incorrect results. When it does, fix that issue as best as you can and then get out. Rewriting bad code just to fix a bug has a greater chance of failing than just putting on your hip waders and fixing the bug.

  28. If you need post-it notes or cheat-sheats to build and deploy, you're doing it wrong! Make your builds and deployments command-line driven. Better yet, make your deployments event-driven with a CI product.

  29. It's not enough for your program to produce correct output, it should also produce a readable, rational log. You can't troubleshoot if you don't know what happened. Build logging into your application.

  30. Build metrics into your log output. When you users say, "It's running slower" you need a reliable way to know if it is really running slower or if your users are just being users. Record performance benchmarks when you deploy the app so you can refer to them later.

  31. It's usually good enough to know there is a way rather than knowing the way. "Programming isn't about what you know; it's about what you can figure out." — Chris Pine

  32. Beware external service dependencies. Cloud services break but your service shouldn't break. Design your critical systems with built-in failovers to keep your service up.

  33. Don't assume someone else's programming rules will work for you. Read and listen to what a lot of programmers and take the best from each that works for you.

  34. Carefully consider the general challenge before you focus on the specific challenge. Solve the general parts of the challenge with components to reuse on the next challenge.

  35. The absence of buggy behavior doesn't prove the absence of bugs.

  36. It is astounding how quickly new code acquires "legacy" status. Document all workflows, assumptions, and goofy stuff (you know the stuff I mean!) so you don't have to start from ground zero every stinkin' time you need to make a change or a fix.




Add your comment
You email is never shared with anyone else.

© Copyright 2017 by Roger Pence. All rights reserved.