how to write good code

Discussion in 'C++' started by Lynn McGuire, Jan 9, 2011.

  1. Lynn McGuire

    Lynn McGuire Guest

    How to write good code:
    http://xkcd.com/844/

    I usually follow the code fast branch myself.

    Lynn
     
    Lynn McGuire, Jan 9, 2011
    #1
    1. Advertising

  2. Lynn McGuire

    Ebenezer Guest

    On Jan 9, 3:04 pm, "Lynn McGuire" <> wrote:
    > How to write good code:
    >    http://xkcd.com/844/
    >
    > I usually follow the code fast branch myself.
    >
    > Lynn


    I favor the do it right path. The requirements can change on
    you that way, but not to the extent that you have to throw it
    all out and start over. In a Wall Street Journal article on
    the best and worst jobs (software developer was rated no. 1)
    a software developer was quoted, "You can't think that you'll
    learn a skill now and that it will still be relevant in six
    months." I disagree with that. It's important to work at
    keeping up with new developments, but am not finding things
    I've learned are being discarded that quickly.

    Brian Wood
    Ebenezer Enterprises
    http://webEbenezer.net
    (651) 251-9384
     
    Ebenezer, Jan 10, 2011
    #2
    1. Advertising

  3. Lynn McGuire

    Guest

    I always tried to write code so that it could be easily modified.
     
    , Jan 10, 2011
    #3
  4. Lynn McGuire

    viper-2 Guest

    On Jan 9, 4:04 pm, "Lynn McGuire" <> wrote:
    > How to write good code:
    >    http://xkcd.com/844/
    >
    > I usually follow the code fast branch myself.
    >
    > Lynn


    Coding fast and coding well are not mutually exclusive.

    agt

    --
    Freedom - no pane, all gaiGN!

    Code Art Now
    http://codeartnow.com
    Email:
     
    viper-2, Jan 10, 2011
    #4
  5. Lynn McGuire

    gmail-unlp Guest

    On Jan 9, 6:04 pm, "Lynn McGuire" <> wrote:
    > How to write good code:
    >    http://xkcd.com/844/
    >
    > I usually follow the code fast branch myself.
    >
    > Lynn


    Real programmers do not have these issues... but I'm not one of
    them...

    Fernando.
     
    gmail-unlp, Jan 10, 2011
    #5
  6. On 01/10/2011 10:14 AM, Les Neilson wrote:
    >
    > "Lynn McGuire" <> wrote in message
    > news:igd7sc$s6e$-september.org...
    >> How to write good code:
    >> http://xkcd.com/844/


    LOL!

    > There is an old saying :
    > do you want it done
    > (a) on time
    > (b) within budget
    > (c) correct
    > choose one of the above
    >
    > Les


    There is a variation on this (which was probably the original source)
    attributed to Henry Ford (quoted from memory here):

    We can deliver it:

    (a) well done;
    (b) in short time;
    (c) cheaply.

    Choose any two.
     
    Robert Hairgrove, Jan 10, 2011
    #6
  7. On 10 jan, 03:52, Ebenezer <> wrote:
    > On Jan 9, 3:04 pm, "Lynn McGuire" <> wrote:
    >
    > > How to write good code:
    > >    http://xkcd.com/844/

    >
    > > I usually follow the code fast branch myself.

    >
    > > Lynn

    >
    > I favor the do it right path.  The requirements can change on
    > you that way, but not to the extent that you have to throw it
    > all out and start over.


    And of course the *code right/ path is also the *project*'s fast path
    (if not the code fast path).
    Saying that code fast path is project's fast path is like saying that
    making a loan is a fast way to become millionaire.

    This is of course to be balanced with the kind of project: if you
    don't expect to live long enough to have to repay the loan that might
    be the path.
    Some would say it is also a bad consultant's path, but that's plain
    slandering and I won't say it. No, it won't pass my lips.

    [snip]

    --
    Michael
     
    Michael Doubez, Jan 10, 2011
    #7
  8. Michael Doubez <> wrote:

    > Saying that code fast path is project's fast path is like saying that
    > making a loan is a fast way to become millionaire.


    It might be a difference in idiom between French and English, but I
    think you mean "taking" a loan instead of "making" one. In the most
    usual scenarios, it is the bank that makes a loan and you that takes
    one. If I make a loan, that's like when I loaned money to my son to help
    him with the down payment on his house, or when I sold a rental
    appartment building and took paper for part of the sales price. (It
    hadn't occured to me until just now, but it does seem slightly amusing
    that I "take" paper to "make" a loan).

    I mention it because I was actually briefly confused as to what you
    meant. One can make money by making loans (banks do it). At first, I
    tried to connect that to your statement. Only when that didn't seem to
    make sense did I realize that you probably meant it the other way, which
    then made plenty of sense.

    --
    Richard Maine | Good judgment comes from experience;
    email: last name at domain . net | experience comes from bad judgment.
    domain: summertriangle | -- Mark Twain
     
    Richard Maine, Jan 10, 2011
    #8
  9. Robert Hairgrove <> wrote:

    > There is a variation on this (which was probably the original source)
    > attributed to Henry Ford (quoted from memory here):
    >
    > We can deliver it:
    >
    > (a) well done;
    > (b) in short time;
    > (c) cheaply.
    >
    > Choose any two.


    Ford might have been the originator. I wouldn't off-hand know (and
    didn't bother to research). A recent NASA administrator (in)famously
    adopted a variant of it as sort of a slogan. Unfortunately, he rather
    missed the point. We (NASA) were going to do things "better, faster,
    cheaper". Yes, we were going to do all three. As was no great surprise
    to some people, insisting that we could do all thee often ended up
    achieving none of them.

    --
    Richard Maine | Good judgment comes from experience;
    email: last name at domain . net | experience comes from bad judgment.
    domain: summertriangle | -- Mark Twain
     
    Richard Maine, Jan 10, 2011
    #9
  10. Robert Hairgrove <> writes:

    >> There is an old saying :
    >> do you want it done
    >> (a) on time
    >> (b) within budget
    >> (c) correct
    >> choose one of the above


    > There is a variation on this (which was probably the original source)
    > attributed to Henry Ford (quoted from memory here):
    >
    > We can deliver it:
    > (a) well done;
    > (b) in short time;
    > (c) cheaply.
    > Choose any two.


    I know this as the "Extended Heisenberg Uncertainty Principle" (applied
    to IT), saying that the feature set, cost and delay of a project cannot
    be simultaneously known with high precision. Sorry, I have no
    reference/source.

    -- Alain.
     
    Alain Ketterlin, Jan 10, 2011
    #10
  11. On 10 jan, 18:12, (Richard Maine) wrote:
    > Michael Doubez <> wrote:
    > > Saying that code fast path is project's fast path is like saying that
    > > making a loan is a fast way to become millionaire.

    >
    > It might be a difference in idiom between French and English, but I
    > think you mean "taking" a loan instead of "making" one.


    Yes I meant 'taking a loan'.
    In french we have to different words and the verb is not significant.
    Thanks for correcting me.

    [snip]

    --
    Michael
     
    Michael Doubez, Jan 11, 2011
    #11
  12. On 11 jan, 13:01, (Yannick Tremblay) wrote:
    > In article <>,
    > Michael Doubez  <> wrote:
    >
    >
    >
    > >On 10 jan, 03:52, Ebenezer <> wrote:
    > >> On Jan 9, 3:04 pm, "Lynn McGuire" <> wrote:

    >
    > >> > How to write good code:
    > >> >http://xkcd.com/844/

    >
    > >> > I usually follow the code fast branch myself.

    >
    > >> > Lynn

    >
    > >> I favor the do it right path. The requirements can change on
    > >> you that way, but not to the extent that you have to throw it
    > >> all out and start over.

    >
    > >And of course the *code right/ path is also the *project*'s fast path
    > >(if not the code fast path).
    > >Saying that code fast path is project's fast path is like saying that
    > >taking a loan is a fast way to become millionaire.

    >
    > Sorry Michael but the "metaphore" is broken.
    >
    > The idea of the code fast approach is that you get a product working
    > sooner albeit arguably with more bugs or with a worse architecture.


    "Get the product working" might be the heck. And if so, you made a
    loan but still have to repay de the debt off which can be expensive
    (or at the detriment of customers which is what happens today).

    Well, I won't debate it since the current consensus goes your way; we
    could debate taking the example of Apple that delivered a good product
    or discuss on how to measure the real costs of quality.

    The rest is just my rambling.

    > The code right approach is that you spent more time to get the
    > architecture and design right but get the product later.
    >
    > The possible consequences:
    >
    > code fast:
    > + Go to market sooner
    > + Start getting revenues sooner
    > + Get in before the market or requirement changes
    > - Have less features
    > - Maybe have more bugs
    > - Maybe loose your reputation because of too much bugs
    > - Future improvement more costly because of poorer architecture
    >
    > code right:
    > + Maybe have less bugs
    > + Maybe have more features
    > + Have a better architecture, more modular. easier to add to
    > - Start getting revenues later
    > - Maybe get to the market too late (competitor took over the opportunity)
    > - Maybe get overtaken by changes in requirements before release.


    This is quite a static view. In fact, one observes the process, the
    "go fast" starts with a lot more feature that are removed when times
    goes short, while the go right as lesser decrease but can subsequently
    built on solid foundation.

    > Both approaches have their pros and cons.  The correct answer is in
    > getting the balance correct.


    Agreed, that is the usual view. Nitpick: note that in the diagram,
    there is no direct branch from one to the other (which IMO should be a
    singly directed edge from right to fast).

    This is all the most easier since customers are now so used to having
    bug and buying faulty software. Although that this is not necessarily
    true on the asian market (or so I have been told), where a shoddy
    product will simply be not sold by distributors.

    > But as far as the loan metaphore is concerned, the sooner you go on the
    > market, the less you have to borrow so I am afraid this is upside
    > down.


    The marvels of marketing. You are of course right on the state of the
    art but I don't have to like it.

    > Oh and you will find that quite a few peoples became millionaire by
    > borrowing money to invest in higher return ventures (e.g. during the
    > property boom).  Actually, it's probably the fastest way to become
    > millionaire. Borrow a large amount of money, invest it in a high risk,
    > high rewards venture and either go bankrupt or become millionaire :)


    But the milionnaire repaid his debt off, didn't he ?
    And I expect the successful one was the one to do it right (excepted
    for the varibility due to lucky ones).

    Truth is that in the software factory, you don't always have the
    budget to go back and makes things right where you made them fast.
    Embracing "go shoddy" as a way of coding rather than a downside of
    pressure is plain wrong IMO.

    --
    Michael
     
    Michael Doubez, Jan 11, 2011
    #12
  13. Lynn McGuire

    James Kanze Guest

    On Jan 11, 12:01 pm, (Yannick Tremblay) wrote:
    > In article <>,
    > Michael Doubez <> wrote:
    > >On 10 jan, 03:52, Ebenezer <> wrote:
    > >> On Jan 9, 3:04 pm, "Lynn McGuire" <> wrote:


    > >> > How to write good code:
    > >> >http://xkcd.com/844/


    > >> > I usually follow the code fast branch myself.


    > >> I favor the do it right path. The requirements can change on
    > >> you that way, but not to the extent that you have to throw it
    > >> all out and start over.


    > >And of course the *code right/ path is also the *project*'s fast path
    > >(if not the code fast path).
    > >Saying that code fast path is project's fast path is like saying that
    > >making a loan is a fast way to become millionaire.


    > Sorry Michael but the "metaphore" is broken.


    > The idea of the code fast approach is that you get a product working
    > sooner albeit arguably with more bugs or with a worse architecture.


    And it's a false idea. In practice, taking the right path will
    generally result in the product working significantly faster.

    > The code right approach is that you spent more time to get the
    > architecture and design right but get the product later.


    > The possible consequences:


    > code fast:
    > + Go to market sooner
    > + Start getting revenues sooner
    > + Get in before the market or requirement changes
    > - Have less features
    > - Maybe have more bugs
    > - Maybe loose your reputation because of too much bugs
    > - Future improvement more costly because of poorer architecture


    > code right:
    > + Maybe have less bugs
    > + Maybe have more features
    > + Have a better architecture, more modular. easier to add to
    > - Start getting revenues later
    > - Maybe get to the market too late (competitor took over the opportunity)
    > - Maybe get overtaken by changes in requirements before release.


    > Both approaches have their pros and cons. The correct answer is in
    > getting the balance correct.


    Except that taking the fast branch doesn't get you to market
    faster, and often will shut you out of the market once you get
    to market (since too many bugs will give you a bad reputation).

    --
    James Kanze
     
    James Kanze, Jan 11, 2011
    #13
  14. Lynn McGuire

    Balog Pal Guest

    "Yannick Tremblay" <>

    > The code right approach is that you spent more time to get the
    > architecture and design right but get the product later.


    This sounds like "leading". Yeah, you spend more time on design, design
    reviews, other quality measures. No, you do not get the product later with
    that approach comparing to the alternative "jump to coding" way.

    The "fast way" is just delusion. Like in traffic when you chose a huge
    detour on small streets avoiding traffic lights ws the highway where you sit
    and wait green at some moments. That feels like waste, while otherwise you
    have some speed all the time.

    The projects I saw being done "the right way" were all finished much closer
    to original deadlines (as a matter of fact were practically in time), and
    used up considerably less overall effort. While tho others went way over
    time, and tied down resources after release.

    It is old established fact for software development, that good quality is
    cheap, and defects are expensive.
     
    Balog Pal, Jan 11, 2011
    #14
  15. Lynn McGuire

    James Kanze Guest

    On Jan 12, 10:42 am, (Yannick Tremblay) wrote:
    > In article <>,
    > James Kanze <> wrote:


    [...]
    > >> The idea of the code fast approach is that you get
    > >> a product working sooner albeit arguably with more bugs or
    > >> with a worse architecture.


    > >And it's a false idea. In practice, taking the right path
    > >will generally result in the product working significantly
    > >faster.


    > I am sorry but I will have to qualify my remark and issue a partial
    > disagreement.


    One major qualification is definitly in order. The discussion
    has been fast path vs. right path, as though it were some sort
    of binary choice. In fact, of course, there are all sorts of
    variations you can follow. I interpreted the earlier postings
    as using "fast path" and "right path" as characterizations of
    a certain type of process. If by "fast", you mean time to
    market, it's often the same as "right".

    > In the code fast approach, there are a few things that you can
    > sacrifice:


    > 1- Quality: this result in more bugs is is almost always a bad
    > thing. This should be avoided.


    > It seems that all the proponents of the "code right" approach assume
    > that only quality can be sacrificed. This is not the case. It is
    > perfectly possible to have a fast approach that does not sacrifice
    > quality.


    > 2- Features: as long as you have the main required features and have
    > the quality, your product will sell. There's a lot of fluff features
    > that are not necessary to make a good product that sell well.
    > Cuttingdown on less important featur is likely to reuslt in hitting
    > the market sooner and with less bugs. (Would the iPhone have been more
    > successful if Apple had waited to implement multitasking and MMS
    > before releasing it? )


    > 3- A clean modular reusable architecture that is ideal for the
    > future. This can be sacrificed depending on circumstances.


    But not if you've omitted features which will have to be added
    (quickly) later:).

    > You will only see benefit of a modular architecture by having future
    > improvement of the product be easier.


    No. You will see the benefit immediately, in easier testing and
    validation. How do you write unit tests if you don't have
    a modular architecture? And good unit tests reduce total
    development time. (Up to a point, of course. But the number of
    organizations which have reached that point is very, very
    small.)

    [...]
    > If we want to go semantic, we could argue that "code right" is always
    > the right thing to do since by definition is it "right" and take the
    > assumption that the "code fast" branch actually means "code too fast"
    > which is of course always the wrong thing.


    Yes. By definition. That's why I assumed some sort of
    characterization.

    --
    James Kanze
     
    James Kanze, Jan 12, 2011
    #15
  16. On Jan 11, 3:27 pm, Michael Doubez <> wrote:
    > On 11 jan, 13:01, (Yannick Tremblay) wrote:
    > > Both approaches have their pros and cons.  The correct answer is in
    > > getting the balance correct.

    >
    > Agreed, that is the usual view. Nitpick: note that in the diagram,
    > there is no direct branch from one to the other (which IMO should be a
    > singly directed edge from right to fast).
    >
    > This is all the most easier since customers are now so used to having
    > bug and buying faulty software. Although that this is not necessarily
    > true on the asian market (or so I have been told), where a shoddy
    > product will simply be not sold by distributors.


    There is also a large market where the end-customers don't view the
    product as software and for that reason are less tolerant about having
    bugs in the product. One product where customers are not accepting
    buggy software is the radio/entertainment system of their car.

    >
    >
    > --
    > Michael


    Bart v Ingen Schenau
     
    Bart van Ingen Schenau, Jan 12, 2011
    #16
  17. Lynn McGuire

    Ebenezer Guest

    On Jan 12, 5:45 am, James Kanze <> wrote:
    > On Jan 12, 10:42 am, (Yannick Tremblay) wrote:
    >
    > > In article <>,
    > > James Kanze  <> wrote:

    >
    >     [...]
    >
    > > >> The idea of the code fast approach is that you get
    > > >> a product working sooner albeit arguably with more bugs or
    > > >> with a worse architecture.
    > > >And it's a false idea.  In practice, taking the right path
    > > >will generally result in the product working significantly
    > > >faster.

    > > I am sorry but I will have to qualify my remark and issue a partial
    > > disagreement.

    >
    > One major qualification is definitly in order.  The discussion
    > has been fast path vs. right path, as though it were some sort
    > of binary choice.  In fact, of course, there are all sorts of
    > variations you can follow.  I interpreted the earlier postings
    > as using "fast path" and "right path" as characterizations of
    > a certain type of process.  If by "fast", you mean time to
    > market, it's often the same as "right".
    >
    >


    I think of the tortoise and the hare. It's a paradox how
    the tortoise defeats the hare. Even though the hare has
    gotten far ahead of the tortoise, the tortoise has read
    how the story ends and so he continues by faith.


    Ploddingly yours,
    Brian Wood
     
    Ebenezer, Jan 12, 2011
    #17
  18. Lynn McGuire

    Paul Guest

    "Lynn McGuire" <> wrote in message
    news:igd7sc$s6e$-september.org...
    > How to write good code:
    > http://xkcd.com/844/
    >
    > I usually follow the code fast branch myself.
    >
    > Lynn
    >

    According to this diagram there is no path that leads to good code.
    If there was a fast path leading to good code I would choose that one ;)
     
    Paul, Jan 13, 2011
    #18
  19. Lynn McGuire

    Lynn McGuire Guest

    On 1/13/2011 4:00 PM, Paul wrote:
    >
    > "Lynn McGuire" <> wrote in message news:igd7sc$s6e$-september.org...
    >> How to write good code:
    >> http://xkcd.com/844/
    >>
    >> I usually follow the code fast branch myself.
    >>
    >> Lynn
    >>

    > According to this diagram there is no path that leads to good code.
    > If there was a fast path leading to good code I would choose that one ;)


    Yup, that was the point. There is no path to good code.
    After a software product is in a the wild for a while,
    everything is a patch.

    Lynn
     
    Lynn McGuire, Jan 14, 2011
    #19
  20. Lynn McGuire

    Öö Tiib Guest

    On Jan 9, 11:04 pm, "Lynn McGuire" <> wrote:
    > How to write good code:
    >    http://xkcd.com/844/
    >
    > I usually follow the code fast branch myself.


    Me too. There are some things to keep in mind when going to code fast:

    1) It is often faster to write new code initially unintegrated from
    rest of application. As result i do not need to build the whole
    application to see if it compiles and links. I do not need to navigate
    in whole application to particular place/situation to see if and how
    it works.

    2) It is faster to see if it compiles and how it behaves instead of
    reading the code and imagining its behavior. For that purpose it is
    good to write tests. Sometimes little separate unit tests are fine,
    sometimes testing application can be made. Testability also indicates
    how clear are requirements and how easy is to integrate the new code
    with something else.

    3) When i integrate my code with rest of the application then i pay
    attention that it should be made cheap to throw it or its parts away
    and replace with something else. New requirements *will* pop up always
    (unlike comic tries to tell). If the initial design does not fit with
    new requirements then it is often faster to write that part anew and
    not to try and hack the previous attempt to meet new requirements.

    4) GUI is terribly slow to test. It changes a lot depending on things
    displayed, skins and styles and localization settings used, so
    automatic test frameworks can somewhat support but not replace human
    testers. Since GUI is something that share-holders see, the
    requirements about it change most often. We try keeping GUI as
    separate layer and never place application's business logic into GUI
    layer. Then that layer can be replaced with fake "GUI" layer and usual
    unit tests can be written using it.

    5) The external devices and third party applications are in too
    constant change ... quite like GUI and even more expensive to test. We
    always aim to fake these things too, it ends up faster to market.

    Some novice may think that i talk too lot about tests. Nope. Usually
    more than 60% of to-market effort goes into discovering and dealing
    with issues so that is the biggest part of real development and it
    gives best effect to speed it up.

    As for "good code" is code that my team members do understand and
    accept when they read it. For achieving that we have review process.
    Team members have to read each others code and then write what they
    did not understand, what defects they saw and what did not fit with
    coding policies that we have agreed to use. Defects discovered that
    early are cheaper to fix too, so reasonable review process actually
    speeds everything up and helps to achieve "good code" too.
     
    Öö Tiib, Jan 16, 2011
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. sikka noel
    Replies:
    8
    Views:
    437
    Mike Wahler
    Aug 5, 2003
  2. vlsidesign
    Replies:
    26
    Views:
    1,042
    Keith Thompson
    Jan 2, 2007
  3. Cliff  Martin
    Replies:
    1
    Views:
    3,080
    Larry Smith
    Jan 31, 2007
  4. SM
    Replies:
    9
    Views:
    529
  5. Andrea Mondelli

    How to write good C++ code

    Andrea Mondelli, May 21, 2013, in forum: C++
    Replies:
    6
    Views:
    334
    Anand Hariharan
    May 23, 2013
Loading...

Share This Page