Re: Re: IYHO, what do you consider good code?

[halley]

A couple of my tips on style, regardless of language.

Strategy in comments, tactics in code. Don't explain every statement or operator, but explain the goal of the following few statements or chunk of code. Another suggestion is to write the comments first as you're thinking about what you want to get done, then "translate" the intent into implementation. Don't write clever code which needs explaining-- just accomplish the tactics simply and directly.

There are only three numbers in Computer Science. Zero, One and N. Zero refers to the complete lack of something: no variable, no method, no capability, no support. One refers to a sole solution: one variable, one method, my way or the highway. N represents an arbitrary scalability, an array which can grow, a method reference, a parameterized technique with room to expand. If you find a need for two, structure your code so it can handle three, four or more. That goes for allocations, methods, strategies, resources, resource types, everything.

--
[ e d @ h a l l e y . c c ]

[DrHyde]

There are only three numbers in Computer Science. Zero, One and N

Someone suggested on the london.pm mailing list some time ago that if you ever use a constant other than 0 or 1 you should comment why. I can see his point, although I make exceptions for well-known scaling factors like 7, 24, 60, 3600 and 86400 when mangling times and so on. I also don't bother documenting the constants when I do something like:

$foo = ($foo & 112) >> 4;

although that gets wrapped up in a little subroutine whose function is documented, including a pointer to the relevant standard. But just about every other constant I do inded comment. eg, from my current project ...

$price /= 100; # convert from pence to pounds
...
$time += 23 * 3600 # because we're changing timezone