News for hackers. Stuff that matters.
Re:How to Read Other People's Code -- And Why by notauser on Friday October 23, 2009 @02:58AM (#898394)
If top-of-function comments like:

/* Does everything required to initialise the UI (DO NOT CALL DIRECTLY - see class foo) */

Get outdated quickly (without being updated) you have big problems.

Equally a one line comment before things like:

// Do this if we can be certain we are in month X

if (!(!x || ($chk(diff(y,o)) && (z<p))) {...}

Saves you having to draw out a truth table each time. Even if the logic gets tweaked a bit when bugs are found the purpose of the code is likely to remain and so the comment won't age too badly.

Re:How to Read Other People's Code -- And Why by derefr on Friday October 23, 2009 @03:21AM (#898411)
In the first case, perhaps the function should only be accessible by/from Foo, or those that share a Foo-ish interface. In the second, I would really hope to be able to abstract that into a call to s.in_month?(m), with s perhaps being built from some combination of $chk, x, y, o, z, and p.
Re:How to Read Other People's Code -- And Why by olliesaunders on Friday October 23, 2009 @04:15AM (#898447)
Your parenthesis don't even match in the second example, which could easily be re-written not to require a comment by renaming the variables.