Rules for practical programmers

[eluser]Jonathon Hill[/eluser]
Here's a post from my blog that I thought you guys would find interesting. I had CI in mind for the first rule

What do you think? Do you have any observations you'd like to add from your own experience?

1) Don't waste time re-inventing the wheel unless you can make a significantly better one.

Custom frameworks have their advantages, but are really necessary only if you are developing a particularly unusual project or actually have time to invest in writing framework. There are several great frameworks out there which are mature, tested, and have communities, all time-saving assets which no business-smart programmer should overlook.

Can't find a framework that suits perfectly? Consider forking one.

2) Pretty code syntax should not be more important than re-usable code.

Case in point: static class methods nice and easy to use, but only if you don't ever need to extend them (that is, until PHP 5.3 is production-ready). Make code decisions on the basis of functionality and intended use rather than "prettiness."

3) Learning to use design patterns will save time in the long run, but don’t overdo it.

Remember the law of diminishing returns.

4) Comment religiously, and make your code easy to read, too.

This involves descriptive variable names, following code style conventions, etc. Make comments useful: "# Assign the variable" tells me nothing I can't already see.

I plan to expound more on that last one; it's a biggie. I'm thinking about publishing my own PHP style guide that I've developed.

[eluser]jdfwarrior[/eluser]
Looking forward to it.

[eluser]drewbee[/eluser]
My big one. Comments/commenting should explain the why. I hate seeing comments that explain how/what a particular method/function/ code block is doing. We can see the how/what in the code!!

[eluser]Mark Skilbeck[/eluser]
That 'php style guide' sounds interesting.

[eluser]jdfwarrior[/eluser]
I've gotten to where I do both lately. I used to never comment my code because I was the only one looking at it. But not too long ago I decided to start following good practice and doing it. The only part I hate about commenting is the fact that, it takes up sooo much more time. I know you shouldn't wait until the project is done to comment, you theoretically should do it as you go. This makes it take twice as long to get a system up and going.

Lately, I will begin a function or class with a comment, telling its name, its function (what its used for), a list of parameters that are passed to it, and if it returns a value, describe the return (what it returns, and what it returns per situation if there are multiple options such as true or false).

Then I follow by giving VERY brief descriptions through out the code (usually just a single line here and there. I do this especially on if statements so I can quickly look through code and know what >THIS< else statement is referring to, or WHY i performed this certain task (if its not something that extremely obvious).

[quote author="drewbee" date="1236794973"]My big one. Comments/commenting should explain the why. I hate seeing comments that explain how/what a particular method/function/ code block is doing. We can see the how/what in the code!![/quote]