Regardless of operating system, language, team size, project size, etc... there are some things that every programmer should know.

What are your little pieces of knowledge that you have picked up or come to realise that help you when programming.

For a start, I learnt very quickly to take constructive criticism of my code and use it to help better my code in the future. I never take criticism personally now or try to be too protective of my code as I know that it's perfectly possible that there are several better/alternative solutions.

A good idea of what is needed and how it's put together is always great, if you don't have that luxury then a process I call 'iterative prototyping' can be just as good though takes longer - Program everything you can by hacking stuff together, when you have something that works how you want it to, reprogram it with good practises in mind.

If you ever find yourself thinking "this would be much easier in X language" then you probably haven't learnt the language you are using well enough or are using the wrong language for the job.

If you put your mind to it and don't mind it being slow, particular, and rather long winded, you can do almost anything in Bash!

I'm not much of a programmer tbh, but something I've seen time and again on DWTF can be rectified by "check there isn't already a function that does this"

1) always write your test scripts, before you've written a line of code

2) always write the function/method header comments before you start writing the code.

3) make sure that the comments are updated to reflect changes in the design of the system, before you implement the changes

4) for compiled languages, always comment out redundant code, don't just delete it, you never know

5) use a code management system, like SourceSafe, SVN or CVS (see 4 above).

Things the junior at work can't do but every dev should:

Know how to debug code
Know how to respect a tester, for they are the ones that WILL break your code
Know how to view a stack trace
Know how to write out in some form of logging
Know how to make a meaningful error message
Know that it takes someone else to test & validate code/bug fixes to the person that wrote it
Write code comments (the "It's a small business, I can just ask" doesn't work when people leave)
Generate a functional spec, especially for things that are used multiple times (especially when there are consistent failings because they don't get fixed)
Then on failure to make a functional spec to not whine when bugs are found because "The customer didn't ask for it" (I doubt the customer should have to ask to not get null reference exceptions on deleting items)

If you use it more than 3 times and needs a comment to describe how it works, write a method for it

ALWAYS test the positive result in a decision (if...then, while, repeat etc.) rather than the negative result, where possible, as it is faster and more efficient.

E.g.



is more efficient than:

Putting the negative first can make your code more readable in some situations. I know one shouldn't say it, but with todays computers, with small knock on performance is probably worth it for readability later.

I did a test of this at work the other day.

It took about 30% longer for the computer to check if a boolean was negative than it did to check if it was positive.

I couldn't believe it!

I've tried it in Java and Perl and it's not that much in it:
Java:

Time:



Time:
- Yes, I did recompile

Perl:

Time:


Time:

Ah, I only skim read Dave's post.

My test was checking an actual boolean.

In pseudo code it was...

assign a boolean value.
if boolean then print "Here".
else print "Here".

this was compared to...

assign a boolean value.
if not boolean then print "here".
else print "here".

if that makes sense.

I also looped it about 10,000 times so I could get a sensible answer out of it as our system was too quick for anything up to 100 iterations and gave a time of 0.

Processors are designed to test for true, testing for false requires more processing power.

With a modern processor, with a single user, it doesn't make much difference. Add in thousands of tests in a script, multiplied by hundreds of users on the same processor (e-shopping sites, for instance), it can make a big difference.

We had an e-shop with 4 load balanced servers, when it got more than 250 customers, it would grind to a halt - part of it was also poorly optimised SQL queries as well, changing those, and optimising the code meant that it was running fine with 1000 users afterwards. A lot of the SQL optimisation was also changing WHERE statements to check for positives, instead of negatives, plus re-ordering the joins.

Nothing to stop a

if (something)
{
// do nothing
}
else
{
// do stuff
}

Totally.