As the title says, this is in no particular order, a number
of random points about programming that I think are of
exceptional importance.
- The most cost-effective method of testing is code
reviews. This is true even before you count in
benefits in terms of knowledge transfer etc.
- The bug is probably in your code. Failing that it is
probably in something that changed recently.
- You are using version control software and have
backups, aren't you?
- The hardest class of bugs, and one of the most common
causes of failure for large projectgs lies in keeping
track of interactions at interfaces. This has been
known since the 70's and The Mythical Man-Month.
- Most software projects fail. The odds of failure rise
sharply with how hard it is for one person to keep track
of what is going on. The more people you have, and the
longer it is expected to take, the worse your odds are.
- When we start a project we inevitably do not know as
much as we will learn. Therefore we will make decisions
that in hindsight would be better being changed. Plan
ahead. If your interfaces hide information (as
recommended in references like
Code
Complete) then you are going to have an easier time in
revisiting decisions. This will be even easier if you
have a good set of
unit tests like the
XP people recommend.
(Thanks clemburg.)
- Programming is about keeping track of ideas. How can
you make this easier on yourself?
- Have you thought through your boundary cases in detail?
Methodically walk through your code and test them, you
may be shocked...
- One of the most common errors is to reverse the meaning
of a flag. This is both an easy error to make, and is
hard to catch in reviews. But name variables as yes/no
questions and you will almost never make this mistake.
Consider starting the name of your next flag with "is"...
- Don't make an ass of you and me.
- It is typically impossible to list all things that
could go wrong. It is generally fairly easy to list
conditions under which your code should behave correctly.
This observation has enormous consequences for how you
should validate user input...
- The basic outline of a transaction is that you note
that there is work to be done. create a private work
area, work in it, and then when the work is complete you
make it public. The really nice thing about thinking in
terms of transactions is that virtually all failure
situations are easy to handle, just log the issue, save
your private space (directory etc) somewhere for later
inspection, and abort the transaction. If you in addition
make a habit of keeping track of work that needs to be
done in a table and retry it periodically, you will be
amazed at how the system tends to be robust in the face
of unexpected problems. The relevance of these points
might not sink in for you until the next time a complex
sequence of steps breaks, leaving things in an
inconsistent state...
- It is likely that more truly innovative ideas have
come out of play than serious professionalism. Luckily
great software does not need to be particularly
innovative.
- That is a nice shiny wheel you just reinvented...
- ...on the other hand the world needs more than one
type of wheel...
- ...but the best way to create a new wheel is generally
to modify an existing one in unexpected ways. For
instance though woodworking could have used a wheel
earlier, they didn't get one until Tabitha Babbitt
modified her spinning wheel into a circular saw (circa
1813 or so).
- That which is not automated does not reliably happen.
- Be sure you have error checks...
- ...but will your messages make sense if things do
go wrong?
I know I missed plenty. So please add to the list.
Re: Random thoughts on programming
by japhy (Canon) on Feb 19, 2001 at 12:12 UTC
|
The following are based on personal experience. Those marked with a super-scripted asterisk (*) are common mantras I repeat on #perl.
- If someone's already done it, respect it, investigate it, use it, and build on it.
- Competition is healthy. Fierce competition is not. Two people working on the same project is not two people working on conflicting projects. Don't Fear the Collaborator.
- Programming is about finding patterns. *
- Not understanding something is not always a reason not to use it. Not understanding an algorithm can be a sign of laziness or ignorance. Not understanding why you're using something is a bad thing. (Case in point, people that do use CGI qw(:standard) and have no idea why.) *
- Code that reads like "There was an old lady who swallowed a fly" needs serious rethinking. (That is, code that is highly redundant, in the form of A; A B; A B C;.)
- Code should be fluent. Don't program in a stuttering manner. If this means you need to read all your code before you add more, by all means, do so.
- Users are evil. All users are evil. Do not trust them. Perl specifically offers the -T switch because it knows users are evil. *
- It helps a bit to know that program XYZ received invalid data. It helps a lot to know that program ABC sent XYZ invalid data. Learn to use stack-tracing tools (for Perl, that'd be Carp.pm).
japhy --
Perl and Regex Hacker | [reply] |
Re: Random thoughts on programming
by damian1301 (Curate) on Feb 19, 2001 at 11:09 UTC
|
20. Expect the worst - don't always think that the user's input will be nice, clean, and tidy.
21. Always use die and warn(sometimes) if the code has a possibility of failing.
22. DO NOT try to reinvent CGI.pm. It is already good enough as is and should not try to be re-written. Check out chromatic's homenode and generally(.*?) just look at daily posts on why not to.
I just thought I should point that out.
Almost a Perl hacker. Dave AKA damian
I encourage you to email me | [reply] [d/l] [select] |
(dkubb) Re: (2) Random thoughts on programming
by dkubb (Deacon) on Feb 19, 2001 at 14:52 UTC
|
- If you think you need to optimize, always profile your code first. Use Devel::Dprof for perl scripts, DBIx::Profile for DBI code, Apache::Dprof for mod_perl apps.
- Explore, Learn and Study CPAN. Look often at the recent uploads list. You never know when a module will come out that will allow you to re-factor out code from existing systems. Remember, even the most brilliant people understood the value of learning from those who came before:
"If I have seen further it is by standing on ye shoulders of Giants." --Isaac Newton Feb 5, 1676
- Look at the source code of the CPAN modules you use. Worst case, you will learn some interesting uses for perl, best case you'll learn more efficient ways to use those common modules you thought you knew everything about.
- Format and comment your code as if you are going to return to it later for instruction. File the location of this code in your memory (or better yet docs), because if you need to do something similar you have a pre-existing code base. Learn to bootstrap your future development using custom made documentation and examples.
- Find a good text editor. Learn it well.
- Get involved in PerlMonks.
- The teacher will sometimes learn more than the student. By trying to explain a concept to another person, it's like you're learning it all over again.
- Keep everything as simple as possible. Write the least amount of code to get the job done. Just given the law of averages your likelyhood of making mistakes goes down. Besides that, the less you need to keep in your head at once, the more likely you are to understand the bigger picture.
- Understanding needs to come before automation, otherwise you will be doomed to solve your problem again, and duplicate the effort to re-automate it. I always solve the problem proceduraly before making objects, keep paper records before making a database, and design interfaces in HTML before making CGI's. Even though this doesn't always return perfect results, IMHO I believe the answer I come up with is usually closer to the ideal than without this methodolgy.
| [reply] |
Re: Random thoughts on programming
by Tyke (Pilgrim) on Feb 19, 2001 at 15:10 UTC
|
- Start writing the test harness before you start writing
the code you want to test... it can often clarify just what it
is you need to do!
- From time to time stop and think. It's not a luxury!
- Don't be afraid to experiment with different ways to do
things, not only might you learn something new; but you
might also understand occasionally why your original code
was better
- Take time to clean your code up regularly... in
particular make an effort to be consistent even if it means
going back and reviewing existing code. Be critical.
- Sometimes you need to work at being lazy. Learn how to
use your toolset effectively. Add your own tools if you
need them.
| [reply] |
|
| [reply] |
|
| [reply] |
|
(crazyinsomniac) Re: Random thoughts on programming
by crazyinsomniac (Prior) on Feb 19, 2001 at 12:41 UTC
|
6. Don't forget about scope.
6. Make sure you're not forgetting about scope.
6. Be sure your're asking for what you really want.
6. Document that mother before you write it(or at least right after you do).
6. Forget about voodoo, cause praying won't help. If you don't know what your code is doing, like the man said, figure it out.
6. When all else fails, kick'n'reboot.
___crazyinsomniac_______________________________________
Disclaimer: Don't blame. It came from inside the void
perl -e "$q=$_;map({chr unpack qq;H*;,$_}split(q;;,q*H*));print;$q/$q;" | [reply] |
Re: Random thoughts on programming
by mothra (Hermit) on Feb 19, 2001 at 20:33 UTC
|
My $0.02:
- Learn the idioms of the language you're using. Respect them. USE them! This seems to do wonders for improving the readability of your code, and makes it easier to put your ideas into the "words" of the language you're using.
- Know when to/don't be afraid to put your code into functions. For me at least, 3-4 40-50 line functions are almost always easier to understand than 1 big honkin 200 liner that often seems to look ugly and repetitive.
- Focus on producing *good quality* code, with less of an emphasis on how quickly you can churn it out. I learned that from this node. :) It's amazing how lots of careful thought about a problem, without doing any (or very little) coding during that thought process can suddenly turn into an elegant solution.
| [reply] |
Re: Random thoughts on programming
by danger (Priest) on Feb 19, 2001 at 19:51 UTC
|
- Use a thought-processor before a text processor/editor (my
preferred thought-processor is a rotring 600 pencil and a pad of
graph paper)
- Document your data and design, not the code.
- If you are planning to throw one away, throw away that plan.
- Be sure your tests cover what the code is supposed to do, not
merely what it does do (writing the tests first, ala XP, is helpful
here).
- Step away from the code ... regularly!
| [reply] |
Re: Random thoughts on programming
by flay (Pilgrim) on Feb 19, 2001 at 14:23 UTC
|
Prototype, prototype, prototype. Or, as Fred Brooks put it:
`Plan to throw the first one away, because you will anyway.'
-- flay, here to learn
| [reply] |
Re: Random thoughts on programming
by dws (Chancellor) on Feb 20, 2001 at 02:00 UTC
|
7. Programming is about keeping track of ideas. How can you make this easier on yourself?
A corollary:
47. |
Programming is often a matter of keeping track of loose ends. Establish a convention for tracking yours (e.g., #FIXME) and use it religiously. A loose end that you don't fix before shipping is an embarrasment waiting to happen.
|
| [reply] [d/l] |
Re: Random thoughts on programming
by robsv (Curate) on Feb 19, 2001 at 21:19 UTC
|
Seeing tilly's
#5 random thought ("...The more people you have, and the
longer it is expected to take, the worse your odds are.")
reminds me of what often happens when software projects are
behind schedule. When a software project is running behind
schedule, and people "add manpower" (in the words of Fred
Brooks) or "throw bodies at the problem" (my description),
it often just makes matters worse. Brooks' law states that
"Adding manpower to a late software project makes it later".
If you're managing a software project that's running behind
and are tempted to add resources, remember Brooks' warning:
"When schedule slippage is recognized, the natural (and
traditional) response is to add manpower. Like dousing a
fire with gasoline, this makes matters much worse."
- robsv | [reply] |
|
I recall being taugh much the same early on in my programming career. The example give to me was:
"You cannot make a baby in one month by impregnating nine women:"
| [reply] |
Re: Random thoughts on programming
by Maclir (Curate) on Feb 20, 2001 at 02:14 UTC
|
A few thoughts:-
- Programmers will test their code to make sure it works. Users will test code to see where it breaks.
- Always look to see where you have hard coded limits. Things like numbers of variables in some array or structure, maximum / minimum values, things like that. Make them at least a globally defined value, so you only have to change things once when the user will (eventually) say "now could we make it do this . . . ".
- Data validation - it is easier to assume all data is wrong, and test to see if it is correct, than to assume it is correct, and look for errors. This, of course, sits well with the taint concept. And if the requirements change ("well, can we now handle negative rates of growth?"), you only need to add an additional validation test, or modify an existing test.
| [reply] |
Re: Random thoughts on programming
by Albannach (Monsignor) on Feb 20, 2001 at 02:27 UTC
|
One of my favorite goals which appears to sum up several of the more
specific ones stated earlier (simple to state but not so simple to implement):
A program should always gracefully survive even the worst data.
Whether it carries on unperturbed with a warning message in a log, or dies but
clearly spells out why (and does not frag the disk), will depend on the
specific nature of the application. I was reminded of this today while
trying to load a corrupt spreadsheet into Excel (which breaks all the rules 8-( ).
--
I'd like to be able to assign to an luser | [reply] |
Re: Random thoughts on programming
by el-moe (Scribe) on Feb 20, 2001 at 08:36 UTC
|
42. When debugging is getting you down, go outside and look at the sky or the trees or the ocean... anything but text. Take a deep breath or five and remember that you know what's wrong. You just need to look at your code with someone else's eyes... even if they belong to you... Prost, Moe | [reply] |
(ichimunki) re: Random thoughts on programming
by ichimunki (Priest) on Feb 20, 2001 at 03:15 UTC
|
Hmmm. All kinds of great thoughts and no has stated rule #0: "Have fun-- Programming is fun!"
{grin} | [reply] |
|
| [reply] |
Re: Random thoughts on programming
by petral (Curate) on Feb 21, 2001 at 02:41 UTC
|
A propos of #5, this from Dr. Haussler, professor of computer science: "He's unbelievable. This program represents an amount
of work that would have taken a team of 5 or 10 programmers
at least six months or a year."
From NYTimes Tues 13 Feb 2001.
Talking about James Kent who, in 4 weeks, wrote code to integrate the Human Genome Project's data and thus stay in step with the attempts to do it commercially.
p | [reply] [d/l] |
|
It's worth noting that Kent had to ice his wrists at night. A codefest like the amazing one he pulled off isn't easy on the body.
| [reply] |
Re: Random thoughts on programming
by johndageek (Hermit) on Aug 12, 2003 at 20:37 UTC
|
Enjoy the journey of life, learn from each moment.
All points in your life intersect through you.
Think of all that experiences you have, to combine in ways that have never been tried before.
Brilliance is just a matter of combining experiences and ideas you have had applied in ways no one else has thought of in a particular situation.
They pay me for those momentary flashes of brilliance each day.
PRORAMMING
Listen to the request for help.
keep listening - do not assume you know the answer and start contemplating a solution.
Ask for clarification, claiming ignorance - You will be amazed at how often that claim turns out to be true.
Speak to others with needs for the same types of help, your expanded insight will improve your solution.
Mentally solve the problem 3 ways, using only existing programs and systems.
Decision time: to code or not to code, that is the question.
If the solution can be implemented without code - GREAT, it's done. and you can move on to other cool things.
If the solution needs coding - GREAT, you now have a program that really needs to be written, using all the neat techniques and skills you possess, or will possess because you have need to epand your boundaries.
Elegance: the simplest solution with the best performance that will work for the most people at the lowest cost.
Solution test suite: Would I want to use my solution to do my job every day in exactly the way I am asking others to use it?
Enjoy!
John | [reply] |
Re: Random thoughts on programming
by prodevel (Scribe) on Feb 26, 2001 at 11:51 UTC
|
If you're a code mentor (you have low-level coders, whether they be DB, JAVA, J++,
JSP, ASP, PHP, SOAP) coders looking for DB info, always ask what their project is,
not what they're trying to do at the moment. I've had way too many interactions
w/newbies trying to work around problems w/me as a shepard.
When I circumvented these situations, eventually, by systematically asking detailed q's,
I've been able to solve any simple problem I've come against.
This has saved me enough time to POST to this heavenly subj.,
even though there were so many BRILLANT responses.
Just wanted to add what <italic>little</italic> I could.
| [reply] |
|
|