What would be the best programming guideline/tip

Question

What would be the best programming guideline/tip to follow to become a better programmer?

My favorite one is from the book The Pragmatic Programmer: From Journeyman to Master

Don't Live with Broken Windows

Their case is: One broken window, left unrepaired for any substantial length of time, instills in the inhabitants of the building a sense of abandonment. People start littering. Graffiti appears.

This theory inspired police department in New York and other cities to crack down on the small stuff in order to keep out the big stuff. It works: keeping on top of broken windows, graffiti, and other small infractions has reduced the serious crime level.

So, don't leave "broken windows" (bad design, wrong decisions, or poor code) unrepaired. Fix each one as soon as it is discovered. Neglect accelerates the software rot faster than any other factor.

Suggest your programming guidelines/tips.

Answer 1

Do not reinvent the wheel. Code to reuse.

Answer 2

Test your code (and code against tests)

Answer 3

hmm... without going into anything language specific, I can only think about these few generally sound principles about the process of programming:

• always write code with the #1 goal that it can be read easily.
• fix bugs before adding further behaviour to programs.
• premature optimization is the root of all evil (Knuth).

Answer 4

Don't let serendipity be your copilot!

Understand very clearly what every line of code that you write is doing. If you can't explain it, you can't debug it.

Answer 5

Build the simplest solution that could possibly work.

Or KISS: keep it simple stupid.

Answer 6

When you find a bug, take the time to fix it now while you can still find it and remember how to fix it!

Answer 7

Do your best to read about patterns. Try to absorb where patterns should exist, when you can recognize anti-patterns, and what the purpose of patterns are to begin with. It was years before I realized that all I really coded were anti-patterns.

Answer 8

For web development...

Develop in Firefox* first, then test in IE.

* (Firefox, Safari, Opera, Chrome, Pogo, (e.g. any other standards based browser))

Answer 9

When trying to solve a problem with software, first at least consider the "right way" to solve it--given whatever definition of "right" you have. Only after considering this, account for the feasibility and practicality of using that solution, and adjust as necessary to come up with a reasonable solution given the project's constraints.

Although this approach might seem overly naive or idealistic, time and time again I've seen others and myself go with a sub-optimal solution that really isn't much easier or more beneficial than a "better", more principled solution. (And yes, it does end up biting us in the end... although that "end" might be a year or more later.) The main reason seems to be that we get into such a single-minded mode of finding the "simplest fix" or the "least risky fix"--which is necessary for some projects--that we sometimes forget to consider some of the most important tenets of software design.

Answer 10

DRY -- Don't Repeat Yourself. Don't duplicate any piece of information as it runs the risk of becoming out of date. For instance, if you have a "Rectangle" class (or DB table), and you have a "length" and "width" variable, then you don't an "area" variable. Make it a function instead.

On another note, too many programmers focus on what the customer asks for, rather than what they really want. When you get requirements from a customer, try to understand what problems they are trying to solve. Your knowledge of technology combined with their knowledge of the business practices can provide better solutions than either of you could have found on your own.

Try to continually learn new or better methods. New technologies, pitfalls to avoid, best practices, etc. I think that the desire to learn more is one of the things that separates average programmer from good programmers. That desire to always learn more is probably something that all of us who are reading this thread have in common.

Answer 11

Clean, readable code matters. If you can't read it you can't maintain it. Get rid of long, rambling or pointless comments. Write small well named functions that do only one thing. Choose variable names wisely and use whitespace liberally to make your code more readable.

Answer 12

Document your code. I mean by that :

• 'public API documentation'
• internal comments if really needed

The goals is two answer the two age-old questions:

• how do I use this API ? (=> external public API documentation)
• If I revisit this code in 2 weeks, will I still be able to know what it does by just looking at it (=> few well-placed internal comments)

Answer 13

Establish some metrics.

Use the code static analysis tools you are comfortable with, and do not forget that you need to analyze their trends, not just their raw results.

That advice can be duplicated for other populations than just developers: project leaders and stakeholders will benefits from this analysis.

Answer 14

Don't build in support for features you don't need right now.

It can be hard to stop thinking of ways to make something awesome an architect it perfectly for them all to work together seamlessly, but stop daydreaming and do useful work now.

Answer 15

Never code drunk. Remember Windows ME? :-)

On a serious note: build what the customer wants, not what the customer tells you they want. Do this using small, frequent releases to get feedback on real, implemented (or needed, but not implemented) features.

Answer 16

I have always liked the quote that scrolls by in the About screen in Sharp Develop

"The most successful method of programming is to begin a program as simply as possible, test it, and then add to the program until it performs the required job"

PDP 8 Handbook, Pg 9-64

IMHO this is KISS in a nutshell :)

Answer 17

"The secret to write good code is to write it as if the next one that will read your code is a serial killer that knows where you live."

Answer 18

The book Prefactoring has a wonderful collection of maxims.

However, here are a few of my favorites (from a variety of sources):

• Code against interfaces, not implementation.

• Don't Repeat Yourself.

• If you don't know how to test it, you don't know enough to write it.

• Do the simplest thing that could possibly work. (As a friend remarked, that doesn't mean, "Do the stupidest thing that appears to work.")

• Code unto others as you would have them code unto you.

Answer 19

Study best people's code.

Answer 20

Work on open-source projects with really great and experienced developers. See what they do.

Answer 21

I found it very helpful to debug (step by step) into any code I just wrote. Several times I found potentially nasty bugs before it becomes an issue. It's also a good way to get you thinking about writing asserts.

Answer 22

Where it is breaking is why it is breaking. That's my mantra for debugging.

Also, if you are trying to tweak something into the right spot with a range, try doubling your values or halving them, depending on which way you are going (up or down). This works much better than guessing what the "right" value is. Just keep going up or down by doubles or halves and you will arrive at the correct value much faster than any other method I've found.

This applies mostly to game tuning (for me) but I've used it successfully elsewhere.

Answer 23

My favorite maxim this days is probably Don't Repeat Yourself, which is to say, make sure there is a single point of truth for every piece of information in the program. A good example is the layout of a wire format. A good trivial example is the length of a C array in initialized data. Closely related, but much harder to understand and abide by: Every Module Hides a Secret.

Answer 24

It is best to start by writing something small that works. It is almost always easier to start by building a working system according to a good small subset of your requirements, then add functionality later. Do not try to get most of your requirements mostly met; instead, try to get a few of your requirements met and working well and proceed from there.

Answer 25

YAGNI - You Ain't Gonna Need it.

Build what you need right now, not what you think you might need later. You probably won't and if you do, the requirements will be completely different anyhow.