Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot

Re: Rewriting some code

by athomason (Curate)
on Feb 18, 2001 at 05:27 UTC ( #59198=note: print w/ replies, xml ) Need Help??

in reply to Rewriting some code

It's great you realize that planning will help you. The urge to dive into a project is frequently hard to resist, as anyone who enjoys programming knows. But the best ways to plan a project depend on a great many things. Some common factors that can affect your strategy:

  • Architecture - language, platform, etc.
  • Program size - programs with 500 lines and 500,000 require totally different approaches
  • Timeframe - did you need the program yesterday, or do you have a year to get it right?
  • Number of collaborators - it's much less hassle to do things yourself, but large projects require coworkers, and the red tape that comes with them

You need to know all these things before you start writing any code. Don't just think about them; write them down, or explain them to someone else. Structuring your thoughts in a more concrete manner will force you to really understand what you're doing. Getting the requirements right is the first thing you'll need to do. Next, look in more detail at what languages, algorithms, libraries, etc you can reuse. Compare a variety of them and see which fits your project best. Flowcharts and other graphical diagrams, as non-computer-esque as they seem, can frequently help you organize your ideas and find fundamental problems very early. The right design decision can save you enormous cost down the line.

Once you've got a good idea of how you want to structure your program, start looking at how to implement it in general terms without actually writing code. Most coders I know tend to itch to start writing code as soon as it's fairly obvious how to implement a routine, but restrain yourself until you know that the obvious way is the best way. My favorite tool for good program design is writing an initial draft in a sort of formal pseudocode called PDL (Program Design Language... see the book link below). Before ever writing a scrap of code, map out in detailed English (or whatever natural language you prefer) what your routines will do. This frees you from syntactical constraints of your target language and allows you to tell at a glance what routines do. Recursively revise your draft with increasing detail until you can go almost directly from that to code. Any logical flaws are much easier to correct if you uncover in the planning phase than once you've started coding. As an added bonus, once you fill in the code, you've got comments already there in the form of the PDL.

Your question relates mainly to the planning stage, but maintainability is also greatly influenced by how you write the code itself. Structuring routines and classes for maximum understandability and flexibility will always help you in the future.

One of the most valuable books on my shelf is Steve McConnell's Code Complete, because it address exactly these issues. I've had it for seven years and reread it every so often just to remind myself of how I should be doing things. Amazon has a list of related titles (which I can't vouch for personally, but look similar) that you might find useful.

Comment on Re: Rewriting some code
Re: Re: Rewriting some code
by Fingo (Monk) on Feb 18, 2001 at 08:42 UTC
    A book about good code, provided by Micro$soft??!!? I wondered why Hell had ordered all that ice... :)

    UPDATE: This was meant as a joke, I do not know how good Code Complete is, it just seemed ironic to me that a company whose software is always crashing, would publish a book on good code design
      Actually, if you open the book and read it, you will find that it contains a lot of good advice. Microsoft, you must admit, does write a lot of software, and if anyone should be able to comment from a position of experience alone, then Microsoft would certainly qualify.

      As for the content, the author apologises if the material is a little too C oriented, but a lot of it applies quite literally to Perl as well, if only because they share a lot of syntax, semantics, and pitfalls, such as:
      if ($my_var = 0) { # Why doesn't this EVER run!?!? DoImportantStuff(); }
      The author is a strong advocate of the "Hungarian" naming system, where in a strictly typed language like C or C++, the name of the variable indicates its type, such as 'nPeople' (int) or 'pszName' (char *). This is not entirely irrelevant for Perl, that while it will readily convert between int and char, it still isn't psychic. You will be punished severely if you switch up $q for $p when $q is a CGI object and $p is a SQL statement handle. Hungarian would have you call them '$cgi' and '$sth', for example, or perhaps '$cgiMain' and '$sthSelectAll'.

      I know, a book about writing good code from Microsoft, the creators of DOS 4.0, Windows NT3 and much, much worse, but when you consider that Windows 2000 actually runs at all, despite being 25 million lines of code, they must be doing something right. It seems that the author wrote the book to try and promote good coding practices within Microsoft, a practice that was strangely absent from one of the world's largest software manufacturers.

      While it may not be as comprehensive as XP, it does promote a better methodology than the ad-hoc approach taken by many, and it uses a lot of code examples to illustrate its points. Have a look through it if you have a chance, and see for yourself.
        Lets not start a Microsoft flame-war. Those are almost always stupid.
        I moved my original message here

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://59198]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others avoiding work at the Monastery: (6)
As of 2014-09-19 10:22 GMT
Find Nodes?
    Voting Booth?

    How do you remember the number of days in each month?

    Results (135 votes), past polls