Thread: A development process

  1. #16
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,396
    Quote Originally Posted by mog View Post
    1. Write one line
    2. Compile
    3. Fix error(s)
    4. Write another line
    But that's a purely syntax-based approach. Just because your program compiles doesn't mean it's not full of errors. Eventually you get the hang of the language and don't make syntax mistakes anymore -- or only rarely -- but that doesn't mean your code is bug-free.

    I'd suggest that you should write code non-stop until you run out of ideas. As soon as you find yourself thinking, "Hmm. I'm not sure how to do this next part..." that's a good time to stop and compile. This avoids creating a break in your concentration. The result will probably be a thousand syntax errors -- that's OKAY. Just look at the first one, and go fix it. Recompile, and repeat. Don't try to fix all the errors in a single pass. Often times, many errors all stem from a single typo. You may find that 3 different typos can create hundreds of errors.

    Avoiding the break in concentration is very important while in the learning phase. Switching between problem-solving mode and syntax-fixing mode can be taxing.

  2. #17
    بابلی ریکا Masterx's Avatar
    Join Date
    Nov 2007
    Location
    Somewhere nearby,Who Cares?
    Posts
    497
    Great stuff tanx dude

  3. #18
    /*enjoy*/
    Join Date
    Apr 2004
    Posts
    159
    thank you for this perfect code ...

  4. #19
    Registered User
    Join Date
    May 2008
    Location
    Kentucky
    Posts
    13
    Begging to differ on the act of commenting code.

    I try to make myself comment every line as I code. Actually, I've had more than one instructor and/or associate insist that such is the best practice.

    The best practice actually may be a bit backwards.

    Start with pseudo-code. (I'm just sure you all pseudo-code first. (couchchokespit))
    Then put your actual code in right next to the pseudo-code. By doing this your code is pretty much commented already.

    Dale L

  5. #20
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by nakedBallerina View Post
    Begging to differ on the act of commenting code.

    I try to make myself comment every line as I code. Actually, I've had more than one instructor and/or associate insist that such is the best practice.
    I personally don't think it makes sense to comment on every line of code - comments should clarify what the purpose of the code is and quite often a sequence of say 5-10 lines is self-explanatory once you understand why the sequence is there, with "special" things commented on the line, e.g:
    Code:
    //fill in data for the current BLT operation
    // We need to know where the blit starts, where it ends and how wide and high it is. 
    // A stride is needed to know how many bytes the image 
    bltinfo.x = rect.x;
    bltinfo.w = rect.w;
    // Note blits start from "bottom" going up. 
    bltinfo.y = rect.y + rect.h;
    bltinfo.h= rect.h;
    
    bltinfo.dataAddress = &img.data[img.x + img.y * img.stride];
    // Remember, we go UP, so stride is negative.
    bltinfo.stride = -img.stride;
    // Now tell the chip to perform the operation. 
    DoBlt(&bltinfo);
    I agree, you need to have some idea how the code should be implemented, either as pseudo-code, or as a design sketch that describes in "plain English" how it all works [at least roughly].

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  6. #21
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,675
    Comments (for students) tend to emphasis knowledge of the language as much as anything.
    Comments for pros are really just to explain what isn't obvious from just reading the code.
    Play to your audience basically - there is no set style.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  7. #22
    Registered User
    Join Date
    Jul 2008
    Posts
    1
    perfect !

  8. #23
    Registered User
    Join Date
    Jul 2008
    Posts
    1

    Lightbulb developing code

    The coders who have it right are the ones who document at all stages - before, during, after - especially before.

    If you don't do it before, then regardless of how accomplished you think you are, your middle name is always 'Spagetti', like Joe 'Spagetti' Smith. If you DON'T know what you are going to code BEFOREHAND, and can't or won't explain it to yourself, you are in deep doo doo from the first line of code onwards, because you are lazy.

    Actually writing the code, is like painting the house you built. DO IT LAST !!!

    Start with an architectural drawing, plan out the construction, get the right tools, make a solid foundation, build a sound structure, ensure the fundamentals for expansion are in place, finish the plan - according to the plan ... then paint it. If you did things right, you can modify, reconstruct or rebuild things, and still meet code standards. Else call "Holmes on Home" to rescue you.

    It is easy to paint and repaint a solid wall or ceiling, right?
    Last edited by bertking2; 07-04-2008 at 03:08 PM.

  9. #24
    Lurking whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    9,611
    I'm not one for speaking in metaphor, but developers usually don't have that kind of time. Their goal is if they can get it to work at all, get something shipped.

    It's good for newbs to plan because they'll become more familiar with language tools, and learn how to make/follow a program spec. It does get easier.

  10. #25
    Hurry Slowly vart's Avatar
    Join Date
    Oct 2006
    Location
    Rishon LeZion, Israel
    Posts
    6,786
    but developers usually don't have that kind of time.
    You have never provided support for your own code? Or worse - code written by someone else?

    If you do - you will always try to find "that kind of time" to write comments at least...
    All problems in computer science can be solved by another level of indirection,
    except for the problem of too many layers of indirection.
    – David J. Wheeler

  11. #26
    Registered User
    Join Date
    Jan 2009
    Posts
    1
    Great thread.

  12. #27
    Complete Beginner
    Join Date
    Feb 2009
    Posts
    312
    I'm not one for speaking in metaphor, but developers usually don't have that kind of time. Their goal is if they can get it to work at all, get something shipped.
    Once programmers enter the level of mediocrity, they tend to forget about all those good advices like "always use comments", "think before you start" and so on. Everybody knows that his own code is obvious and perfect, so why waste time?

    Saying that developers are happy if they get it to work at all and have it shipped is maybe true if they're writing a web-based calendar in PHP or if they are working at Microsoft. But consider a company that builds an operating system for a nuclear power plant, or maybe just the software for the airbag in your car (as a friend of mine did for BMW). You don't want these people to ship the code as soon as it works, right?


    There are good reasons these advices are passed around, so let's see why:


    1. USE COMMENTS

    This is true for beginners and advanced programmers alike. Comments make it easy for others to understand your code, and as soon as the project increases to, say, 10.000 (2.000.000) lines of code, it will also be much easier for you. There is a line between "impossible" and "give me 5 minutes", and if it comes down to it, you can only cross it with comments.

    But there's even more to it: if you are used to attach a comment to each of your functions, you are forced to think about what you did and how/why you did it. I've found more errors in my own code by writing comments than by testing/debugging. Which leads directly to my next point:


    2. THINK BEFORE YOU WRITE

    A common mistake among beginners is to blindly start typing characters in their text files and then wonder why the compiler/machine has a different opinion about the code's semantics. In the traditional waterfall model of software development, the time spent on actually producing the code is about 10-20% of the overall development time. The rest is thinking (>70%) and fixing errors (10% to 20 years). At university, we had to develop a small game (actually, a 3D-, networked, multiplayer game). We spent about 4 weeks thinking about the design, layout, necessary methods, classes and their relationships (yes, we were using C++), and when we were ready, it took us about 4 days to implement it in 20.000 lines of code. By then, we were all complete beginners at C++. When was the last time you wrote 20.000 lines of code from scratch nearly error-free in 4 days?


    So, don't listen to people telling you to not invest further thinking in your own code.
    Use your head.
    Gets you ahead.

    Greets,
    Philip

  13. #28
    Registered User
    Join Date
    Feb 2009
    Posts
    278
    Amen. And a program doesn't need to be 10,000 lines before it gets confusing if you don't document/comment. A program of just a couple hundred lines can be confusing. Especially to someone else or to you a couple weeks after you write it.

  14. #29
    Registered User
    Join Date
    Mar 2009
    Posts
    48
    A good tutorial for me.
    I just read the white bible (K & R) in this morning.
    there is no "ctype.h" inclued at the book smaple code. :-)
    Last edited by userpingz; 05-29-2009 at 07:14 AM.
    --------------------------------------------------------
    Newbie
    C/C#/C++
    swimming/cycling/running
    There is nothing more powerful than an idea.
    Except for an idea put into action.
    --------------------------------------------------------

  15. #30
    Registered User
    Join Date
    Jun 2009
    Location
    US of A
    Posts
    305

    Smile

    Simply fantastic !!!!! I always used to wonder how those big lines of codes are written but now i know the secret too !!!!!!! Thanks a lot

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. init adopts zombie process?
    By password636 in forum Linux Programming
    Replies: 4
    Last Post: 07-01-2009, 10:05 AM
  2. Replies: 3
    Last Post: 10-15-2008, 09:24 AM
  3. Problem with forking a process
    By Unitedroad in forum C Programming
    Replies: 10
    Last Post: 10-04-2007, 01:43 AM
  4. process programming
    By St0rM-MaN in forum Linux Programming
    Replies: 2
    Last Post: 09-15-2007, 07:53 AM
  5. Happiest moment during development process....
    By Nutshell in forum A Brief History of Cprogramming.com
    Replies: 16
    Last Post: 04-02-2002, 11:40 AM