RE: Code Review section, anyone?

In no particular order....

Isn't code review offered in principle by both Seekers of Perl Wisdom and, for shorter questions, Q & A?
At the level of the slycer and BastardOperator and, I hope, myself you run into a thorny problem -- most, although by no means all, of my mistakes will be structural rather than procedural (unless I'm venturing into uncharted territory -- in which case I'm probably back at the level of quick and dirty answers).
This makes it extremely difficult for someone to review a section of my code and say: "this could be done better," because doing so would involve a review of all the code... which is generally going to be well over 300 lines
Speaking for myself, I also come from a non-traditional programming background (uh, Comparative Literature) and have reached the point where I need to understand more about the why before I can move forward again with the how. I've been trying to work my way through Mastering Algorithms (and getting bogged down in b-trees) but it makes me think that a section devoted to strategy rather than review might be more helpful.
After all, most of the time I waste is going back when I discover that a particularl methodology doesn't get me where I need to be, not that a particular subroutine in causing me problems.

I hope this makes sense, because I'm arguing not for a section where code is excluded but where the discussion 'decomposes' into code from a meta-programmatic level -- e.g. I'm writing an application to watch a log-file and report on irregular behavior -- I know that I need to mask the process itself so that a hacker won't realize they're being observed, and I also need a way to recover any data they might have changed. Where should I look for more information about this? And what are the common traps that people writing this kind of program fall into?

The thing that I like about this idea is that it enables me to ask complex questions and get useful answers without either a) expecting anyone to give up a large amount of their time reviewing the implementation, or b) being handed the answer on a plate which doesn't help me learn.

Hope this makes sense.

Comment on RE: Code Review section, anyone?

Replies are listed 'Best First'.
RE (tilly) 2: Code Review section, anyone? by tilly (Archbishop) on Sep 14, 2000 at 19:01 UTC
I recommend that for this kind of problem you start with some general programming books (eg "Code Complete" and "The Pragmatic Programmer") and go from there. Overall, "How do I structure what I am doing" questions are very important but far too seldom considered. I mean to post some day on a few of these issues. Thinking in terms of transactions. Modularization and loose coupling. etc. However so far the majority of that discussion around here stops at, "Avoid Cargo Cult programming and don't bother reinventing wheels." But the next time you are starting to write something, why not spec out the general flow, and post that asking for general comments? The question may have no Perl per se in it, but the answers should be helpful and relevant to Perl programmers...	[reply]

Replies are listed 'Best First'.

RE (tilly) 2: Code Review section, anyone?
by tilly (Archbishop) on Sep 14, 2000 at 19:01 UTC

I mean to post some day on a few of these issues. Thinking in terms of transactions. Modularization and loose coupling. etc. However so far the majority of that discussion around here stops at, "Avoid Cargo Cult programming and don't bother reinventing wheels."

But the next time you are starting to write something, why not spec out the general flow, and post that asking for general comments? The question may have no Perl per se in it, but the answers should be helpful and relevant to Perl programmers...

[reply]